Application Security in 2026: Why jQuery CVEs Still Dominate Codebases
Why outdated jQuery versions continue to dominate security reports—and what enterprises must do to reduce risk.
Remember when jQuery was the library? Before React had its moment, before Angular and Vue rose, there was jQuery, quietly doing the heavy lifting for half the internet. And here's the thing: it still is. However, recent data from the 2026 Black Duck Open Source Security and Risk Analysis (OSSRA) report tells a much more sobering story.
The report named jQuery the single most prevalent source of vulnerabilities across commercial codebases scanned. Four of the top ten most common CVEs found in scanned applications are jQuery CVEs, and between 25% and 28% of all codebases analyzed carry at least one of them. The reason is simple: the jQuery 1.x and 2.x branches stopped receiving security patches in 2016, but they never stopped being used.
Why is jQuery still so widely used in 2026?
jQuery turned 20 years old on January 14, 2026, and despite two decades of frontend framework churn, it remains one of the most widely deployed JavaScript libraries in history. According to W3Techs, jQuery is used by roughly 88% of all websites with a known JavaScript library and appears on approximately 70% of all websites. It ships by default with WordPress, which powers over 42% of the web, Drupal, and thousands of enterprise internal tools.
jQuery 4.0.0 was released on January 17, 2026. After a long development cycle and several pre-releases, jQuery 4.0.0 is the first major version release in almost 10 years and includes some breaking changes.
How is jQuery officially supported?
Unlike frameworks with formal long-term support (LTS) windows and fixed end-of-life (EOL) dates, jQuery operates on an informal support model signaled through release activity. Governed by the jQuery Foundation (now part of the OpenJS Foundation), with the release of jQuery 4, it has indicated that jQuery 3.x will only receive critical security patches and bug fixes, and the recommendation is to upgrade to the latest version of jQuery 4.x.
The state of jQuery release support today is summarized in:
- jQuery 1.x and 2.x: End of life since May 2016. No security patches, no bug fixes, no compatibility updates from the core team.
- jQuery 3.x: It will receive only critical security patches and bug fixes. No official EOL date, but the last release was in August 2023.
- jQuery 4.x: Latest release and actively maintained, with ongoing minor releases and security patches.
For jQuery unsupported versions (3.x and earlier versions), the jQuery project states 3 options:
- Upgrade to the latest version of jQuery. The best solution is to upgrade, as it will include all features, bug fixes, security patches, and improvements. The jQuery Migrate Plugin and upgrade guides are available to assist with upgrading.
- Continue using an older version of jQuery, but include all security patches through commercial security support by HeroDev’s Never-Ending Support (NES) offering. HeroDevs is part of the OpenJS Ecosystem Sustainability Program and is an approved commercial support vendor.
- Continue using an older version of jQuery without security patches. This means an increased risk of vulnerability exploitation resulting in potential cyberattacks, data breaches, ransom demands, or data and operational loss.
Why does jQuery still appear in modern codebases?
jQuery shows up as a transitive dependency in most enterprise codebases because it was baked into the foundations of the modern web. Older WordPress and Drupal 7 installations frequently shipped with jQuery 1.x, and that code persists in production today. Bootstrap 3 and 4 (Bootstrap 5 dropped jQuery in 2021), jQuery UI, DataTables, Select2, and hundreds of other UI plugins from the 2010 to 2018 era list it as a hard or peer dependency.
In an npm-based project, jQuery often shows up four or five levels deep in the dependency tree, pulled in by a UI library that depends on a wrapper that depends on a plugin that depends on jQuery. Run a simple npm ls jquery to surface it. Most teams don't run that check until an SBOM tool flags a CVE.
The practical consequence is that "we don't use jQuery" is rarely true for any application older than five years. The right question is which versions are present, where they came from, and which ones are EOL.
The Top Four jQuery CVEs Affecting Most Codebases
Despite the community’s strong track record of disclosing and patching vulnerabilities, the vast scale of jQuery deployments means that keeping software current with the latest minor releases is harder than it sounds. Organizations running large application portfolios often struggle to maintain an accurate inventory or software bill of materials (SBOM) that identifies which packages and libraries need updates. Combined with constrained engineering time, limited security resources, and uneven security posture across teams, the result is predictable: many applications run without the latest fixes. With jQuery, which appears in roughly 88% of all websites with a known JavaScript library, that problem multiplies across every codebase it touches.
The 2026 OSSRA report identified four jQuery CVEs responsible for the bulk of jQuery-related risk in enterprise applications. These vulnerabilities are not new, yet they persist because organizations fail to patch or migrate away from outdated versions. Most of these flaws involve Cross-Site Scripting (XSS), where an attacker can execute malicious scripts in a user's browser.
Each one is covered in the HeroDevs Vulnerability Directory with full technical detail:
These four CVEs continue to dominate, according to the OSSRA report, collectively affecting 25%–28% of codebases.
Four-Step Mitigation Guidance for the Unpatched jQuery CVEs Risk
- Audit Your SBOM: Use tools to generate a Software Bill of Materials (SBOM) to identify hidden jQuery instances.
- Upgrade to the latest jQuery: If possible, move to the latest version of jQuery 3.x or 4.x.
- Use HeroDevs NES: If you are stuck on jQuery 1.x, 2.x, or 3.x due to breaking changes, implement jQuery NES to ensure you are protected against the "Top 4" CVEs. See our How to Patch jQuery Vulnerabilities in Production Without a Full Rewrite blog for more details.
- Sanitize Inputs: Always use server-side validation and modern Content Security Policies (CSP) to mitigate the impact of potential XSS.
jQuery remains a powerful tool, but in 2026, its "persistent" nature is its greatest liability. Organizations must move beyond "set it and forget it" mentalities to ensure this dominant library doesn't become their dominant security failure.
Quick Reference: Is My jQuery Version Supported?
How to secure end-of-life jQuery in production
Don't wait for your next audit cycle to find jQuery 1.x or 2.x in production. Roughly one in four enterprise codebases scanned in 2026 carries an unpatched jQuery CVE, and these vulnerabilities have been public for five to ten years. HeroDevs NES for jQuery provides secure drop-in replacements for 1.x, 2.x, and 3.x with full CVE coverage and compliance documentation. Talk to our team about your jQuery footprint.
Frequently Asked Questions
Is jQuery officially end of life?
jQuery has no formal EOL policy. The jQuery 1.x and 2.x branches are effectively end of life: both received their final releases (1.12.4 and 2.2.4) on May 20, 2016, and have not received security patches since. jQuery 3.x will only receive critical security fixes; the last update was in August 2023. jQuery 4.x is the currently supported branch.
What is the latest version of jQuery?
jQuery 4.0.0, released on January 17, 2026, is the current stable release. jQuery 4 has been in beta since February 2024, which has given the opportunity to test and remediate issues. It includes breaking changes from 3.x.
Which jQuery versions are vulnerable to XSS?
All versions of jQuery before 3.5.0 are vulnerable to at least one of the htmlPrefilter XSS CVEs (CVE-2020-11022 and CVE-2020-11023). All versions before 3.0.0 are additionally vulnerable to CVE-2015-9251, the CORS-related XSS issue.
Can I keep running jQuery 1.x safely?
Not without compensating controls. jQuery 1.x carries multiple unpatched XSS and prototype pollution vulnerabilities, and no upstream fixes will be released. Options to mitigate include a strict Content Security Policy, server-side output encoding, input sanitization at every sink, or adopting a supported drop-in replacement such as HeroDevs NES for jQuery.
How do I know if jQuery is in my application?
Check your package.json, bower.json, composer.json, or explicit <script> tags. Also, check for transitive dependencies: WordPress, Drupal, many CMS themes, and hundreds of UI plugins pull in jQuery automatically. A Software Bill of Materials (SBOM) generated from tools like Syft, Black Duck, or Snyk will surface jQuery even when it is not a direct dependency.
