A JavaScript library has known security holes

SeverityHigh

ScopeWhole site

EffortMedium

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_js_vulnerable

Short answer

A script your site loads is a library version with known security holes listed in the retire.js database. The issue shows the library, the version found, the CVEs and the version that fixes them. Update the library to at least that version; if a theme or plugin ships it, update that theme or plugin.

Why it matters

Old library versions carry documented flaws, for example cross-site scripting in jQuery before 3.5.0 or in Bootstrap before 3.4.1 and 4.3.1, and prototype pollution in old lodash. Whether a given flaw is exploitable on your site depends on whether your code passes untrusted input to the affected function, so not every finding is an open door. But the version is visible to anyone, security questionnaires and payment-card scans flag it, and an XSS on your domain can steal sessions or rewrite pages.

How Glimana detects it

Glimana collects the script addresses on your home page and two sample pages, plus up to 400 .js files already known from crawling your site. It recognises library and version from the address or file name (for example jquery-1.12.4.min.js) and, for up to six unrecognised scripts, from the licence header in the first 4 KB; a WordPress ?ver= value is used only when the file name is exactly the library name. Versions are compared with the retire.js vulnerability repository (Apache-2.0), refreshed weekly. The severity is that of the most serious vulnerability found, with critical reported as high. Code bundled into your own files without a header is not detected. Before the data has loaded, the check shows Not running yet.

How to fix it

Watch out

Major-version jumps can break old code; jQuery 3 removed several APIs older plugins use. Test the pages that use the library after updating. In WordPress, the jQuery in /wp-includes/ is updated with core; an outdated copy usually comes from a theme that deregisters core jQuery and loads its own. If you load from a CDN with an integrity hash, change the hash together with the version, and purge your cache so the old file stops being served.

Find the finding in Glimana. Open Security; this check is in the Outdated software group, with the evidence from the last scan under its title. The same problem is listed under Issues › A JavaScript library has known security holes.
Apply the fix on your platform.

WordPressnpm / bundled codeScript from a CDN

The address in the evidence tells you who ships the file: /wp-content/plugins/<slug>/… is a plugin, /wp-content/themes/<slug>/… a theme. Update that plugin or theme. If the theme calls wp_deregister_script( 'jquery' ) and loads an old jQuery itself, remove that code (in a child theme) so WordPress's current jQuery is used, or ask the theme author for a fix.

Find where the version comes from with npm ls jquery (replace with the library name), update with npm install jquery@^3.7.1 or update the dependency that pulls it in, run npm audit, rebuild and deploy the new bundle.

Change the version in the <script src> address to the fixed release or newer, and replace the integrity value with the hash published for that exact file. Then purge your site's cache.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After the fix, press Re-scan on the Security page (or wait for the weekly Sunday 04:00 scan); the problem closes when the check passes.