Yes — jQuery 1.10.2 vulnerabilities are real and current, not theoretical. Released in June 2013, version 1.10.2 predates every major security fix jQuery has shipped since: the cross-domain ajax XSS fix in 3.0.0, the prototype pollution fix in 3.4.0, and the htmlPrefilter XSS fixes in 3.5.0. If 1.10.2 is still running anywhere in your stack — often bundled inside an old plugin or vendored asset nobody's touched in years — it carries every one of those unpatched issues at once.
Which specific CVEs affect jQuery 1.10.2?
Three well-documented CVEs apply directly. CVE-2015-9251 is a cross-site scripting issue in jQuery's $.ajax() cross-domain handling, fixed in version 3.0.0 — since 1.10.2 predates that fix by three major versions, it's exposed. CVE-2019-11358 is a prototype pollution vulnerability in $.extend() when performing a deep merge with attacker-controlled input, fixed in 3.4.0; this one matters beyond XSS because prototype pollution can, depending on how a downstream application uses polluted objects, lead to broader logic corruption or in some app-specific cases further exploitation. CVE-2020-11022 and CVE-2020-11023 are both XSS issues in jQuery's htmlPrefilter — the function responsible for handling HTML strings passed to methods like .html() and .append() — fixed in 3.5.0, and both apply to any version before that, including 1.10.2. Put together, an application still serving jQuery 1.10.2 is running code with at least four known, fixed-elsewhere XSS and prototype pollution issues sitting active in production.
How does jQuery 3.2.1 compare — is it actually safer?
Somewhat, but not by much. jQuery 3.2.1, released in 2017, already includes the fix for CVE-2015-9251 since that landed in 3.0.0, so that specific cross-domain XSS issue doesn't apply. But 3.2.1 still predates both 3.4.0 and 3.5.0, meaning it remains exposed to CVE-2019-11358 (prototype pollution) and both CVE-2020-11022 and CVE-2020-11023 (htmlPrefilter XSS). This is a useful distinction for anyone triaging a scanner report: "jQuery 3.2.1 vulnerabilities" and "jQuery 1.10.2 vulnerabilities" overlap on three CVEs but differ on one, and neither version is safe to treat as current.
What about jQuery UI 1.13.2 — is that version actually vulnerable?
This is where a lot of scanner-driven confusion happens, because jQuery UI 1.13.2 is largely a different story from jQuery core. The three CVEs most commonly associated with jQuery UI — CVE-2021-41182, CVE-2021-41183, and CVE-2021-41184, all XSS issues in Datepicker and related components — were fixed in jQuery UI 1.13.0, released in September 2021. Since 1.13.2 is a later patch release on top of 1.13.0, it already contains those fixes. If a scan flags jQuery UI 1.13.2 for those specific CVE IDs, that's worth double-checking against the actual fix-version metadata before treating it as an active finding — it's a common source of false-positive noise in dependency scanning, distinct from jQuery core versions like 1.10.2 or 3.2.1, which are genuinely unpatched for the issues discussed above.
How do other jQuery versions stack up against these same CVEs?
The same three fix points — 3.0.0, 3.4.0, and 3.5.0 — determine exposure for every jQuery release, not just 1.10.2 and 3.2.1. Here's how several commonly-flagged versions line up, based strictly on which fix each version does or doesn't include:
| Version | CVE-2015-9251 (fixed 3.0.0) | CVE-2019-11358 (fixed 3.4.0) | CVE-2020-11022/11023 (fixed 3.5.0) |
|---|---|---|---|
| 1.11.1 | Vulnerable | Vulnerable | Vulnerable |
| 1.12.4 | Vulnerable | Vulnerable | Vulnerable |
| 2.2.4 | Vulnerable | Vulnerable | Vulnerable |
| 3.2.1 | Fixed | Vulnerable | Vulnerable |
| 3.3.1 | Fixed | Vulnerable | Vulnerable |
| 3.4.1 | Fixed | Fixed | Vulnerable |
| 3.5.0 | Fixed | Fixed | Fixed |
| 3.6.1 | Fixed | Fixed | Fixed |
| 3.6.4 | Fixed | Fixed | Fixed |
So jQuery 1.11.1, 1.12.4, and 2.2.4 vulnerabilities all follow the 1.x/2.x pattern above — every fix from 3.0.0 onward is missing, exactly like 1.10.2. jQuery 3.3.1 vulnerabilities mirror 3.2.1's exposure. Versions 3.4.1 and later close the prototype pollution issue but 3.4.1 specifically still needs the 3.5.0 htmlPrefilter fix. By 3.5.0, 3.6.1, and 3.6.4, all three of the CVEs discussed in this post are patched — though as always, "patched against these three" isn't the same as "patched against everything ever disclosed," so it's still worth checking a current CVE feed against your exact version rather than treating this table as a permanent clean bill of health.
What should you actually do if you find old jQuery in your stack?
Upgrade to the current 3.x line first, since every relevant fix (3.0.0, 3.4.0, 3.5.0) is already included in any release from 3.5.0 onward, and jQuery has maintained strong backward compatibility across the 3.x series for most common usage patterns. If a hard upgrade is blocked by a legacy plugin dependency, isolate and audit every call site that passes user-controlled input into .html(), .append(), $.extend(), or $.ajax() with cross-domain requests — those are the exact functions the CVEs above target, and manually reviewing those call sites can meaningfully reduce exposure while a full version upgrade is scheduled. Don't rely on a Content Security Policy alone to compensate; a strict CSP helps limit the blast radius of a successful XSS but doesn't prevent the underlying DOM-based injection these CVEs describe.
How Safeguard Helps
Safeguard's SCA scanning identifies exact jQuery and jQuery UI versions across your codebase, including copies bundled inside older plugins that manual package.json audits typically miss, and maps each one against the specific CVE IDs and fix versions that actually apply — distinguishing genuinely exposed versions like 1.10.2 from patched ones like jQuery UI 1.13.2 that scanners sometimes flag incorrectly. See the SCA product page for how version-and-fix mapping works across frontend dependencies.
FAQ
Is jQuery 1.10.2 still safe to use if the site has no user input fields?
It's lower risk but not zero risk — CVE-2020-11022 and CVE-2020-11023 can be triggered through any HTML string reaching .html() or similar methods, including content from a CMS, third-party widget, or URL parameter, not just direct form fields.
Does upgrading from 1.10.2 straight to the latest 3.x version break things?
Often yes for older codebases — jQuery 3.x dropped support for some legacy browser-compatibility shims present in the 1.x line, and plugins written against 1.x APIs sometimes need updates. jQuery's official migration guide documents the breaking changes to check against.
Are jQuery vulnerabilities still actively exploited today?
Yes, in the sense that automated scanners and opportunistic attackers routinely probe for old, unpatched jQuery versions on public-facing sites, since it remains one of the most widely deployed JavaScript libraries in existence and many sites never revisit vendored frontend assets.
How do I check which jQuery version a live site is actually running?
Most versions expose it via jQuery.fn.jquery in the browser console, or it can be inferred from the file path or a version comment at the top of an unminified jquery.js file if one is served directly.