Known-Vulnerable JavaScript Libraries
Most websites load third-party JavaScript libraries: jQuery, Bootstrap, Angular, Lodash, Moment and many others. When a security flaw is found in one of them, it is fixed in a new release and published with a description and usually a CVE identifier. Sites that keep loading an old release keep the flaw.
Why it matters
Library code runs with full access to your page. A flaw in a widely used library, often a cross-site scripting issue in how it handles HTML or URLs, can be exploitable on every site that uses the affected version in the affected way. Because the details are public, finding sites that still load an old version is easy to automate.
Not every published vulnerability is exploitable on every site: many only apply if you call a particular function with untrusted input. Working out whether yours is affected usually takes longer than upgrading, so upgrading is the practical default.
What we check
| Check | Passes when |
|---|---|
| No known-vulnerable JavaScript libraries | no <script src> URL on the page matches a library version with known issues |
We take the src URL of every <script> tag in the page’s HTML and match it against the
Retire.js vulnerability database, which maps library names
and versions to published vulnerabilities. A match needs the library name and version to appear in
the URL or the file name, for example:
https://code.jquery.com/jquery-3.4.1.min.js
https://cdn.jsdelivr.net/npm/bootstrap@4.1.0/dist/js/bootstrap.min.js
The report lists each matched library, the version we detected, and the vulnerabilities that apply, with their severity and CVE identifiers where available.
We never download your scripts. The check works only from the URLs in your HTML. That keeps it passive, but it has limits:
- Libraries bundled into your own files (for example
app.3f9a1c.jsbuilt with webpack or Vite) are invisible to it. - A library served under a name without its version, such as
/js/jquery.min.js, cannot be matched. - If you patched a library yourself but kept the old version in its file name, you may see a match that does not apply.
A pass therefore means “no vulnerable versions visible in script URLs”, not “no vulnerable code”.
How to fix
- Upgrade each listed library to the latest release of its current major version at least, and preferably to the latest supported release. Check each CVE or the library’s changelog to find the release that fixed it.
- Read the release notes before a major upgrade. Major versions can change behavior. For jQuery, the official jQuery Migrate plugin logs deprecated usage while you test.
- Remove what you no longer use. Old themes and plugins often keep loading libraries the page does not need anymore. The safest library is one you do not load.
- Update the CMS plugins and themes that bundle them. On WordPress and similar systems, many old libraries come from plugins. Updating or replacing the plugin is the fix.
Check bundled dependencies too
Since this check cannot see inside your bundles, scan your project’s dependencies directly:
npm audit
Most package managers have an equivalent (yarn npm audit, pnpm audit). Automated dependency
update tools on your code host can open pull requests when fixes are released.
Loading from a CDN
If you load libraries from a public CDN, pin an exact version (as in the examples above) so you know what you are running, and add Subresource Integrity so the browser refuses a file that has been tampered with:
<script
src="https://cdn.example.com/lib@1.2.3/lib.min.js"
integrity="sha384-…"
crossorigin="anonymous"
></script>
Most CDNs show the integrity value next to each file. Remember to update it whenever you change the version.
Keep it current
Library vulnerabilities are published continuously, so a page that passes today may not pass in a few months. Schedule regular dependency updates, and re-scan after you change themes, plugins or front-end tooling.
Further reading: OWASP: Vulnerable Dependency Management Cheat Sheet.