The Problem
Between 2023 and 2024, HTTP Archive analyzed 418,112 websites using Google Chrome's Lighthouse auditing tool. The findings revealed that 77% of these sites serve at least one JavaScript library containing known vulnerabilities. Specifically, 92.5% of jQuery versions found in production environments have security flaws that attackers can exploit.
This isn't a traditional breach—no single attacker compromised these sites. Instead, it represents a systemic control failure affecting hundreds of thousands of production environments. The vulnerable code is documented in CVE databases, waiting for exploitation.
Timeline of Vulnerability Management Failure
2016-2019: Multiple cross-site scripting (XSS) vulnerabilities disclosed in jQuery versions prior to 3.5.0. CVEs published. Patches released.
2020: jQuery 3.5.0 released with fixes. Migration guides published.
2021-2023: Snyk and other security vendors add jQuery vulnerabilities to their databases. Automated scanning tools flag these issues in thousands of codebases.
2023-2024: HTTP Archive analysis reveals 92.5% of production jQuery installations remain vulnerable. The same analysis shows 38% of open-source users don't use automated dependency update tools.
Present: The vulnerable code remains in production across 77% of analyzed sites. No coordinated remediation effort exists.
Failed or Missing Controls
The root cause isn't a sophisticated zero-day exploit. It's the absence or failure of basic software composition analysis (SCA) and dependency management controls:
Missing automated dependency scanning: 38% of organizations analyzed don't use tools to track vulnerable dependencies. This means security teams have no visibility into their JavaScript attack surface until manual audits occur—if they occur at all.
Broken change management processes: Even when teams know about jQuery vulnerabilities, updating a widely-used library requires testing across multiple pages and components. Without automated regression testing, teams defer updates indefinitely rather than risk breaking production functionality.
No inventory of client-side dependencies: Many organizations maintain detailed inventories of server-side components for compliance but treat client-side JavaScript as invisible. When your PCI DSS v4.0.1 Requirement 6.3.2 inventory doesn't include front-end libraries, you can't manage what you don't track.
Absent vulnerability disclosure response procedures: Security teams receive CVE notifications for server infrastructure but lack processes to triage and remediate front-end library vulnerabilities. The jQuery CVEs existed for years before this analysis—the gap isn't awareness, it's response capability.
Compliance Requirements
Multiple compliance frameworks address this control failure, though enforcement varies:
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software and third-party software components. Your jQuery library counts as a third-party component. If you process payment card data and don't track your JavaScript dependencies, you're non-compliant.
PCI DSS v4.0.1 Requirement 6.4.3 requires managing all payment page scripts loaded and executed in the consumer's browser. This explicitly includes third-party JavaScript libraries. You must maintain a list, justify business need, and ensure integrity. A vulnerable jQuery version fails the integrity requirement.
OWASP Top 10 2021 A06:2021 – Vulnerable and Outdated Components highlights this risk: "You do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies."
OWASP ASVS v4.0.3 V14.2.3 (Level 2 requirement) states: "Verify that all third-party components are up to date." This applies to JavaScript libraries as much as server-side packages.
NIST Cybersecurity Framework v2.0 ID.AM-2 requires software platforms and applications to be inventoried. Your client-side dependencies are software platforms.
ISO 27001 Annex A.8.31 covers security requirements in development and support processes, which includes managing third-party code vulnerabilities throughout the lifecycle.
The standards are clear. The gap is implementation.
Action Items for Your Team
Here's what you can implement this quarter:
Build a complete asset inventory that includes client-side dependencies. Extend your existing configuration management database (CMDB) or asset tracking system to include JavaScript libraries. For each library, track: version number, CDN vs. self-hosted status, pages where it loads, and business justification. Update this inventory with every deployment.
Implement automated SCA scanning in your CI/CD pipeline. Tools like Snyk, npm audit, or Yarn audit can flag vulnerable JavaScript dependencies before code reaches production. Set your pipeline to fail builds that introduce high or critical severity vulnerabilities. This prevents new vulnerable code from shipping while you remediate existing issues.
Create a JavaScript dependency update schedule. Don't wait for vulnerabilities to force updates. Review and update all client-side dependencies quarterly. Test updates in staging environments using automated regression testing. Document breaking changes and migration steps.
Establish a front-end vulnerability response process. When a JavaScript library CVE drops, your security team needs a defined workflow: triage severity, identify affected applications, test patches, schedule deployment, and verify remediation. This process should mirror your server-side vulnerability management workflow.
Use Subresource Integrity (SRI) for CDN-hosted libraries. If you load jQuery or other libraries from public CDNs, implement SRI tags to ensure the file hasn't been tampered with. This won't fix vulnerabilities, but it prevents attackers from compromising the CDN and injecting malicious code. Subresource Integrity
For the jQuery problem specifically: If you're running jQuery versions prior to 3.5.0, schedule an upgrade sprint. Yes, this requires testing. Yes, some plugins may break. But 92.5% of production jQuery installations being vulnerable means attackers have reliable, widespread targets. The XSS vulnerabilities in older jQuery versions allow attackers to inject malicious scripts through DOM manipulation—exactly the attack vector PCI DSS Requirement 6.4.3 aims to prevent.
The 77% figure isn't just a statistic. It represents hundreds of thousands of production environments where known, documented vulnerabilities sit exposed. Your site is likely among them. The question isn't whether you have vulnerable JavaScript libraries—the data suggests you probably do. The question is whether you'll implement the controls to find and fix them before an attacker does.
