Summary: Cloudflare describes four malicious storefront campaigns, totaling eight payloads, that Page Shield ML caught in live traffic. Seven payloads were absent from VirusTotal and URLScan gave none a malicious verdict, showing why signature and reputation checks miss conditional client-side attacks. Cloudflare combines a graph neural network, Workers AI review, and frontier-model voting to flag affiliate theft, click hijacking, and related behavior.
A storefront can pass every visual check while malicious JavaScript quietly works underneath it: siphoning affiliate revenue, hijacking clicks, tampering with analytics. Pages load, checkout completes, and all the while the browser is doing something the owner never authorized. Cloudflare’s Client-Side Security machine learning model exists to surface that blind spot, and a recent post walks through four operations it caught in the wild.
Why scanners miss what Page Shield ML catches
Detection was automated; a human only stepped in to verify after the system raised a flag. When Cloudflare later ran the campaigns through ordinary security scanning tools, seven of the eight payloads were entirely absent from VirusTotal, and URLScan gave no malicious verdict for any of them. Page Shield ML had caught all eight in live traffic.
One payload version sat indexed by URLScan for close to two and a half years with “No classification,” a stretch that covered a direct scan in January 2024. A hash can be on record long before the code behind it is classified as malicious. Any defense that waits for that label arrives too late. What you need is ML that can take the JavaScript apart and judge it at scale.
The four operations had no universal signature in common and no shared way of hiding. One stayed dormant unless device, country, time, referrer, or browser state matched. Another tucked a clickless affiliate request inside an invisible iframe. The rest intercepted clicks, suppressed monitoring, or conditionally pulled additional code from remote servers. A single pass over the page does not cover this; scripts like these stay quiet until the right victim turns up.
How a graph neural network reasons about code
The GNN that flagged these operations had already caught malicious npm packages and an in-the-wild Magecart payment skimmer. It never reads JavaScript as flat text; it reasons over the code as a graph — a syntax tree linking code symbols and revealing what calls what, what the attacker tried to bury, and what is still phoning home. That structure lets it recognize suspicious patterns through minification, renaming, and a degree of obfuscation, without leaning on a known URL or byte signature.
The scripts the GNN marks malicious — under 0.3% of all analyzed traffic — go to a lightweight large language model on Workers AI for a live second opinion. That trims false positives further while recall stays high. Customers are alerted once the LLM corroborates the GNN.
For the most complex scripts, Cloudflare turns to a cohort of frontier models it calls teachers, drawing leading models from around six different families, open-weight models running on Workers AI among them. Each one studies the same suspicious script in its own fresh, independent session. Where it helps, their agentic tool access lets them run a restricted JavaScript evaluator to unpack small snippets and expose concealed behavior.
The frontier models disagree at times, especially on intricate scripts, and Cloudflare treats that disagreement as signal rather than noise. Every label becomes a vote weighted by the model’s score in the Artificial Analysis Intelligence Index, resolving into a probability distribution over four labels: benign, payment skimming, other malware, and cryptomining. Human reviewers only have to examine scripts flagged as malicious or lacking a clear two-thirds majority. Those label distributions then flow back into GNN training, helping it tell apart 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. A model that knows only one of those tricks will sleep through the rest.
Operation 1: the after-hours affiliate-commission hijacker. A shopper taps a product on a phone. Rather than following the tap the usual way, the script opens a product or campaign landing page from an attacker-preselected list in a new tab and routes the original tab through an affiliate path. If the shopper goes on to complete a purchase, that detour takes the attribution, crediting the sale to an account that did not earn the referral. The shop could pay a commission it owes no one, and partners who stop trusting the attribution system may stop trusting the retailer as well.
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 passes through different gates before acting, 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: the 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 hides the affiliate request behind 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 have nothing to do with actual geography. The script calls a public IP-based geolocation service but ignores everything it returns, including the shopper’s country. Should the geolocation request fail, the script silently stops; its promise chain ends with .catch(() => {}). Fail-closed behavior like that could help the script evade network-restricted sandboxes.
Instead of using the geolocation data it fetched, the payload carries three TradeDoubler configuration objects labelled AU, US, and UK. Each holds an affiliate URL plus 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 will not carry you. 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, that 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.