# Fix an outdated jQuery or other JavaScript library that fails your PCI ASV scan (/en/blog/pci-asv-scan-outdated-javascript) Your quarterly PCI scan came back as a fail, and the finding is an outdated jQuery, or another JavaScript library, on a page you thought was up to date. The fix is usually quick once you know which copy the page loads and where it comes from. This post explains why the scan fails on it, how to find the copy, what to upgrade to, how to rescan, and when a dispute is the right answer instead. ## Why an outdated JavaScript library fails a PCI ASV scan [#why-an-outdated-javascript-library-fails-a-pci-asv-scan] PCI DSS requires many merchants to run a quarterly external vulnerability scan through an Approved Scanning Vendor (ASV), a company listed by the PCI Security Standards Council. The ASV Program Guide sets the pass rule: any component with a vulnerability scored CVSS 4.0 or higher fails the scan, unless you remediate it or the ASV accepts a dispute. That is why jQuery shows up so often. The common jQuery advisories all score 6.1 on the National Vulnerability Database (NVD): | CVE | NVD CVSS base score | Fixed in | | ----------------------------------------------------------------- | ------------------- | -------- | | [CVE-2020-11022](https://nvd.nist.gov/vuln/detail/CVE-2020-11022) | 6.1 | 3.5.0 | | [CVE-2020-11023](https://nvd.nist.gov/vuln/detail/CVE-2020-11023) | 6.1 | 3.5.0 | | [CVE-2019-11358](https://nvd.nist.gov/vuln/detail/CVE-2019-11358) | 6.1 | 3.4.0 | | [CVE-2015-9251](https://nvd.nist.gov/vuln/detail/CVE-2015-9251) | 6.1 | 3.0.0 | Every one is above 4.0, so a page that loads jQuery before 3.5.0 fails the scan on these alone. The same rule applies to any other library: an old Bootstrap, Lodash, Moment.js, or AngularJS copy with a CVE scored 4.0 or higher fails the same way. For what each jQuery advisory does and which versions it covers, see [Which jQuery versions are vulnerable](/en/blog/vulnerable-jquery-version). The Program Guide also lists conditions that fail a scan whatever their score, unsupported operating systems among them. Whether your ASV treats an end-of-life library line the same way is up to each vendor, so ask yours, and plan to move off end-of-life lines such as jQuery 1.x and 2.x or AngularJS anyway. ## Find which copy the page loads [#find-which-copy-the-page-loads] The finding names a host and usually a URL. Before you upgrade anything, find out which copy of the library that page loads, because the version in your own bundle is often not the one the scanner saw. Old copies come from: * **A plugin or theme** that bundles its own jQuery, common on WordPress and other CMS sites. * **A vendor widget** (chat, reviews, payments, analytics) that loads its own copy. * **A CDN line in an old template** that pins a version nobody updated. * **A second copy** loaded next to your current one, so upgrading the first changes nothing. Run the page the finding names through the [Technology Checker](/tools/tech-checker). It lists each library with its version, the known CVEs affecting that version, the version that fixes each one, and where the library was detected, which tells you who owns the fix. Check the other pages in scope too, payment and login pages first, since the ASV scans more than the one URL in the finding. ## Upgrade or remove the copy [#upgrade-or-remove-the-copy] Work through each copy the check found: 1. **Your own copy.** Upgrade to the current release of the library. For jQuery that is a current 3.x release; [jQuery Migrate](https://github.com/jquery/jquery-migrate) restores removed APIs during the move, but it does not patch the CVEs, so the core still has to change. 2. **A plugin or theme copy.** Update the plugin or theme first. If the current release still bundles the old copy, dequeue it and let your CMS core copy serve, or replace the plugin. 3. **A vendor widget copy.** Ask the vendor for an updated tag. If they will not update it, the widget is the finding, and removing it from in-scope pages is the fix. 4. **A copy nothing uses.** Delete the script tag. Then check the page again and confirm that the version served is the new one. Caching layers and CDNs keep serving the old file for a while after a deploy. ## Rescan with your ASV [#rescan-with-your-asv] Request a rescan from your ASV once the fixed version is live on every in-scope page. A passing report needs no remaining findings at 4.0 or above, so fix every library the first scan listed before you rescan, not only the first one. The checker is a pre-check, not a scan. It shows which library versions a page loads and which advisories apply, but a clean check is not proof of a clean ASV scan: the ASV uses its own detection, scans every component in scope, and only its report counts for PCI DSS. ## When a dispute is legitimate [#when-a-dispute-is-legitimate] Not every finding needs an upgrade. ASVs accept disputes, and the usual categories are: * **False positive.** The finding is wrong: the library is not loaded, or the version the scanner read is not the version served. Some vendors also backport a security fix without changing the version string. Evidence is a configuration file, a screen capture, or a vendor advisory confirming the backport, with when and how you obtained it. * **Compensating control.** The vulnerable code path is blocked by another control that meets the intent of the requirement, documented with the compensating controls worksheet in PCI DSS Appendix C. * **Exception.** The failure does not affect the cardholder data environment, for example a disputed score or a component out of scope. A Technology Checker export (the dated PDF, or the CycloneDX file) can support a false-positive dispute by showing which versions a page loaded on a given date. Treat it as supporting evidence only. The ASV decides what it accepts, and a dispute without a real reason only moves the problem to the next quarter. ## Keep it from coming back [#keep-it-from-coming-back] The library comes back when a plugin update reintroduces it, a new tag lands on a payment page, or a CVE is published for the version you just moved to. A quarterly scan finds that three months later. Continuous detection finds it the day it happens. Content Security Policy (CSP) hash reporting has your visitors' browsers report every script they run, and CentralCSP keeps an inventory of every library version across your pages, with an alert when an outdated or vulnerable one appears. [Build a script inventory with CSP hash reporting](/en/blog/script-inventory) covers the mechanism, and the [supply-chain page](/platform/supply-chain) has the tour. The same inventory is evidence for the PCI DSS v4 client-side requirements, which CentralCSP helps you meet; see [CSP and PCI DSS v4](/en/blog/csp-pci-dss-v4) and [PCI DSS v4 client-side requirements explained](/en/blog/pci-dss-v4-client-side-explained). ## FAQ [#faq] ### What is the minimum jQuery version to pass a PCI scan? [#what-is-the-minimum-jquery-version-to-pass-a-pci-scan] No PCI document names a minimum version. The rule is the CVSS score: a version with a known vulnerability scored 4.0 or higher fails. In practice, jQuery 3.5.0 and later has none of the common advisories listed above, so a current 3.x release is the target. ### Can I pass the scan by hiding the version number? [#can-i-pass-the-scan-by-hiding-the-version-number] No. Removing a version banner from the file does not remove the vulnerability, and ASVs can identify libraries from their content, not only from version strings. Upgrade instead. ### Does the Technology Checker replace my ASV scan? [#does-the-technology-checker-replace-my-asv-scan] No. Only an ASV listed by the PCI Security Standards Council produces a scan report that counts for PCI DSS. Use the checker before the scan to find and fix outdated libraries, and after a fix to confirm the new version is served. ### Why does the scan still fail after I upgraded jQuery? [#why-does-the-scan-still-fail-after-i-upgraded-jquery] Usually because a second copy is still loaded: a plugin, a theme, a vendor widget, or a cached file. Check the page again and look at every row the checker lists for the library, not only the first. ## Related [#related] * [Which jQuery versions are vulnerable](/en/blog/vulnerable-jquery-version) * [What a technology checker is for, from security ratings to PCI scans](/en/blog/technology-checker-use-cases) * [How to detect vulnerable JavaScript libraries on a live website](/en/blog/detect-vulnerable-javascript-libraries) * [Build a script inventory with CSP hash reporting](/en/blog/script-inventory) ## Sources [#sources] * [PCI Security Standards Council, ASV Program Guide](https://www.pcisecuritystandards.org/document_library/) * [Tenable, PCI ASV dispute reasons](https://docs.tenable.com/pci-asv/Content/pci-asv/DisputeReasons.htm) * [Halo Security, how to prepare for your first PCI ASV scan](https://blog.halosecurity.com/how-to-prepare-for-your-first-pci-asv-scan/) * [NVD, CVE-2020-11022](https://nvd.nist.gov/vuln/detail/CVE-2020-11022) * [NVD, CVE-2020-11023](https://nvd.nist.gov/vuln/detail/CVE-2020-11023) * [NVD, CVE-2019-11358](https://nvd.nist.gov/vuln/detail/CVE-2019-11358) * [NVD, CVE-2015-9251](https://nvd.nist.gov/vuln/detail/CVE-2015-9251) * [jQuery Migrate](https://github.com/jquery/jquery-migrate)