A storefront can look healthy while malicious JavaScript works underneath: siphoning affiliate revenue, hijacking clicks, or tampering with analytics. Pages load and checkout works, yet the browser quietly does something the owner never authorized. Cloudflare’s Client-Side Security machine learning model is built to expose that blind spot, and a recent post details four operations it caught in the wild.
Why scanners miss what Page Shield ML catches
The detection was automated; humans verified findings only after the system flagged them. When Cloudflare 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 caught all eight in live traffic.
One payload version sat indexed by URLScan for nearly two and a half years with “No classification,” including during a direct scan in January 2024. 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.
The four operations shared no universal signature or common concealment technique. One remained dormant unless device, country, time, referrer, or browser state matched. Another concealed a clickless affiliate request within an invisible iframe. Others intercepted clicks, suppressed monitoring, or conditionally loaded additional code from remote servers. Checking the page once is not enough; such scripts stay quiet until the right victim shows up.
How a graph neural network reasons about code
The same GNN that flagged these operations had already caught malicious npm packages and an in-the-wild Magecart payment skimmer. It does not treat JavaScript as flat 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 the GNN flags as malicious (under 0.3% of all analyzed traffic) go to a lightweight large language model 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.
For the most complex scripts, Cloudflare uses a cohort of frontier models called teachers. The cohort draws leading models from around six different families, including open-weight models running on Workers AI. Each analyzes 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.
The frontier models sometimes disagree, especially on intricate scripts. Cloudflare treats 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, other malware, and cryptomining. Human reviewers need only examine scripts flagged as malicious or lacking a clear two-thirds majority. Those label distributions feed back into GNN training, helping it distinguish ever more nuanced cases.
Four operations that show the range of threats
These operations do very different things, from commission theft to stolen analytics on shoppers the store already paid to acquire. If an ML model only knows one of those tricks, it will sleep through the others.
Operation 1: The after-hours affiliate-commission hijacker. A shopper taps a product on a phone. 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. If the shopper completes a purchase, the detour hijacks the attribution, crediting the sale to an account that did not earn the referral. The shop could pay an unearned commission, and partners who stop trusting the attribution system may also stop trusting the retailer.
The attack chain: qualified mobile visitor → intercepted product tap → script-selected page opens in new tab + original tab follows attacker’s affiliate route. Five related script builds were found: two active and three paused when captured. Each active variant uses different gates before it acts, checking device and local time, whether the trick has run recently, whether a product button has appeared, and whether someone actually clicks it. The active scripts use a MutationObserver to watch for product tiles and buttons that dynamically appear after the page is first loaded. A crawler that loaded the HTML once and stopped there could miss the redirect path entirely.
In active later variants, the script intercepts a qualifying click and writes a three-day cooldown to localStorage, then executes a dual-tab maneuver: popping an attacker-chosen product page into a fresh tab while the original tab takes a quick round-trip through the attacker’s affiliate tracking link to plant an attribution cookie in the background. Console masking and self-defending source checks make inspection harder.
The paused builds showed how the campaign could go dark without removing the script. Their embedded configuration set status: “paused”, so they exited before installing click handlers. One paused script even recorded a version-history comment explicitly documenting that the campaign was paused after Black Friday.
To reach visitors, the operation leveraged the site’s marketing supply chain: third-party scripts and tag managers embedded by e-commerce sites. One confirmed delivery path ran through Google Tag Manager → another tag manager → malicious script. That is how the payload reached the browser, not proof that either tag manager was compromised. The attacker even disguised the domain hosting the script: adtargett[.]com differed by a single “t” from adtarget[.]com, an advertising domain registered in 1998. The lookalike was registered in 2025 and called itself “Adtarget.com - Performance Marketing Agency.”
Operation 2: The clickless affiliate theft. A shopper can open a booking page, linger over product options, and never touch an ad. In the background, the script might have already sent an affiliate request that could make a later sale look as though someone else had referred the shopper. When conditions are met, the payload sends that request through a hidden iframe or a link that clicks itself.
The script conceals the affiliate request in two layers: selective execution (a pre-flight network gate and hourly schedule) and stealth delivery (an off-screen iframe). The first layer is surprising because its country labels are disconnected from actual geography. The script calls a public IP-based geolocation service but ignores everything it returns, including the shopper’s country. If the geolocation request fails, the script silently stops; its promise chain ends with .catch(() => {}). This fail-closed behavior could help the script evade network-restricted sandboxes.
Instead of using the fetched geolocation data, the payload contains three TradeDoubler configuration objects labelled AU, US, and UK. Each contains an affiliate URL and start and end times. The script computes Asia/Kolkata time in JavaScript, checks those configured time windows, then applies fixed odd/even-hour rules to choose one of the three or else skip the affiliate request for that run.
What this changes for how you build storefronts
Static scanners and reputation feeds are not enough. Malicious scripts are built to stay quiet until the right victim shows up, and they evolve without changing their hash. Runtime detection that watches how scripts behave — when they wake up, what they hide, what they intercept, and what they fetch next — is the difference between catching an attack and missing it entirely.
For builders, this means treating client-side security as an ongoing monitoring problem, not a one-time audit. The same principle applies to any system where third-party code runs in your users’ browsers: you need visibility into what that code actually does, not just what it claims to be. Cloudflare’s approach shows how combining graph-based analysis with LLM second opinions and ensemble voting can catch threats that traditional tools miss. As with scoping Cloudflare Workers access so agents can’t touch production, the goal is to limit what untrusted code can do and detect when it oversteps.
The supplied RSS summary does not specify the full details of Operations 3 and 4, but the pattern is clear: attackers are using increasingly sophisticated techniques to hide in plain sight. The takeaway for product builders is to assume that some of the JavaScript running on your storefront is malicious and to build detection that works at runtime, not just at deploy time.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.