jQuery EOL Extended Support Options

Go straight to an AI summary of this blog post instead

Key Takeaways

Longevity created the lifecycle problem. jQuery 1.x and 2.x are EOL with no upstream patches, and every jQuery release before 3.5.0 carries at least one XSS CVE that was only ever fixed in a later version.
The exposure usually sits in your dependency graph. jQuery has no dependencies of its own, but plugins, themes, and vendor bundles pull it in at versions you never chose.
A major-version migration is not a file swap. Removed APIs, plugin breakage, and behavior changes produce bugs that surface under real user interaction rather than in CI.
Upgrade or rewrite is a false binary. OpenJS runs a non-exclusive program for commercial support of unsupported project versions, and TuxCare is one of its partners.

In January 2006, John Resig introduced jQuery at BarCamp in New York City with a modest goal: make JavaScript less painful to write. Twenty years and three days later, the project shipped 4.0.0. Somewhere between those two dates, your application picked up jQuery 1.11.3, and it is still in the bundle you deployed last Tuesday.

That gap is the actual jQuery End of Life problem. The library isn’t the issue. The issue is that jQuery got so widely deployed, so early, and so deep inside other people’s code that entire release lines went unsupported while still running in production at enormous scale. jQuery 1.x and 2.x have been EOL since 2016. Most sites running them never noticed.

Here’s the argument worth making, because it should change how you weigh your options: this isn’t a story about teams being careless. It’s a story about a volunteer-founded project outliving the assumption that everyone upgrades. The OpenJS Foundation, jQuery’s home today, has said as much publicly and built a program specifically to address it. That history tells you which of your options are legitimate and which are just procrastination with extra steps.

Why Old jQuery Is Still Everywhere

To understand why these versions persist, remember what jQuery was built to solve. In the mid-2000s, browsers implemented JavaScript and the DOM differently enough that finding an element, attaching a handler, or making an asynchronous request could require browser-specific branches. Code that worked in Firefox failed in Internet Explorer.

jQuery absorbed that complexity behind one concise API. That wasn’t only convenient. It gave teams a dependable compatibility layer at a time when the platform couldn’t provide one, and it made interactive frontend work accessible to a far larger group of developers.

Each release line marks a stage in that history:

jQuery 1.x (2006) supported browsers back to IE 6, which made it non-negotiable for enterprise and government applications with broad client requirements. 1.12.4, in May 2016, was the last of the line.

jQuery 2.x (2013) dropped IE 6-8 for a smaller build while keeping a familiar API. It ended at 2.2.4, also May 2016.

jQuery 3.x (2016) unified the two branches. 3.7.1 (August 2023) is the last feature release, and the project’s own support policy now states that 3.x receives only critical security patches and bug fixes, with all users encouraged to move to 4.x. Being on 3.7.1 is not the same as being on a fully supported branch.

jQuery 4.0.0 shipped January 17, 2026, the first major release in almost a decade. It drops IE 10 and older with IE 11 removal staged for 5.0, adds Trusted Types support, and stops silently converting cross-domain JSON requests to JSONP. Those last two are real security improvements.

One thing teams miss: jQuery UI, jQuery Mobile, and Sizzle are now Emeritus projects at OpenJS, meaning formally retired. If your migration plan includes “and update jQuery UI,” there is no supported version waiting at the other end.

What End of Life Actually Changes

When upstream maintenance ends, nothing breaks. Forms submit. Menus open. Ajax runs. The application behaves exactly as it did the day before.

What changes is the security model. The project is no longer expected to ship fixes for that line, so the next vulnerability affecting your version arrives with no upstream patch behind it. You learn about it from a scanner rather than a release note.

For a deeper breakdown of common security risks and CVEs, you can explore our detailed guide on jQuery vulnerabilities.

The CVE history clusters around exactly the features people use jQuery for:

CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.

CVE-2020-11022: The sibling flaw in the same parsing logic, with the same split scoring. Affects 1.2 through 3.4.1, so its range starts slightly later than CVE-2020-11023’s.

CVE-2019-11358 (CVSS 6.1): Prototype pollution in jQuery.extend(). An attacker who can influence the merged object can modify Object.prototype. Affects everything before 3.4.0, so all of 1.x and 2.x.

CVE-2015-9251: XSS in cross-domain Ajax handling. Issue a request without dataType and a hostile server can respond with text/javascript, which jQuery executes. Affects everything before 3.0.0.

CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.

Worth being precise: an affected version does not automatically mean an exploitable application. Real exposure depends on how your code uses jQuery, whether untrusted data reaches the vulnerable path, and what compensating controls you have. What these CVEs do demonstrate is that “the application still works” and “the application is still securely maintained” are different claims.

