Using Components with Known Vulnerabilities

The application ships a third-party library, framework, or package at a version with a publicly disclosed CVE, and nobody upgraded it. This is one of the most reliably black-box-detectable classes on this list, in two different ways: (1) server-side or client-side software with a distinctive version banner or fingerprint (an HTTP header, a <meta generator> tag, a JS bundle's own version string) can be matched directly against known-CVE databases, and (2) if a dependency manifest itself (a lockfile) is accidentally exposed, the exact installed versions of every dependency are readable directly, removing the need to fingerprint anything.

• Publicly exposed package-lock.json, package.json, or requirements.txt
• Fingerprintable server/framework banners (headers, generator tags, error-page signatures)
• Outdated JS libraries bundled client-side with an identifiable version string

• Fetch conventional manifest paths (/package-lock.json, /package.json, /requirements.txt) left reachable at the web root
• Fingerprint server/framework/CMS versions from headers, banners, and default pages, then match against known-CVE version ranges
• Parse exact dependency versions from an exposed lockfile and check each against a public vulnerability database

• No injected payload - this is a discovery-and-correlation check, not a probe

Probe for exposed manifest files at their conventional paths; where found, parse the exact (or, for package.json alone, the floor-of-range) version of every listed dependency and check each against a public vulnerability database. Exact-version sources (a lockfile) are trusted at higher confidence than package.json alone, since the latter lists semver ranges rather than the version actually installed, and that distinction is carried into the finding rather than treated as equally certain.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• A package.json-only match reports the semver range's floor version, not a confirmed installed version - the finding says so explicitly rather than implying certainty a lockfile-based match would have.
• A CVE affecting a version range doesn't guarantee the specific deployment is exploitable (some CVEs require a non-default configuration to trigger), so findings are framed as "upgrade recommended" rather than "confirmed exploitable" unless a lockfile pins the exact vulnerable version.

Manual Testing Methodology

Here is a systematic approach to identifying Using Components with Known Vulnerabilities vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Using Components with Known Vulnerabilities specifically, fingerprint the technology stack and every dependency version reachable from response headers, error pages, and client-side bundles, then cross-reference each against public CVE and known-misconfiguration databases.

Compare the response against your baseline, looking specifically for a component version with a known, applicable CVE, a default account or debug feature still reachable, or a security header/setting that deviates from the hardened baseline.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Using Components with Known Vulnerabilities, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Security misconfiguration and outdated components are consistently among the most common findings in real-world assessments precisely because they don't require a code-level bug — a default setting left unchanged, an unnecessary feature left enabled, or a dependency left unpatched is enough on its own. Exploiting a known CVE in an outdated component is often more reliable for an attacker than finding a novel bug, since the exploit is already public and well-tested.

The impact ranges enormously depending on exactly what's misconfigured or outdated — anywhere from an information leak in a verbose banner to full remote code execution via a known, unpatched vulnerability in a framework or library.

This class is also disproportionately preventable relative to its frequency: unlike a novel logic flaw, both misconfiguration and outdated dependencies are catchable by routine process (configuration review, dependency scanning) rather than requiring a deep security review to find.

Prevention and Secure Coding

Preventing Using Components with Known Vulnerabilities takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Hardened baseline configuration, applied consistently. Maintain a security-reviewed baseline (headers, disabled unused features, no default accounts) and apply it through infrastructure-as-code so every environment gets the same configuration, not a manually-recreated approximation.

Automated dependency scanning. Track every dependency against known-vulnerability databases (Dependabot, npm audit, OSV) continuously, not just at release time, and patch on a defined cadence rather than only when convenient.

Remove what isn't used. Disable or uninstall unused features, sample applications, and default accounts that ship with a framework or platform — unused surface is still attack surface.

Environment parity. Keep staging and production configuration in sync so a hardening step applied to one doesn't quietly get skipped in the other.

Periodic external configuration review. Have someone outside the team that built the configuration review it periodically — configuration drift is easy to miss from the inside.