The fix, in one snippet
npm audit fix
npm ls jqueryIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now identifies libraries from version numbers in script URLs (/jquery-1.12.4.min.js, /ajax/libs/lodash.js/4.17.15/), from the version banner in the first few lines of same-origin script files it fetches (/*! jQuery v1.12.4), and from known file-content fingerprints. Each detected library and version is compared against a Retire.js-style vulnerability repository that lists affected ranges with CVE identifiers, and the finding reports the library, the version seen, the matching CVEs and the highest associated severity. Examples of what triggers it: jQuery below 3.5.0 (CVE-2020-11022, CVE-2020-11023), Bootstrap below 3.4.1 or 4.3.1 (CVE-2019-8331), Lodash below 4.17.21 (CVE-2020-8203, CVE-2021-23337), Moment.js below 2.29.4 (CVE-2022-31129), jQuery UI below 1.13.2 (CVE-2022-31160), and any AngularJS 1.x, which reached end of life in January 2022. Nothing is executed; detection is by string matching.
Why it matters
OWASP lists vulnerable and outdated components as A06 in the Top 10:2021 for a reason: a page that ships an old library ships its known bugs, with public write-ups and often public proof-of-concept code. Most front-end library CVEs are cross-site scripting or prototype pollution. They are exploitable only when your code passes attacker-influenced input to the affected function, for example jQuery's .html() with a user-supplied string, or a Bootstrap tooltip whose title comes from a database field, so a detection is a "possibly vulnerable" rather than a confirmed hole. Attackers do not need certainty; they try the known payload and move on if it fails. End-of-life libraries are worse: new bugs are found and never fixed. The outdated libraries guide explains how to confirm exploitability and upgrade safely, and the CVE and CVSS guide explains the scores.
How to fix it
Upgrade to a patched version, using the library's migration notes (jQuery Migrate helps with 1.x to 3.x). Run the same detection locally to see everything at once:
npx retire --path ./public
npm auditPin updated versions in package.json and let a bot keep them current (Dependabot or Renovate). When a transitive dependency drags in an old version, force it:
{
"overrides": { "lodash": "4.17.21" }
}For CDN-loaded scripts, change the version in the URL and update the SRI hash:
<script src="https://code.jquery.com/jquery-3.7.1.min.js"
integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
crossorigin="anonymous"></script>WordPress sites: core has shipped jQuery 3.x since version 5.6, so an old copy comes from a theme or plugin that bundles its own; update or replace it. Remove libraries no page still uses, which is often a third of what a legacy site loads. Re-scan with the JavaScript scanner to confirm.
Where this fits
JavaScript library with known vulnerabilities is check 2 of 10 that the website vulnerability scanner runs under page content and javascript, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Form submits over HTTP (high), where a form on the page submits to a plain-HTTP URL. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
JavaScript library with known vulnerabilities closes one route in. Immediately below it: Mixed content (HTTP resources on an HTTPS page), where the HTTPS page loads scripts, styles, frames or media over plain HTTP; Advertising and tracking endpoints, where which of the page's third-party hosts exist to advertise to the visitor or to follow them, matched against the EasyList and EasyPrivacy blocklists that also power our <a href="/ad-blocker">ad blocker</a>; CMS / generator version disclosure, where the page announces the CMS or static-site generator it was built with, usually including the version, in a meta tag, header or comment banner.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: JavaScript library with known vulnerabilities (high severity)
Scanner check id: outdated-javascript-libraryThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
References
Related guides
8 min read · Updated Sep 20, 2026
Outdated JavaScript Libraries: Why Old jQuery and Angular Are a Real Risk and How to Find Them
A page that ships an old library ships its known vulnerabilities. How Retire.js-style detection works, the most common vulnerable...
Read the guide
9 min read · Updated Sep 16, 2026
CVE and CVSS Explained: How Vulnerabilities Are Named, Scored and Prioritised
Every public vulnerability gets a CVE identifier and usually a CVSS score. How the numbering works, what the score measures and does...
Read the guide