Malicious scripts vs vulnerable libraries: two problems, two clocks

A malicious script rarely announces itself. The file keeps its name and often its URL, and the site keeps working. What changes is what the code does: it starts reading what visitors type into payment or login fields, it talks to a server it never used before, or it hides what it does behind decoding and runtime code. Recent cases show the pattern: a trusted analytics tag that served exploits for a week (the Plerdy compromise), and a performance script that drained crypto wallets (the DebugBear incident).

• Stop it first. Block the script, its host or its vendor on the pages it reaches. A wrong block costs a broken widget for an hour; a missed skimmer costs every card typed in the meantime.
• Then find out how it got there. A vendor's file, your own bundle, a tag manager change or a plugin update each points to a different fix.
• Treat it as an incident. Follow your incident response plan, and for payment pages, your obligations to your acquirer.

Most sites ship a few libraries with known advisories: an older jQuery, a date picker, a carousel. That is a maintenance problem, not an attack, and the useful question is how much it matters on your pages.

• How severe is it? A critical or high advisory comes first. A low one can usually wait for the next routine upgrade.
• Can it be reached? A flaw in a function your pages never call, or on a page with no forms, matters less than one on checkout.
• Is there a fix? Most advisories are fixed by upgrading within the same major version. Where there is none, replace the library or limit what it can do.
• Write the decision down. If you keep a vulnerable version for a while, record why and until when. That record is what an assessor asks for.

For payment pages, 6.4.3 asks you to authorise every script and assure its integrity, which a malicious change breaks by definition. 11.6.1 asks you to detect unauthorised changes to scripts and security-impacting headers as the browser receives them. Separately, PCI DSS asks you to manage known vulnerabilities in the software you run, which covers libraries your pages load. Two different obligations, which is one more reason to keep the two problems apart.

Script Monitoring reads every script that runs on your pages. Behaviour and source decide whether it looks malicious, and AI analysis reads the code before anything alerts, so you can block it in the browser right away. Libraries are checked against known-vulnerability databases and alert by advisory and severity, so a critical CVE is not buried under minor ones. See AI script analysis and script blocking.

Requirement descriptions are paraphrased from PCI DSS v4.0.1, published by the PCI Security Standards Council. The incidents mentioned are covered in our own posts, which list their sources. Written on 10 November 2026.