Check any website for JavaScript libraries with known CVEs

Most scanners get this wrong, and the difference matters. They count every CVE the package ever had. jQuery has accumulated 8 CVEs across its lifetime, but a site running jQuery 1.8.2 is affected by only 5 of them; the rest were introduced later or fixed before it.

CheckWeb cross-references the detected version against the OSV and NVD advisory ranges and counts only the CVEs whose affected range includes that version, with the maximum severity computed over the same set. The result is a number worth acting on, not an alarmist lifetime total that falls apart the moment a developer checks it.

In a CheckWeb report, under the Security axis, this shows as a line reading "Vulnerable front-end libraries" with a red FAIL status. The evidence chip beneath names each library, version, per-version CVE count, and max severity: for example jQuery 1.8.2 with 5 known CVEs (max Medium) and Bootstrap 3.1.0 with 6 known CVEs (max Medium). A clean site shows PASS, "Recognized libraries have no known vulnerabilities." When no library version can be fingerprinted, the status is N/A, never a fake pass.

The fix is almost always moving to the latest patch of the current major, not a rewrite.

• Plain script tags or CDN: bump the version in the CDN URL (or the vendored copy) to the latest patch release of that major.
• npm or a bundler: update the dependency and rebuild. `npm audit` surfaces the same OSV advisories CheckWeb uses.
• WordPress: the library is usually bundled by a plugin or theme rather than added directly, so update those and drop any that ship ancient copies. (See the WordPress security check.)
• Then verify: re-scan and watch the Security axis recover.

Does a known CVE mean the site will be hacked?

No. A CVE means a published flaw exists in that version and the exploit is public, which is what makes it findable by automated scanners sweeping the web. Whether it is reachable depends on how the library is used. The reason to treat it as urgent is cost: upgrading a front-end library is usually a version bump, while triaging exactly which CVE is exploitable takes longer than the upgrade would.

The library loads from a CDN. Is that still a problem?

Yes. The CVE belongs to the version, not to the place it is hosted. A page pulling jQuery 1.8.2 from a public CDN ships the same flawed code as one serving it locally, and the fix is the same: point the URL at a current patch release.

Can a bundled or renamed library still be detected?

Sometimes. Detection reads version fingerprints from the served files, so a library concatenated into one large bundle or stripped of its version comment can go unrecognized. When no version can be fingerprinted the check reports N/A rather than a pass, because an undetected library is an unknown, not a clean result.

Why is the CVE count lower than other scanners report?

Most tools total every CVE a package ever had. CheckWeb counts only the CVEs whose affected range covers the detected version, using the OSV and NVD ranges. jQuery has 8 CVEs across its lifetime, but 5 of them reach a site running 1.8.2, and that smaller number is the one worth acting on.

• WordPress security checkOn WordPress the vulnerable library usually arrives inside a plugin or theme, and the core version carries its own CVE record.