Your website's JavaScript dependencies are its supply chain. And just like a physical supply chain, a single weak link can compromise everything downstream. In 2025 alone, over 4,000 npm packages were identified as containing malicious code, and dozens of high-profile data breaches were traced back to outdated JavaScript libraries loaded directly by websites.
The uncomfortable truth: most websites still load at least one JavaScript library with known, published CVEs (Common Vulnerabilities and Exposures). Attackers don't need sophisticated zero-days when old jQuery XSS bugs are freely exploitable on millions of sites.
The Libraries Attackers Target Most
jQuery (versions before 3.5.0)
jQuery has multiple XSS vulnerabilities in versions before 3.5.0. The most exploited is CVE-2020-11022 — passing untrusted HTML to jQuery's DOM manipulation methods allows script injection. Given jQuery's ubiquity (still used on ~77% of all websites as of 2025), this remains one of the most exploited client-side vulnerabilities in the wild.
Lodash (versions before 4.17.21)
Lodash has prototype pollution vulnerabilities that allow attackers to modify the behaviour of all JavaScript objects on the page. CVE-2021-23337 — command injection in template() — is rated critical. If your site or any plugin uses an old Lodash, attackers can potentially bypass security checks.
AngularJS (versions before 1.8.0)
AngularJS (the legacy version, not Angular 2+) has multiple XSS bypass vulnerabilities. Sites still running Angular 1.x are particularly vulnerable because the framework's template system can be exploited to execute arbitrary JavaScript.
DOMPurify (versions before 2.3.0)
The irony is painful: DOMPurify is a sanitisation library designed to prevent XSS. Versions before 2.3.0 have bypass vulnerabilities that allow the exact attacks it's supposed to prevent.
Why This Matters for Trust
Vulnerable JavaScript libraries create three categories of risk:
1. Direct exploitation — Attackers inject malicious scripts that steal session cookies, redirect users to phishing pages, or modify page content (e.g., swapping payment form endpoints) 2. Compliance failure — GDPR Article 32 requires "appropriate technical measures" to protect user data. Running known-vulnerable libraries is the opposite of appropriate 3. Reputation damage — If your site is compromised through a known CVE, the conversation shifts from "we were hacked" to "you knew this vulnerability existed and didn't patch it"
How We Detect Vulnerable Libraries
Our scanner checks script URLs and inline JavaScript against a database of known vulnerable library versions. We match version strings from CDN URLs, self-hosted file paths, and library signatures in bundled code. Each finding includes the library name, detected version, and severity rating.
How to Fix Supply Chain Issues
1. Audit your dependencies — Run npm audit or check your CDN script tags against known vulnerability databases
2. Update to patched versions — Most vulnerabilities have straightforward patch upgrades (jQuery 3.5+, Lodash 4.17.21+)
3. Use Subresource Integrity (SRI) — Add integrity attributes to <script> tags loading from CDNs. This ensures the file hasn't been tampered with
4. Implement a Content Security Policy — CSP headers restrict which scripts can execute on your page, limiting the damage even if a library is compromised
Scan your website at RoastReady for a free supply chain security check — we detect vulnerable JavaScript libraries alongside 50+ other trust signals.