jQuery prototype pollution vulnerability re-emerges

A seven-year-old jQuery flaw is having a moment again. CVE-2019-11358, a prototype pollution vulnerability in jQuery's $.extend() merge utility, is the specific jQuery vulnerability behind most of these recurring hits, and it continues to surface in software composition analysis (SCA) scans across enterprise codebases in 2026 — not because a new variant was discovered, but because the vulnerable library never actually left production. Bundled copies inside legacy CMS themes, vendored admin dashboards, WordPress and Drupal plugins, and transitive npm dependencies that still pin jquery@<3.4.0 keep resurrecting this CVE every time a security team runs a fresh scan. The underlying issue is simple to describe and deceptively hard to fully eradicate: when jQuery.extend(true, target, source) performs a deep merge, it doesn't validate keys like __proto__ or constructor.prototype before copying them onto the target object. An attacker who can influence the source object — often via a JSON body, query string, or config payload parsed into JavaScript — can inject a __proto__ key and pollute Object.prototype itself, corrupting behavior for every object in the running application. Depending on what the host application does with polluted properties, the practical impact ranges from denial of service (crashing the app by overwriting expected properties) to client-side cross-site scripting when a polluted property flows into a DOM sink, to authorization bypass in server-side Node.js code that also happens to import jQuery for HTML templating or scraping tasks.

Affected Versions and Components

The vulnerability lives in jQuery core versions prior to 3.4.0. Any application, theme, plugin, or Node.js package that loads jQuery below that version through jQuery.extend() (and the related jQuery.fn.extend()) is exposed. The most common exposure vectors we see in real inventories are:

• Bundled/vendored copies — jQuery shipped as a static file inside a CMS theme, admin panel, or SaaS product's static assets, invisible to package-manager-based SCA tools because there's no package.json entry to flag.
• Transitive npm dependencies — build tooling, testing frameworks, and older UI component libraries that still declare jquery as a dependency and never bumped their floor version.
• CDN-pinned script tags — HTML pointing at jquery-3.3.1.min.js or earlier on a public CDN, often left over from a template that was never revisited after initial deployment.
• WordPress and Drupal plugin ecosystems — a large share of plugin-bundled jQuery copies predate 3.4.0 and are rarely updated independent of a full plugin refresh.

Notably, jQuery UI carries its own related history of object-injection and prototype-pollution-adjacent issues in widget option handling, which teams frequently confuse with the core library CVE during triage — worth double-checking which component (jQuery core vs. jQuery UI) actually appears in your bill of materials before scoping a fix.

CVSS, EPSS, and KEV Context

NVD scores CVE-2019-11358 as CVSS 3.x base score 6.1 (Medium), vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — network-exploitable, low attack complexity, no privileges required, but requiring user interaction and reflecting the "changed scope" nature of a client-side XSS-style outcome rather than a direct server compromise. That medium score is part of why the finding gets deprioritized in ticket queues — but it undersells the risk in two ways security teams should account for. First, the score models a single exploitation path (client-side gadget leading to XSS); server-side Node.js consumers that misuse jQuery for HTML parsing can see materially worse outcomes depending on what downstream code trusts polluted objects for. Second, ubiquity multiplies aggregate exposure: a medium-severity bug present in hundreds of internet-facing assets is a very different risk posture than the same bug in one.

On the exploit-likelihood side, EPSS scores for CVE-2019-11358 have historically sat in the low single-digit percentile range — reflecting that it's not a headline actively-exploited CVE, but prototype pollution as a bug class has proven weaponizable in the right context (chained with a gadget that reads the polluted property into a dangerous sink). It is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, which is another reason it tends to get backlogged rather than remediated on an emergency timeline. We'd caution against reading "not in KEV, not critical CVSS" as "safe to ignore" — the combination of low remediation cost, high asset prevalence, and a well-understood public exploitation technique makes this exactly the kind of finding that erodes an organization's risk posture through sheer accumulation rather than any single dramatic incident.

Timeline

