A modern storefront can look perfectly healthy while malicious JavaScript works underneath: siphoning affiliate revenue, hijacking searches and clicks, tampering with analytics, or asking a remote server what to execute next. Pages load, products appear, and checkout works — yet the browser may be quietly doing something the site owner never authorized. That is the blind spot our Client-Side Security machine learning (ML) model is built to expose.
This post follows four operations, spanning eight payloads, that our Page Shield ML uncovered in the wild. The detection of these malicious payloads was automated; humans verified each finding only after the system had flagged it. When we afterward reviewed the campaigns using security scanning tools, seven of the eight payloads were entirely absent from VirusTotal, and URLScan returned no malicious verdict for any of them.
Page Shield ML , meanwhile, caught all eight in live traffic. For instance, while security research documented the broader Lnkr family years earlier, one specific payload version sat indexed by URLScan for nearly two and a half years with “No classification,” including during a direct scan in January 2024. Only in this case had VirusTotal ingested the payload earlier: while it currently flags the script as malicious, public history does not reveal when that verdict was first assigned.
Meanwhile, Page Shield ML independently surfaced those exact bytes live on an online retailer's storefront. More broadly, a hash can be known long before the code behind it is classified as malicious. If your defense waits for that label, you are already late.
You need ML that can unravel the JavaScript itself and judge it at scale. Indeed, seeing a file is not the same as understanding it. The tricky part was that the four operations shared no universal signature or common concealment technique.
One remained dormant unless the device, country, time, referrer, or browser state matched what it was waiting for. Another concealed a clickless affiliate request within an invisible iframe. Others intercepted clicks, suppressed monitoring, or conditionally loaded additional code from remote servers.
To catch them, you have to watch how those pieces work together: when the script wakes up, what it hides, what it intercepts, and what it fetches next. Checking the page once is not enough; as these cases show, such scripts are built to stay quiet until the right victim shows up. That is why ongoing browser visibility makes the difference between catching an attack and missing it entirely.
How we detect and label JavaScript at scale The same GNN (graph neural network) that flagged the four operations in this post had already caught malicious npm packages and an in-the-wild Magecart payment skimmer . The GNN does not treat JavaScript as a flat chunk of text; it reasons through the code as a graph: a syntax tree connecting code symbols and exposing what calls what, what the attacker tried to bury, and what still phones home.
That structure helps it recognize suspicious patterns across minification, renaming, and some obfuscation without relying on a known URL or byte signature. The few scripts that the GNN flags as malicious (under 0. 3% of all analyzed traffic) go to a lightweight large language model (LLM) on Workers AI for a live second opinion .
This further reduces false positives while keeping recall high. When the LLM corroborates the GNN, customers are alerted. To investigate the most complex scripts at scale, we use a cohort of frontier models, which we call teachers (an ensemble of automated judges).
The cohort draws leading models from around six different families, including open-weight models running on Workers AI. We spin up each as an agent to analyze the same suspicious script in its own fresh, independent session. When useful, their agentic tool access lets them use a restricted JavaScript evaluator to unpack small snippets and reveal concealed behavior.
We will soon extend this workflow with Cloudflare Sandbox for deeper analysis in isolated environments. The frontier models sometimes disagree, especially on the most intricate scripts. We treat that disagreement as signal, not noise.
Each label becomes a vote, weighted by the model's score in the Artificial Analysis Intelligence Index , producing a probability distribution over four labels: benign, payment skimming ( magecart ), other malware, and cryptomining. Human reviewers therefore need only examine scripts flagged as malicious or lacking a clear two-thirds majority. We then feed those label distributions back into GNN training, helping it distinguish ever more nuanced cases.
This feedback loop is still partly manual, though we are starting to automate it. Four malicious JavaScript operations we caught These four operations do very different things, from commission theft to stolen analytics on shoppers the store already paid to acquire. Stealing a commission is not like skimming a credit card; likewise, hijacking search is not like stealing a password.
If an ML model only knows one of those tricks, it will sleep through the others. Instead, our Page Shield ML has to stay attuned to every kind of hostile behavior. Now, let’s dig deeper into each operation and how it worked.
Operation 1: The after-hours affiliate-commission hijacker Picture a quiet Sunday afternoon: a shopper on a phone taps a product. Instead of following the tap normally, the script opens a product or campaign landing page from an attacker-preselected list in a new tab and sends the original tab through an affiliate route. The storefront still appears to work.
If the shopper completes a purchase (either then or later), the detour hijacks the attribution, crediting the sale (and any resulting commission) to an account that did not earn the referral. What the shop lost The shop could pay an unearned commission to an account that did not bring the shopper.
Originally published at blog.cloudflare.com
