CWE-1310 is less about a bug than about a missing repair path. A System or System-on-Chip (SoC) cannot patch its ROM code, so when a vulnerability is found after shipping, the system stays vulnerable.
If you run a patching program, this one will sound familiar. A weakness is manageable when you can fix it. It becomes a long-term exposure when you cannot.
How it happens
A secure boot process with a Root-of-Trust (RoT) usually starts by running code from a Read-only-Memory (ROM) component. ROM is immutable by design. That gives a stable anchor for trust, and it also means any security flaw in the ROM code can never be fixed on systems already in use.
The weakness MITRE describes is the absence of any mechanism to patch the ROM once flaws come to light. The device is then in a vulnerable state in the field, and an adversary can compromise the SoC through the unfixable code.
What an attacker gains
MITRE rates the likelihood of exploit as high. The listed impact is varies by context, with reduced maintainability. The record states the effect plainly: when the system is unable to be patched, it can be left in a vulnerable state.
The consequence is therefore open ended. It depends on what the flaw in the ROM allows, and it lasts for the life of every unit that shipped.
How to find it
The record lists no detection methods. This is a design question, so ask it during architecture review:
- Does the boot ROM have a defined route for accepting a patch?
- Is a patch authenticated before it is applied?
- Can the patch be delivered in the field, or only in manufacturing?
- Which parts of the boot flow are explicitly out of reach of any patch?
If a design review cannot answer the last question, the team does not yet know its remaining exposure.
How to fix it
MITRE lists two mitigations, both for the architecture and design and implementation stages, each rated moderate effectiveness.
- Add secure patch support so ROM code can be patched on the next boot.
- Support patches that can be programmed in the field or during manufacturing through hardware fuses. This allows limited patching after shipping, or for the next batch of silicon, without changing the full device ROM.
MITRE attaches honest caveats. Some parts of hardware initialization and of the signature verification used to authenticate patches will always be not patchable. Fuse-based patches are limited in size and in how many can be supported.
So a patch mechanism narrows the problem and does not erase it. Keep the unpatchable portion as small and as carefully reviewed as you can, because that portion has to be right the first time.
Try it yourself
Patchability is a general theme in vulnerability management. See how finding, prioritizing and fixing flows when a fix exists.
Click through it at your own pace, or open it full screen.
Quick check
Why is ROM both useful and risky for boot?
Being immutable gives a stable start for the Root-of-Trust. It also means a flaw there cannot be fixed on shipped units unless a patch route was designed in.
Does a fuse-based patch solve everything?
No. MITRE notes limits on patch size and count, and some initialization and signature verification will always be not patchable.