• Pre-2019 — Prototype pollution as a JavaScript vulnerability class gains broader security research attention, following disclosures in libraries like lodash and minimist that share the same root cause: unsanitized deep-merge and deep-clone operations.
• April 10, 2019 — jQuery 3.4.0 is released, fixing the $.extend() prototype pollution issue by adding a check that rejects __proto__ keys during merges.
• May 2019 — CVE-2019-11358 is formally assigned and published, giving the fix a tracked identifier and pushing it into SCA tool databases.
• 2019–2022 — The CVE becomes a fixture of dependency-scanning "greatest hits" lists alongside other prototype pollution findings (lodash's CVE-2019-10744, minimist's CVE-2020-7598), as organizations run their first serious SCA rollouts and discover just how deep jQuery is embedded in legacy front-end stacks.
• 2023–2026 — Despite jQuery 3.4.0 being six-plus years old, the CVE continues to reappear in fresh scan results as organizations onboard new SCA/SBOM tooling, acquire companies with legacy tech debt, or simply re-scan assets that were never remediated after the original finding was triaged and shelved. Its persistence has made it something of an industry bellwether for measuring how much "known-vulnerable, never-fixed" debt sits in a given codebase.

Is This the Only jQuery Vulnerability Worth Tracking?

No — it's the most persistent one in dependency scans, but not the only jQuery vulnerability with a live CVE. jQuery UI's widget-option handling has its own history of object-injection issues, and older jQuery core releases carry separate, unrelated XSS findings in selector parsing. Treat CVE-2019-11358 as the highest-volume recurring finding, not the sole jQuery risk in your inventory.

Remediation Steps

1. Upgrade jQuery to 3.4.0 or later (3.7.x is current at time of writing) wherever the library is a direct dependency. This is a low-risk upgrade for the vast majority of applications, since the fix only changes merge behavior for a key most code never legitimately uses.
2. Inventory bundled and vendored copies, not just package-manager-declared dependencies. Search static asset directories, theme folders, and vendored /lib or /vendor paths for jquery files and check their version banners directly — SCA tools that only parse manifests will miss these.
3. Audit CDN references in HTML/templates for pinned legacy version strings (e.g., jquery-1.x, jquery-2.x, jquery-3.0 through 3.3.1) and bump them to a version-pinned 3.4.0+ URL rather than an unpinned "latest" reference that could silently break on future major bumps.
4. Patch or replace outdated CMS plugins and themes that bundle their own jQuery copy independent of the core platform's version — coordinate with plugin vendors or fork-and-patch if a vendor has abandoned updates.
5. Add a CI gate that fails builds when a dependency resolution includes jQuery below 3.4.0, so the fix doesn't regress the next time a transitive dependency graph shifts.
6. Validate reachability before triaging as urgent — if the vulnerable $.extend(true, ...) call path is never invoked with attacker-influenced input in your application (e.g., it's only used to merge trusted internal config objects), the practical exploitability is far lower than the CVSS score alone implies, and that context should drive ticket prioritization rather than a blanket "critical" label applied to every hit.

How Safeguard Helps

This is precisely the class of finding where blanket CVE lists create more noise than signal, and it's where Safeguard is built to help. Our reachability analysis traces whether the vulnerable jQuery.extend() call path in your specific codebase is actually invocable with attacker-influenced data, so teams stop spending remediation cycles on jQuery copies that are present but functionally unreachable. Griffin, our AI-driven vulnerability triage engine, correlates CVE-2019-11358 hits across your full asset inventory — including vendored and CDN-referenced copies that traditional manifest-based scanners miss — and ranks them by real exploitability rather than raw CVSS score. Safeguard's SBOM generation and ingestion capabilities give you a single source of truth for every jQuery instance across first-party code, vendored assets, and third-party plugins, closing the visibility gap that lets "fixed" vulnerabilities keep reappearing in future scans. And when remediation is warranted, Safeguard can open auto-fix pull requests that bump the dependency, update lockfiles, and flag any CDN references needing a manual template change — turning a recurring backlog item into a same-day merge.