There are no published CVEs against jQuery core at version 3.6.0, so most reports of jQuery v3.6.0 vulnerabilities are pointing at something adjacent to the library rather than the library itself. The last security fixes to land in jQuery core were CVE-2020-11022 and CVE-2020-11023, both cross-site scripting issues resolved in 3.5.0 — a full release before 3.6.0 shipped in March 2021. That does not mean every finding against 3.6.0 is noise. It means you need to read the finding carefully, because the real problem is usually a plugin, a stale bundled copy, or an end-of-life policy, and each of those has a different fix.
What jQuery 3.6.0 actually fixed and inherited
jQuery's security history in the 3.x line is short and specific. Version 3.4.0 closed the prototype pollution issue in jQuery.extend (CVE-2019-11358). Version 3.5.0 closed two XSS vectors: CVE-2020-11022, where regex-based HTML sanitization in htmlPrefilter could be bypassed, and CVE-2020-11023, where passing <option> elements from untrusted sources into DOM manipulation methods could execute code. By the time 3.6.0 was cut, all of those were behind it.
Databases agree on this. Snyk's advisory page for jquery@3.6.0 lists no direct vulnerabilities, and NVD has no CVE whose affected range includes 3.6.0 for jQuery core. The 3.6.x point releases that followed — 3.6.1 through 3.6.4 — were bug-fix releases, not security releases. If someone on your team is searching for "jquery 3.6.3 vulnerabilities" after a scanner upgrade, the answer is the same: nothing published against core at that version either.
So why is your scanner flagging it?
When a report cites jquery 3.6 0 vulnerabilities, one of four things is usually happening.
1. The finding is against a jQuery plugin, not jQuery. jQuery UI (Datepicker XSS in CVE-2021-41182/41183/41184, checkboxradio XSS in CVE-2022-31160) and jQuery Validation are separate projects with their own CVE histories. Tools that fingerprint JavaScript files sometimes roll these up under a generic "jQuery" component name, and the remediation is to upgrade the plugin, not core.
2. A stale copy is bundled somewhere in the artifact. jQuery's own repository famously ships test/data/jquery-1.9.1.js as a test fixture, and plenty of applications carry ancient minified copies in vendor/, static/legacy/, or inside a packaged theme. A file scanner walks the whole artifact, finds jquery-1.9.1.js, and correctly reports the CVEs that apply to 1.9.1 — the report just gets misread as being about your primary 3.6.0 copy.
3. Policy findings, not vulnerability findings. Some scanners raise informational or license-hygiene flags — Black Duck, for example, has flagged jQuery 3.6.0 over commented references to a hijacked domain in source comments. These are worth reading but they are not exploitable conditions in your application.
4. Outdated-dependency policy. Organizations that enforce "no dependencies more than N versions behind" will flag 3.6.0 simply because 3.7.x has been current since 2023. That is a legitimate maintenance signal even with zero CVEs attached.
Triage: confirm what you are actually running
Before filing an upgrade ticket, verify what the scanner saw. In the browser console:
jQuery.fn.jquery
// "3.6.0"
Then check for duplicate copies in the built artifact:
grep -rl "jQuery v" dist/ | xargs grep -h "jQuery v" | sort -u
If that prints more than one version banner, you have found the real finding. Multiple jQuery copies on one page are also a functional hazard — plugins bind to whichever instance loaded last — so consolidating them is worth doing regardless of the security report. A software composition analysis tool that resolves findings to a file path, such as Safeguard's SCA, makes this distinction visible instead of leaving you to guess which of five bundled copies triggered the alert.
The fix: upgrade to 3.7.x, and mind the migration details
Even with no CVE forcing your hand, moving off 3.6.0 is cheap and removes the recurring triage cost. The 3.6-to-3.7 jump is small: 3.7.1 is a drop-in replacement for almost all applications. The changes that occasionally bite are the removal of the deprecated jQuery.fn.hover shorthand pattern in some plugin code paths and Slim-build differences if you switched bundle flavors.
npm install jquery@3.7.1
For CDN users, update the pinned version and the Subresource Integrity hash together:
<script src="https://code.jquery.com/jquery-3.7.1.min.js"
integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo="
crossorigin="anonymous"></script>
Pinning an exact version with an SRI hash also protects you from the class of CDN-tampering incidents that have hit JavaScript delivery networks — arguably a bigger real-world risk for jQuery consumers than any 3.x core CVE.
Don't stop at core: audit the plugin ring
Because most genuine findings against "jQuery" are plugin findings, finish the job:
- jQuery UI: anything below 1.13.2 carries known XSS CVEs; upgrade to 1.13.2 or later.
- jQuery Validation, DataTables, select2, old carousel/lightbox plugins: check each against its own advisory feed rather than assuming core's clean bill covers them.
- Abandoned plugins: a plugin last published in 2016 will never receive a fix. Treat unmaintained UI plugins the way you treat unmaintained server-side dependencies — replace or vendor-and-own them.
This is where transitive visibility earns its keep. Manifest-only scanning misses jQuery entirely in many legacy apps because the file was copied into the repo by hand a decade ago, with no package.json entry to resolve.
When 3.6.0 is genuinely a risk
Two scenarios justify treating a jQuery 3.6.0 finding as more than hygiene. First, if your application passes untrusted HTML strings into jQuery manipulation methods (.html(), .append(), $(userControlledString)), you have an XSS exposure that no jQuery version fully protects against — the 3.5.0 fixes narrowed specific bypasses, they did not make HTML injection safe. Audit those call sites; that pattern review is covered in our Academy material on DOM XSS. Second, if you are pinned to 3.6.0 because of a plugin that breaks on newer jQuery, the pin itself is the finding: it means your upgrade path is blocked, and the next real core CVE will catch you flat-footed.
FAQ
Does jQuery 3.6.0 have any known CVEs?
No CVE has been published against jQuery core at version 3.6.0. The most recent core security fixes were CVE-2020-11022 and CVE-2020-11023, both fixed in 3.5.0, which predates 3.6.0.
Are jquery 3.6.3 vulnerabilities any different from 3.6.0?
No. The 3.6.1–3.6.4 point releases were bug-fix releases with no security content, and no CVEs have been published against them either. The same triage logic applies: check plugins and bundled copies.
Should I still upgrade if there is no CVE?
Yes, when convenient. 3.7.1 is a low-risk drop-in upgrade, removes recurring scanner noise, and keeps you positioned for future security releases. Staying several versions behind turns the next real advisory into an emergency migration.
Why does my scanner report old jQuery when I only ship 3.6.0?
Almost always a second copy: a test fixture, a vendored theme, or a legacy page still referencing an old CDN URL. Search your built artifact for every jQuery version banner and remove or upgrade the extras.