CWE-1104 is the weakness of relying on third-party components that are not actively supported or maintained by the original developer, or by a trusted proxy for that developer. MITRE files it under bad coding practices and under CWE-1357, reliance on an insufficiently trustworthy component.
It applies to almost every team that ships software. If your product pulls in open source libraries, vendored code, firmware blobs or commercial SDKs, some of them will eventually stop receiving updates. The weakness is not the age of the code. It is the fact that when a flaw turns up, nobody is left to fix it.
How it happens
Nobody decides to depend on dead code. It happens gradually.
A maintainer burns out and archives the repository. A company is acquired and the product line is retired. A library is replaced by a successor and the old one gets no more releases. A project is forked, and the fork quietly stops too. Meanwhile your build keeps working, so nothing prompts you to look.
MITRE lists the usual mode of introduction as the architecture and design phase. That fits: the choice to adopt a component is a design decision, and the maintenance status of that component is rarely part of the decision record.
The problem also hides in depth. You may have picked a healthy library that itself bundles or requires something abandoned. MITRE's observed example CVE-2025-40906 is a case like this: CVE-2025-40906 is described as a Perl module for BSON serialization that includes a component which reached end of life roughly five years earlier, and that component has multiple vulnerabilities. The module's own authors were not the ones who stopped maintaining the bundled piece.
A second example from the record is CVE-2024-35252, a closed-source cloud storage product that includes an unmaintained third-party component that allows denial of service. Closed source makes this harder still, because customers cannot see what is inside.
What an attacker gains
MITRE lists the impact scope as other, with reduced maintainability and varying effects by context. In plain terms, relying on unmaintained components makes it difficult or impossible to fix significant bugs and vulnerabilities, can render code obsolete, and complicates maintenance in ways that raise the risk of new vulnerabilities.
The attacker does not need a clever new technique. A known flaw in an abandoned component stays known and stays unfixed. The advisory is public, the exploit may be public, and there is no upstream patch to apply. Your options shrink to forking, patching it yourself, replacing it or accepting the risk.
How to find it
MITRE's detection note says static analysis can find some instances of this weakness. In practice the most useful checks are about inventory and metadata rather than source patterns.
- Build a complete dependency inventory, including transitive dependencies and anything vendored into your tree.
- For each component, check the date of the last release and the last commit, whether the repository is archived, and whether the registry marks the package as deprecated.
- Look for a stated end-of-life date from the vendor or project.
- Check whether the component has open security issues with no maintainer response.
- Flag components bundled inside other components. These are the easiest to miss.
You can start with an inventory right now. The free in-browser scanner at gold.safeguard.sh/scan takes a dependency file, needs no login, keeps the file on your machine and handles up to 100 dependencies. It reports known vulnerabilities, which is a useful first signal: a package with several unpatched findings and no recent release deserves a closer look.
How to fix it
The MITRE record for this entry lists no formal mitigations, so what follows is general engineering practice rather than quoted guidance.
- Decide on a policy before you need one. Write down what counts as unmaintained, for example no release in a set period and no response to security reports. A shared definition turns arguments into checks.
- Record maintenance status at adoption time. When a new dependency is proposed, note who maintains it and how active the project is. Revisit the note on a schedule.
- Replace, do not hope. Move to an actively maintained alternative or the successor project where one exists.
- Fork with eyes open. If you must keep using the code, owning a fork means owning its security fixes. Assign a named owner and budget for it.
- Isolate what you cannot replace yet. Limit the component's privileges, input exposure and network reach until a replacement lands.
- Prioritise by reachability. A vulnerable function that your code never calls is lower urgency than one on a request path. Reachability analysis answers that question, and it helps you sequence the replacement work.
- Watch continuously. A component can become unmaintained after you adopt it, so a one-time review is not enough.
Try it yourself
This demo walks through building a dependency inventory, which is the step where abandoned components first become visible.
Click through it at your own pace, or open it full screen.
Quick check
Is an old library automatically an unmaintained one?
No. Age alone is not the weakness. A stable library with a responsive maintainer who still ships security fixes is fine. The weakness is the absence of anyone able or willing to fix problems.
Why can a bundled component be worse than a direct dependency?
Because it is easy to overlook. The library you chose may look healthy while carrying an abandoned piece inside, as the Perl BSON example in the MITRE record illustrates.
What is the first step if you find one?
Find out where it is reachable. Then pick between replacing it, forking it with a named owner, or isolating it until you can do one of the first two.
