CWE-1329 covers products that contain a component that cannot be updated or patched to remove vulnerabilities or significant bugs. It concerns firmware and hardware teams, and also anyone whose software depends on a library that nobody maintains any more.
How it happens
If a component turns out to have a vulnerability or critical bug and no update path exists, the owner cannot protect against it. The only option may be replacing the product, which can be too expensive or disruptive.
MITRE says the problem is hardest with ROM, firmware and similar parts that historically had little or no update capability. It also quotes a US task force report on healthcare, where legacy devices run for decades and organizations struggle with unsupported systems that cannot easily be replaced.
Software is affected as well. MITRE gives the example of a third-party driver or library that is no longer actively maintained or supported but is still critical for required functionality.
The record lists two observed CVEs:
- CVE-2022-34381: a Java-based SDK for TLS has an unmaintained third-party component with a critical vulnerability.
- CVE-2020-9054: a chain in which a network-attached storage device has a critical, actively exploited OS command injection used to place IoT devices into a botnet, while some of the products are end of support.
What an attacker gains
The consequences are broad: gain privileges, bypass protection mechanisms, execute unauthorized code, crash or restart the system, and reduced maintainability. If an attacker finds an exploitable flaw in the component, nothing can fix it in the field.
How to find it
MITRE's detection method is an architecture or design review: check the consumer or maintainer documentation, architecture documents or original requirements for how updates, including firmware updates, are done. Rated moderate.
For software dependencies, the equivalent is an inventory. List every component and note which ones have no recent releases, no maintainer response or an announced end of life. The free scanner at gold.safeguard.sh/scan (no login, file stays on your machine, up to 100 dependencies) gives a first list, and reachability analysis shows whether your code calls the vulnerable function in a component you cannot upgrade, which tells you where compensating controls matter most.
How to fix it
From the record:
- In requirements, specify that every component must be updateable, including ROM and firmware.
- In design, allow components to be updated, and include the external infrastructure needed, such as distribution servers.
- For hardware, support patches that can be programmed in the field or during manufacturing through hardware fuses. Rated moderate. MITRE cautions that some parts of initialization and signature verification will always be unpatchable, and fuse patches are limited in size and number.
- In implementation, build the functionality that lets each component be updated.
For software you already ship with an unmaintained dependency, plan the replacement before an incident forces it. Until then, wrap the component behind a narrow interface and restrict what input reaches it.
Try it yourself
Check how a continuous monitor flags dependencies when new advisories land, including ones that have no fixed version.
Click through it at your own pace, or open it full screen.
Quick check
Is this only a hardware problem?
No. MITRE says software is affected too, for example a third-party library that is no longer maintained but still critical.
What does MITRE suggest checking in a design review?
That the documentation explains how the firmware or component is updated.
