The Problem
A scan of the top 5,000 websites using WebPageTest and the Snyk vulnerability database found that 76.6% include at least one JavaScript library with a known vulnerability. The most common issue is jQuery, with 79% of instances running version 1.x, which reached end-of-life years ago. This widespread use of outdated libraries exposes millions of users to documented security flaws.
The Timeline of Neglect
The study provides a snapshot rather than a progressive incident, but the timeline of neglect is clear:
- 2013-2016: jQuery 1.x versions released and widely adopted
- 2016: jQuery 3.0 released with security improvements
- 2019-2021: Multiple CVEs published against jQuery 1.x and 2.x
- 2024: 79% of jQuery deployments still running vulnerable 1.x versions
This ongoing issue leaves libraries in production, increasing daily exposure.
Missing Controls
Dependency Inventory
Most organizations lack a complete inventory of client-side dependencies. Without knowing what you're running, you can't patch vulnerabilities. Unlike server-side package managers, front-end dependencies often come through:
- Direct
<script>tags pointing to CDNs - Copied files in
/vendordirectories - Build artifacts with no manifest
- Third-party widgets bundling their own libraries
Without a dependency manifest, teams rely on manual audits or wait for a scanner to flag issues—often months after a CVE is published.
Vulnerability Scanning
The study used Snyk's database, which covers a subset of the JavaScript ecosystem. Organizations relying solely on infrastructure scanners miss client-side libraries entirely. Your network scanner sees the HTML; it doesn't parse which libraries the browser will execute.
Even teams running SAST tools often configure them for server-side languages. JavaScript is treated as static content rather than executable code with its own attack surface.
Patch Management
The barrier isn't awareness—jQuery vulnerabilities are well-documented. The barrier is change control. Upgrading from jQuery 1.x to 3.x often breaks:
- Event delegation patterns
- AJAX error handling
- Animation callbacks
- Third-party plugins built against the old API
Teams face a choice: accept the risk or allocate sprint capacity to regression testing. Without dedicated front-end security ownership, the risk is often accepted by default.
Compliance Standards
PCI DSS
Requirement 6.3.2: "All system components are protected from known vulnerabilities by installing applicable security patches/updates, including patches/updates released by third-party vendors."
This includes client-side code. If your payment page includes jQuery 1.9 with a DOM-based XSS vulnerability, you're out of compliance.
Requirement 6.4.3: "For public-facing web applications, ensure that either automated or manual mechanisms are in place to detect and prevent web-based attacks."
Vulnerable JavaScript libraries expand your attack surface. A stored XSS vulnerability in your application plus a DOM-based XSS in jQuery creates an exploit chain.
OWASP Top 10 (2021)
A06:2021 – Vulnerable and Outdated Components: "You are likely vulnerable if you do not know the versions of all components you use (both client-side and server-side)."
The 79% jQuery 1.x figure suggests most organizations don't track client-side versions.
ISO 27001
Annex A.8.8 (Management of technical vulnerabilities): Organizations must establish a process to identify and evaluate technical vulnerabilities, then take appropriate action.
Running a library with published CVEs violates this control unless you've documented a risk acceptance decision with compensating controls.
Action Items for Your Team
1. Build a Client-Side Dependency Manifest
If you're using a build process (Webpack, Vite, Rollup), your package.json already lists dependencies. The problem is legacy code and marketing sites that bypass the build pipeline.
Action: Run a scan of your production sites with a tool like Retire.js or Snyk. Export the results as a baseline inventory. Add this scan to your CI/CD pipeline for new deployments.
2. Separate Detection from Remediation
Not every CVE requires immediate action. A prototype pollution vulnerability in a library you only use for date formatting on an internal admin panel has different risk than an XSS flaw on your checkout page.
Action: For each vulnerable library in your inventory, document:
- Where it's used (which pages/applications)
- What data those pages handle
- Whether the vulnerable code path is reachable given your usage
- Compensating controls (CSP headers, input validation)
3. Establish Ownership for Front-End Security
In most organizations, "security engineering" defaults to infrastructure and APIs. JavaScript gets lumped with "the website" and handed to a team optimizing conversion rates.
Action: Assign a specific person or team to own client-side security posture. They should attend the same vulnerability review meetings as your backend security team.
4. Implement Subresource Integrity (SRI) for CDN-Hosted Libraries
If you're loading libraries from a CDN, SRI hashes ensure the browser only executes the exact version you specified. This won't fix vulnerabilities, but it prevents an attacker who compromises the CDN from injecting malicious code.
Action: Add integrity attributes to all external <script> tags. Generate hashes using openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A.
5. Test Before You Update
The reason 79% of jQuery deployments are still on 1.x is that updating breaks things. Allocate time for testing.
Action: For critical libraries, create a test environment that mirrors production. Run your regression suite against the updated version. Budget for fixing broken functionality—this is security work, not a nice-to-have refactor.
The 76.6% figure isn't surprising to anyone who's audited a large web estate. What should concern you is that this number represents known vulnerabilities in tested libraries. The Snyk database doesn't cover every JavaScript library, and the scan didn't check for custom code vulnerabilities.
Your compliance reports might show green checkmarks because your servers are patched. Your client-side code is a different story. Start with inventory, prioritize by risk, and assign ownership. The alternative is waiting for an incident that forces the conversation.
