Loading...
Loading...
Front-end libraries you dropped in years ago (old jQuery, AngularJS 1.x, Bootstrap 3, Moment, Lodash) keep serving their publicly documented vulnerabilities to every visitor until you upgrade them. The version number is baked into the file you ship, so anyone can read it and look up the matching flaws.
Known vulnerabilities in shipped library versions are the lowest-effort target on the web. Attackers do not need to find a new bug: they fingerprint your loaded libraries (exactly like WebShield does), match the version against a public database, and fire an off-the-shelf exploit. The common outcomes are cross-site scripting (a stale library exposes an HTML sink that lets attacker input execute as script and steal sessions), prototype pollution (a crafted payload writes to `Object.prototype` and corrupts application logic, sometimes escalating to XSS or auth bypass), and ReDoS (a malicious string hits catastrophic regex backtracking and pins a CPU core, taking the page down). Because the library still renders your UI, nothing looks broken, which is exactly why these findings sit unpatched for years.
WebShield fingerprints each loaded script by filename (`jquery-1.12.4.min.js`), by version constants inside the file, and by content signatures, then checks the resolved version against the OSV.dev database (the open-source vulnerability feed that aggregates GitHub Security Advisories and language and distro ecosystem databases). OSV expresses each advisory as affected version ranges, so a match means your exact version falls inside a known-vulnerable range, not a guess. Two structural issues make this category persistent. First, end-of-life projects get no patches at all: AngularJS 1.x reached the end of its official support on 31 December 2021, and Bootstrap 3 is likewise unsupported, so there is no fixed version to upgrade to (the only remediation is migration or removal). Second, bundlers inline these libraries into `main.[hash].js`, so the vulnerable code and its version are frozen into your build artifact and ship on every deploy until you bump the dependency and rebuild. Historically, jQuery before 3.5.0 shipped an HTML-parsing XSS in its `htmlPrefilter` handling, and several Lodash versions carried a `Object.prototype` pollution flaw: both are the kind of high-CVSS, widely-scanned issues that OSV tracks. Severity here follows the underlying advisory (CVSS), not the library's popularity.
WebShield fingerprints your loaded libraries and matches them against OSV.dev. You can reproduce this: the version is visible in the page source (filenames like jquery-1.12.4.min.js or a version constant inside the file), readable at runtime from the library's own version property, and confirmable with a local Retire.js scan.
curl -s https://yourdomain.com | grep -oiE '(jquery|angular|bootstrap|lodash|moment|vue|react)[.-][0-9]+\.[0-9]+\.[0-9]+'jQuery.fn.jquery // jQuery
angular.version.full // AngularJS 1.x
bootstrap.Tooltip.VERSIONnpx retire --path ./publicBecause 'works' and 'safe' are unrelated. Known vulnerabilities are latent code paths triggered by attacker-controlled input, not by normal use. Attackers scan the whole web for fingerprinted versions and run pre-built exploits, so a visibly healthy page running a flagged version is precisely the easy target they look for.
It reads the version straight from what you ship: versioned filenames (jquery-1.12.4.min.js), version constants embedded in the file, and content signatures. It then checks that exact version against the OSV.dev database of affected version ranges. No guessing and no access to your source is needed, which is the same visibility an attacker has.
npm audit only inspects packages recorded in your lockfile. A library added as a raw CDN <script> tag or copied into a /vendor folder is invisible to it. WebShield looks at the assets the browser actually loads, so it catches those out-of-band copies. Fix them by bringing the library into your package manager or removing it.
Treat it as unsafe until proven otherwise. Reachability analysis is hard: a sink can be reached transitively, through a plugin, or via prototype pollution that alters unrelated code. Upgrading to the patched version is far cheaper and more reliable than proving a given code path can never execute.
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.