That distinction is where audits land. For a state agency running a permit portal on 1.11.3, the practical consequence isn’t a dramatic breach narrative. It’s a KEV-listed CVE with a federal deadline, a PCI DSS 6.3.3 finding if payments are involved, and an assessor asking what your remediation path is. “Upstream stopped patching it” doesn’t close a finding.

The Exposure Is in Your Dependency Graph

jQuery is self-contained and has no runtime dependencies, which makes it simpler than most modern packages.

Invert that and you find the problem. jQuery is one of the most depended-upon libraries in the history of the web, and your own code is a small part of the picture. The rest is plugins that assume a major version, WordPress themes, UI widgets, commercial components nobody maintains, vendor scripts, and older CMS or ecommerce platforms.

A common pattern: a team migrated its own code off jQuery years ago, everyone considers it gone, and then you open the network tab in production and find 1.11.3 loading from a path nobody recognizes because a licensed reporting widget bundles its own copy. Two versions on the page, one EOL, neither in the package.json anyone reviews. In some environments the file was copied into the source tree years ago and isn’t managed by a package manager at all.

Scanners will find many of these. Finding the library is the easy part. The team still has to work out why that version is there, what depends on it, and whether replacing it changes behavior.

The same graph is what makes upgrading hard. Plugin A targets 1.x. Plugin B calls .live(), removed in 1.9. Plugin C is a commercial component whose vendor stopped shipping in 2019 and whose license doesn’t include source.

Why OpenJS Built a Program for This

jQuery is an Impact Project at the OpenJS Foundation, the vendor-neutral home it landed in after a long governance path: Software Freedom Conservancy in 2009, the jQuery Foundation in 2012, then the 2019 merger with the Node.js Foundation that created OpenJS.

The Foundation has been working the jQuery security problem for years. OpenSSF’s Alpha-Omega project committed $350,000 in 2022 to reduce security incidents for jQuery by modernizing both its code and its consumers. OpenJS moved the jQuery CDN to Fastly, which as of late 2024 was serving on the order of 70 billion requests a month for it. The Foundation built the Healthy Web Checkup, a five-second tool whose only job is telling you which jQuery version your site loads. It commissioned the IDC research behind its own estimate that of roughly 1.9 billion websites, close to 90% use jQuery and about a third of those need an upgrade.

What that funding does not buy is indefinite maintenance of jQuery 1.8.2. There’s a hard limit on how much unpaid maintainer time can go toward patching versions that shipped when Windows 7 was current, and pretending otherwise is how maintainers burn out.

OpenJS launched the Ecosystem Sustainability Program in May 2024 to close that gap. Partners provide commercial security fixes for OpenJS-hosted projects that are archived, end-of-life, or older versions of current projects, and a share of that enterprise revenue flows back to the participating projects. HeroDevs was the first partner, NodeSource followed, and TuxCare joined the Foundation as a Gold member in 2026 and is now listed among the ESP partners on the OpenJS partners page.

Worth noting that the jQuery project itself treats this as a legitimate route. Its version-support policy gives three options for anyone running an older release: upgrade, keep the old version and get security patches through commercial support, or keep it with no patches at all, which the project flags as carrying real risk.

The boundaries still matter, because vendor marketing tends to blur them:

The program is non-exclusive. OpenJS is not telling you which provider to buy from, and three are currently listed at Foundation level.
ESP partners must be Gold or Platinum members and hold a trademark license for co-marketing, with project-level endorsement from the relevant TSC or core team where that applies. Foundation-level partnership and a specific project’s list of approved vendors are two different things, so check the project page for whichever project you actually run.
A partner’s patch for jQuery 1.12.4 is that partner’s patch. It is not an upstream release and does not make an old version officially supported again.
The program explicitly does not restrict maintainers from publicly supporting any version they choose.

The jQuery maintainers own the project and its current releases. OpenJS provides the neutral home. Extended-support providers cover specified older versions after upstream support ends. That’s a more sustainable split than expecting volunteers to maintain every historical release forever, or expecting every organization to finish a complex migration the moment a support boundary passes.

Your Three Options

Upgrade to a supported release

Where feasible, this is the right long-term answer. Current jQuery is better software, and 4.0’s Trusted Types support and JSONP change actively reduce your XSS surface.

But a jump from 1.x isn’t a version bump. The event system was rewritten. Ajax and Deferreds changed. .bind(), .delegate(), .live(), and .error() are gone or different. Selector edge cases shifted. The jQuery Migrate plugin will surface much of the deprecated behavior, which is the first tool to reach for. It won’t tell you which of your plugins has no maintained successor.

For a 40-person SaaS team with one app, current plugins, and real test coverage, this is a couple of sprints. For a bank’s internal admin suite with 200 accumulated plugins and client requirements that still mention IE 11, it’s months, and the bugs you miss will be the interaction-dependent kind that only appear in production.

