CWEweakness

CWE-1395 Dependency on Vulnerable Third-Party Component

Official page ↗
Abstraction
Class
Structure
Simple
Status
Incomplete
Languages
Not Language-Specific
CWE version
5.0

Description

The product has a dependency on a third-party component that contains one or more known vulnerabilities.

Common consequences

• Confidentiality, Integrity, Availability: Varies by Context — The consequences vary widely, depending on the vulnerabilities that exist in the component; how those vulnerabilities can be "reached" by adversaries, as the exploitation paths and attack surface will vary depending on how the component is used; and the criticality of the privilege levels and features for which the product relies on the component.

Potential mitigations

• [Requirements, Policy] In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities can be important to minimize confusion or unnecessary delay when third-party vulnerabilities are disclosed. • [Requirements] Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311]. • [Architecture and Design, Implementation, Integration, Manufacturing] Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships." • [Operation, Patching and Maintenance] Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch. • [Operation, Patching and Maintenance] Continuously monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.

Detection methods

• Automated Analysis: For software, use Software Composition Analysis (SCA) tools, which automatically analyze products to identify third-party dependencies. Often, SCA tools can be used to link with known vulnerabilities in the dependencies that they detect. There are commercial and open-source alternatives, such as OWASP Dependency-Check [REF-1312]. Many languages or frameworks have package managers with similar capabilities, such as npm audit for JavaScript, pip-audit for Python, govulncheck for Go, and many others. Dynamic methods can detect loading of third-party components.

Observed examples

• CVE-2025-45612: product uses a vulnerable version of an authentication framework, allowing authentication bypass

Related

Observed example · CVE (1)

  • CVE-2025-45612 Incorrect access control in xmall v1.1 allows attackers to bypass authentication via a crafted GET request to /index. vulnerability

Child of · CWE (2)

  • CWE-1357 Reliance on Insufficiently Trustworthy Component weakness
  • CWE-657 Violation of Secure Design Principles weakness

Referenced by OWASP · mapped cwe (1)

  • A03:2025 Software Supply Chain Failures Top 10 2025