Update the vulnerable JavaScript library
Why it matters
The page loads a JavaScript library version with a published vulnerability, and attackers scan for these. Updating to the fixed release closes the hole without changing how the site looks.
Staged change. Do this in stages and check each one before the next, so a mistake does not break your site or your mail.
The fix
- Find where the library comes from. Search the page source for the script address named in the finding. It is either a script tag that points at a CDN, a file in your own bundle built from npm or yarn, or a file shipped by a theme, plugin or third-party widget.
- If you build it from npm or yarn, update it and rebuild. Use npm install <package>@<fixed version> (or yarn upgrade <package> --latest), run your tests, and commit the lock file. The finding names the fixed version.
- If a script tag loads it from a CDN, change the version in the address to the fixed one, and add an integrity hash and crossorigin so the browser rejects a tampered file. Generate the hash with curl -s <script address> | openssl dgst -sha384 -binary | openssl base64 -A and put sha384- in front of it.
- Test the site on a staging copy before you deploy. A big jump (for example a jQuery major version) can remove functions that old plugins use. Do not simply delete the library unless you have checked that nothing uses it.
- If another product ships the old copy (a theme, plugin or widget), update that product, or ask its vendor for a fix, or replace it. Then rescan to confirm the old version is gone.
html
<script src="https://cdn.jsdelivr.net/npm/<package>@<fixed-version>/<path-to-file>" integrity="sha384-<hash of exactly this file>" crossorigin="anonymous"></script>
Related
- Reported by the javascript libraries with known vulnerabilities check
Scan your domain to see whether this applies to you.