CWE-1277 describes a product that gives its users no way to update or patch its firmware to fix vulnerabilities or weaknesses. It affects device makers, and it affects everyone who buys, deploys or inherits the device.
How it happens
Without an update path, consumers stay exposed to any known vulnerability and to any that is found later. MITRE points out that this can mean permanent risk across the device's whole lifetime, which may be years or decades. Outside protections such as network controls may reduce the risk, but the root weakness cannot be corrected.
It shows up in two forms. Some products ship with no update mechanism at all. Others are update capable on paper but are declared end of support, so no patch will ever arrive.
Two recorded cases make this concrete.
- CVE-2020-9054: a network-attached storage device had a critical OS command injection flaw (CWE-78) that was actively exploited to place IoT devices into a botnet, while some products were end-of-support. The record frames it as a chain.
- A hardware smart lock had weak key generation that let attackers steal the key by sniffing Bluetooth Low Energy traffic, but its firmware could not be upgraded and so it remained vulnerable. MITRE cites this as REF-1095.
In both, the first bug is ordinary. The missing update path is what turns it into a lasting problem.
What an attacker gains
MITRE rates this Medium and lists confidentiality and integrity loss, access control and authentication failures, gaining privileges, bypassing protection, executing unauthorized code or commands, and crashing the device. The record notes that if an attacker finds an exploitable flaw in one device that cannot be patched, that flaw is available against every device of the type.
How to find it
MITRE lists three approaches.
- Manual analysis. Build a new installable boot image of the current build with a minor version number change. Install it using the standard method and check that the version number changed. Then create a fake image and verify the boot updater refuses to install it.
- Architecture or design review. Check the user or maintainer documentation, the design documents or the original requirements for details on how to update the firmware.
- Manual dynamic analysis. Determine whether there is no ability to update the read-only memory structure. This can appear as a difference between the latest firmware version and the version in the device.
If you are the buyer instead of the maker, ask a simpler set of questions before purchase. Does the vendor publish firmware updates? For how long is support promised? How are updates delivered and verified?
How to fix it
The record lists no mitigation text, but the detection steps describe the target design.
- Build an update mechanism into the product from the start. Retrofitting is harder.
- Make the updater reject images it cannot authenticate, as the fake image test checks.
- Document the update procedure for users and maintainers.
- State a support period and keep to it, so customers can plan replacement.
- Keep a software bill of materials for the firmware so that when a component in it is disclosed as vulnerable you can tell which products need a release.
For teams that consume devices, add network segmentation and replacement plans for anything that can no longer be patched. These reduce exposure but, as MITRE notes, do not correct the root weakness.
Try it yourself
Firmware is built from components, and those components get CVEs. Tracking them continuously is how you learn a patch is needed before an attacker tells you. The demo shows the idea for monitoring.
Click through it at your own pace, or open it full screen.
You can also check a dependency manifest for known CVEs with the free in-browser scan. It needs no login, the file stays on your machine, and it covers up to 100 dependencies.
Quick check
Why is an end-of-support device in the same category?
In practice there is no patch coming, so a newly found bug remains open for the life of the device. The CVE-2020-9054 record mentions end-of-support products for this reason.
What does the fake image test prove?
That the boot updater only installs authentic images. An update path that accepts anything is its own vulnerability.
