CWE-1395 is simple to state. The product has a dependency on a third party component that contains one or more known vulnerabilities.
If your software uses any library, module, framework or bundled operating system you did not write, this one is yours. That is nearly everyone.
How it happens
MITRE points out that many products are large enough that part of their functionality comes from libraries, modules or other intellectual property built by someone else. In some hardware products even the whole operating system comes from a supplier. Open or closed source, those components may carry publicly known vulnerabilities, or hidden functionality such as malware, that an adversary can use against your product.
The weakness is not the bug in the component itself. It is the dependency: you chose to include it, and you keep shipping it after the flaw is public.
One observed example in the record is CVE-2025-45612, where a product uses a vulnerable version of an authentication framework, allowing authentication bypass.
A few patterns lead here:
- Nobody knows what is inside. Without an inventory, a new advisory cannot be matched to your product.
- Nobody owns the patch. MITRE notes that in industries such as healthcare, or in the cloud, it can be unclear whether the vendor, the operator or a separate service applies third party patches.
- Updates stall. The component's maintainers fix the flaw but your release process does not pick it up.
- End of life. The component stops getting fixes entirely.
What an attacker gains
MITRE says the consequences vary widely. They span confidentiality, integrity and availability, and depend on which vulnerabilities exist in the component and how adversaries can reach them, given how your product uses the component and what attack surface that creates.
That last point is worth sitting on. A vulnerable function that your code never calls is a different risk from one sitting on a request path. Reachability analysis, which checks whether your code calls the vulnerable function, helps you tell the two apart and decide what to fix first.
How to find it
MITRE recommends software composition analysis (SCA) for software. SCA tools automatically identify third party dependencies and can link them to known vulnerabilities. The record notes that commercial and open source options exist.
A simple start:
- Generate a list of every direct and transitive dependency from your lockfiles or build output.
- Match each name and version against vulnerability data.
- Rank the matches by whether the vulnerable code is reachable and whether a fix exists.
- Repeat on every build, because new advisories appear for versions you already shipped.
You can try this with no account. The free in browser dependency scan takes a manifest, keeps the file on your machine, and handles up to 100 dependencies.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE's mitigations are mostly about process, and they are worth following in order.
Settle responsibility. Where it is unclear who patches third party vulnerabilities, clarify roles in requirements and policy so disclosure does not lead to delay.
Require and maintain a bill of materials. For software, that means a Software Bill of Materials (SBOM). MITRE quotes a definition: a formal, machine readable inventory of software components and dependencies, information about those components, and their hierarchical relationships. Ask suppliers for one, and keep your own up to date through design, implementation, integration and manufacturing.
Watch for patches and apply them. In operation and maintenance, monitor when a component vendor announces fixes, update the component as soon as possible, and make it easy for operators and customers to obtain and apply the patch.
Track component health. Continuously monitor changes in each component, especially ones that signal new vulnerabilities or end of life plans.
Quick check
Is a vulnerable dependency always exploitable?
No. MITRE says consequences depend on how adversaries can reach the vulnerability given how the component is used. Reachability analysis checks whether your code calls the vulnerable function.
What does MITRE recommend for finding these weaknesses in software?
Software composition analysis tools, which identify third party dependencies and link them to known vulnerabilities.
Why does an SBOM matter here?
It is the inventory that lets you match a newly announced vulnerability to the products that contain the affected component.