Remove jQuery entirely

querySelector(), fetch(), addEventListener(), and classList cover most of what teams actually use jQuery for. If your usage is thin, dropping the dependency is the cleanest outcome, and doing it incrementally beats a full rewrite.

If it isn’t thin, price it honestly. You’re rewriting every DOM operation, reimplementing helpers, giving up jQuery’s normalization layer, and running the old system in parallel while you build the new one.

Extended support while you modernize

Some applications can’t be upgraded on the schedule a disclosure imposes, but also can’t sit unmaintained. TuxCare’s Endless Lifecycle Support for jQuery covers unsupported releases including 1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1, 3.4.1, ,delivered through npm.

The point isn’t to keep you on an old release. It’s to separate the security deadline from the migration deadline.

Three questions usually settle it:

Clean dependency graph, real test coverage, no abandoned commercial plugins? Upgrade to 4.0.0 and be done.
jQuery only doing $() and .on() across a handful of files? Remove it. Don’t pay to support code you don’t need.
Unmaintained plugins, a frozen browser requirement, or a migration that realistically lands two quarters out? Extended support, and plan the upgrade properly.

What Rushing It Costs

When a KEV listing or a failed audit compresses a major migration into an unrealistic window, the failure modes are predictable enough to name in advance.

Support load goes first: forms that don’t submit, dropdowns that don’t open, Ajax that fails silently, much of it tracing to version behavior differences rather than anything in your diff. Then stability, usually a plugin edge case that only appears under production concurrency. Then debt, because under deadline pressure refactoring gets deferred and “we’ll clean this up next quarter” becomes permanent. Then budget: contractor hours, delayed roadmap, and your best frontend engineers spending weeks on compatibility work.

Planned upgrades are good. Panic-driven upgrades are a different activity with a different cost structure, and teams routinely underestimate them by a factor of two or more.

How TuxCare Patches EOL jQuery

Extended support is more than republishing an old package, and the hard part is the backport itself. A fix written against a current branch often depends on later refactoring, different tests, or browser assumptions that don’t exist in the target version. The patch has to preserve the security intent of the upstream change without dragging in unrelated behavior or breaking the compatibility that kept you on the old release.

Monitoring and analysis. TuxCare tracks NVD, vendor advisories, GitHub security feeds, and CISA’s KEV catalog, then determines whether a reported issue actually affects a covered version. Published version ranges alone aren’t sufficient; the vulnerable code path has to be reviewed.

Backporting and validation. Upstream fixes are adapted to the older codebase using automated tooling with security engineers validating the result, then tested for integrity, functionality, and regression before release. Packages are signed and delivered from TuxCare-hosted repositories. If you want the mechanics rather than the summary, TuxCare’s technical whitepaper on their Open Source Patching Process is more readable than most documents of its type.

Documentation. Each release records which CVEs were addressed and which components changed, with SBOM and VEX context so you can show which findings are already remediated. That’s the artifact an auditor wants, and it’s the difference between a closed finding and an open one.

For scale: TuxCare has delivered more than 220,000 patches and resolved more than 5,000 CVEs across operating systems, runtimes, libraries, and applications over about 15 years.

Start With an Inventory

Before evaluating any option, find out what you’re actually running. Check source trees, built bundles, package manifests, CDN references, CMS plugins, vendor libraries, and rendered production pages. Don’t assume the version your application declares is the only one reaching users.

For each instance, record the exact version, the component using it, whether it loads directly or through another product, what depends on it, which client environments must keep working, and how much regression testing a change would require. Once that exists, easy upgrades separate cleanly from high-risk ones.

Then check coverage for your specific versions using TuxCare’s live CVE tracker, which lists what has already been patched. For supported releases, pricing, and implementation details, see TuxCare’s Endless Lifecycle Support for jQuery page.

The Next Chapter

jQuery’s persistence isn’t evidence that a library overstayed its welcome. It’s evidence of how completely it solved a foundational problem, to the point where the platform eventually absorbed much of what it did. 4.0.0 shows the project is still moving.

Millions of lines of production code were written during earlier chapters of that history, though, and those move at different speeds. Some can upgrade this quarter. Others are tied to business-critical applications, abandoned plugins, kiosk and embedded browsers, or modernization programs measured in years.

Move to supported software when you can. When you can’t do it immediately, know exactly which versions you’re running and put a real maintenance plan behind them. The Ecosystem Sustainability Program exists so that plan doesn’t have to mean asking volunteers to patch 2016 releases forever.

Visit TuxCare’s Endless Lifecycle Support for Open-Source Software to see how extended support can cover the rest of your open-source stack for as long as you need it.

Summary