Cloudflare Client-Side Security Found Eight Payloads That Public Scanners Missed

Cloudflare Client-Side Security found eight malicious payloads across four storefront campaigns, despite public scanning services returning little or no warning. The affected pages still loaded, displayed products, and processed customer interactions. Underneath that normal experience, JavaScript redirected affiliate credit, concealed network requests, disrupted analytics, and created a channel for remote code.

Cloudflare disclosed the findings on September 16, 2026. Its central claim challenges a familiar security assumption: a clean scan does not mean a browser session is behaving safely. Seven payloads were absent from VirusTotal when Cloudflare reviewed them, while urlscan.io returned no malicious verdict for any of the eight.

The comparison is important, but it needs context. VirusTotal and urlscan.io provide valuable intelligence based on submitted files, URLs, engines, and observable behavior. Cloudflare instead encountered these scripts within live website traffic and analyzed their internal structure. The disagreement exposes a coverage gap between checking an artifact once and watching code reach real browsers continuously.

Four Campaigns Turned Normal Storefront Traffic Against Merchants

Cloudflare’s discovery matters because these campaigns attacked revenue operations without necessarily breaking checkout or taking a website offline.

The company’s four campaign findings cover affiliate theft, click manipulation, remote code loading, analytics interference, and visitor tracking. Cloudflare says its automated system surfaced the payloads before human analysts investigated them.

The first operation targeted mobile shoppers during selected periods. It waited for qualifying product elements to appear, intercepted a shopper’s click, and opened an attacker-selected page in another tab. Meanwhile, the original tab traveled through an affiliate tracking route before returning to the store.

That detour could assign credit to an affiliate that never referred the customer. The merchant might then pay an unearned commission or deny credit to the legitimate partner. The customer could remain unaware because the storefront continued working.

Cloudflare found five related builds in this operation. Two were active when captured, while three were paused. The active variants checked device type, local time, browser state, product availability, and recent execution before doing anything visible.

Later versions stored a three-day cooldown in the browser’s localStorage, a persistent storage area available to website scripts. Once activated, the malware would remain quiet on that device for days. A scanner repeating the same visit could therefore see nothing unusual.

The second operation removed even the need for a shopper’s click. Its script issued an affiliate request through an off-screen iframe, which is an embedded page hidden outside the visible layout. A hidden link could click itself when the primary method failed.

The code first contacted an IP geolocation service but ignored the geographic data returned. If that request failed, the malware stopped. Cloudflare could not determine whether this behavior was deliberate sandbox evasion or leftover logic.

The third operation was broader. A script embedded directly in a merchant’s HTML contained older search-hijacking modules alongside active telemetry and remote-loading functions. It could request new JavaScript from attacker-controlled servers after the page loaded.

That created a storefront backdoor. The initial script did not need to contain the final action because a remote server could change its response. Cloudflare could not determine which second-stage payloads attackers delivered in practice.

The fourth operation targeted mobile visitors arriving through paid campaigns. It attempted to disable nine analytics or monitoring tools, suppress customer-support interfaces, replace advertising identities, and transmit telemetry.

The script checked for a viewport narrower than 477 pixels. It also looked for selected campaign tags during the visitor’s first two page loads. A 325-entry IP substring list helped it avoid networks associated with analysts or automated infrastructure.

These operations did not share one domain, signature, or monetization strategy. Their shared feature was selective execution. Each script waited for a browser state that a brief automated inspection was unlikely to reproduce.

Why One Clean Scan Was Never Enough

The primary conflict is continuous browser visibility versus point-in-time scanning, not machine learning versus every existing security control.

Traditional scanners answer useful but limited questions. Has someone submitted this file before? Does an engine recognize its signature? Does a controlled visit trigger observable behavior? Those questions become less reliable when malware chooses which visitors can see its real logic.

One Cloudflare example had reportedly remained indexed by urlscan.io with no classification for nearly two and a half years. Its broader malware family was already documented, yet that specific payload had not received the same actionable label.

A static crawler can load the page, inspect its files, and record network traffic. However, the result represents one browser configuration at one moment. Storefront malware can test time, device, location, referrer, cookies, screen width, and session history before activating.

The after-hours affiliate hijacker watched for product tiles created after the initial page load. It used MutationObserver, a browser interface that detects changes to the page’s document structure. A crawler that captured only the original HTML could miss the hooked element.

The paid-mobile cloaker went further. It rejected business networks, cloud providers, hosting facilities, VPNs, proxies, Tor exits, and several geographic locations. Those checks disproportionately exclude the environments that researchers and automated scanners commonly use.

This produces an uncomfortable reversal. A clean desktop test from a corporate network can become evidence that the evasion logic is working. The merchant sees normal analytics because the malicious branch never runs for the people investigating it.

The campaigns also show why a website’s operational health can be misleading. Availability monitoring confirms that pages respond. Synthetic checkout testing confirms that a transaction completes. Neither check necessarily reveals who receives attribution or which browser connections occur.

Server-side logs present another partial view. A third-party script executes with access to the page’s document and browser context. OWASP’s third-party script risks include lost change control, arbitrary code execution, and sensitive-data disclosure.

Cloudflare’s evidence does not make public scanners obsolete. Submitted artifacts, historical observations, reputation data, and shared indicators remain essential for investigations. The findings instead show that those systems cannot label code they never receive or behavior they never trigger.

The strongest defensive position combines multiple views. Reputation services can identify known infrastructure. Code analysis can examine intent. Browser telemetry can expose loaded resources and connections. Human analysts can then determine whether an automated verdict fits the operational context.

That layered model pressures security teams that still treat a one-time scan as final clearance. It also pressures marketing and commerce teams because their tag managers often control code that security teams rarely review continuously.

How Cloudflare Client-Side Security Reads Evasive JavaScript

Cloudflare Client-Side Security focuses on code structure first, then uses language models and human review to narrow uncertain findings.

Cloudflare’s frontline classifier is a graph neural network, or GNN. This machine learning model processes relationships between connected elements. Here, those elements come from JavaScript’s abstract syntax tree, which represents code as structured operations rather than raw text.

That distinction helps the model look past superficial changes. Attackers can rename variables, minify files, rotate strings, or add unused branches. Those changes alter the visible text but may preserve the relationships between calls, conditions, page events, and network requests.

Cloudflare says its GNN flagged all eight payloads in live traffic. The company previously described the broader detection architecture as a cascade rather than a single model making every decision.

The GNN is tuned to catch suspicious structures. Scripts it considers benign leave the pipeline early. Potentially malicious scripts receive a second assessment from a smaller language model running through Workers AI.

This second stage addresses the false-positive problem. Legitimate advertising bundles, bot challenges, tracking scripts, and compressed frameworks can resemble malicious code. They may use obfuscation, dynamic execution, unusual network calls, or other patterns that appear suspicious without context.

Cloudflare reported in an earlier product update that its systems assess 3.5 billion scripts daily. It also said an average enterprise zone exposes about 2,200 unique scripts. Roughly one-third can change within a 30-day period, according to the company.

Those figures come from Cloudflare and have not been independently audited for this campaign disclosure. They nevertheless illustrate the operational challenge. Even a low false-positive rate becomes unmanageable when applied to billions of assessments.

In the latest investigation, Cloudflare says fewer than 0.3 percent of analyzed traffic reached the language-model review stage. If that model corroborated the GNN, the system alerted the customer.

More complex samples received another layer of analysis. Cloudflare used models from about six families as independent “teachers.” Each examined the same script in a fresh session and could access a restricted JavaScript evaluator.

The models voted among four labels: benign, payment skimming, other malware, and cryptomining. Cloudflare weighted those votes using external model-performance rankings. Human reviewers examined scripts labeled malicious or lacking a two-thirds majority.

This is not a fully autonomous loop. Cloudflare acknowledges that feedback into GNN training remains partly manual. The company also plans to add Cloudflare Sandbox for deeper analysis in isolated environments.

The approach combines structural classification, semantic review, model disagreement, and analyst judgment. Its advantage is not that a language model somehow “understands” every attack. The advantage is that each stage addresses a different failure mode.

The GNN can recognize structural similarities at high volume. The language model can filter strange but legitimate JavaScript. Multiple teacher models can expose uncertainty. Analysts can investigate the smaller set where automated signals remain concerning or divided.

Continuous monitoring supplies the context around those judgments. Cloudflare’s security documentation says the service observes scripts, connections, and cookies loaded by visitors. Advanced features add malicious-script detection, code-change alerts, and content security rules.

That architecture directly serves the main contest. Point-in-time tools inspect a chosen sample or session. Continuous browser reporting records how resources appear across real visits, increasing the chance that selective malware eventually reveals itself.

The Browser Has Become Part of the Revenue System

These attacks show that client-side security now protects attribution, analytics, and customer access alongside payment data.

The first two campaigns targeted affiliate economics rather than card numbers. That distinction matters because many storefront security programs concentrate their strongest controls around checkout. Revenue can still leak earlier in the customer journey.

Affiliate systems determine which partner receives credit for a purchase. Attackers do not need to stop the transaction when they can alter that decision. A fraudulent attribution request can convert a legitimate sale into an unearned commission.

The first campaign’s dual-tab maneuver preserved the customer’s shopping flow. One tab kept the visitor engaged while the other passed through the attacker’s tracking route. The attack benefited from looking like a normal navigation event.

The clickless variant was even quieter. An invisible iframe could issue an affiliate request without meaningful customer interaction. Cloudflare confirmed the automated requests but did not establish whether they produced paid commissions.

That limitation should remain visible. Code can prove intent and capability without proving realized financial damage. Merchant attribution records, affiliate-account data, and payout histories would be needed to measure the actual loss.

The paid-mobile cloaker targeted another business asset: observability. It focused on traffic merchants had already purchased through paid search, text campaigns, and other tagged channels. Those sessions were valuable precisely because acquisition spending had brought them to the store.

The malware attempted to replace analytics identifiers while disabling monitoring and support tools. If successful, that could corrupt campaign reporting and make legitimate traffic appear to belong elsewhere.

It also suppressed chat and contact controls. A shopper who noticed something unusual might lose the easiest path for reporting it. The merchant would then lose both telemetry and direct customer feedback.

Cloudflare’s sandbox testing confirmed that a replacement analytics script loaded and fired a tracking beacon. However, the company did not prove that attackers captured usable telemetry or diverted advertising revenue.

The storefront backdoor presented a different risk. Once the script could load arbitrary remote JavaScript, the attacker’s options were no longer limited to the observed modules. Future instructions could change without another edit to the merchant’s HTML.

This flexibility complicates incident scoping. Removing one visible redirect does not establish that the attacker lacked other capabilities. Responders must identify the initial insertion path, remote endpoints, affected sessions, and any administrative compromise.

Cloudflare could not determine how that script entered the merchant’s HTML. It identified compromised credentials, unauthorized template changes, and infected themes or plugins as plausible routes, not confirmed causes.

That uncertainty matters for remediation. Blocking an observed domain can stop one delivery path while leaving the original access route open. A durable response requires credential review, template integrity checks, dependency inventory, and examination of tag-manager permissions.

The industry already recognizes the browser as part of the payment-security boundary. The PCI Security Standards Council’s payment-page guidance focuses on authorizing scripts, verifying integrity, and monitoring pages for unauthorized changes.

Cloudflare’s campaigns expand the operational reason for doing that work. The browser does not merely render a checkout form. It assigns marketing credit, records behavior, loads support tools, and determines which external services receive customer data.

Security, marketing, commerce, and analytics teams therefore share the same attack surface. A marketing tag approved for measurement can become a delivery route. A compromised theme can become a command channel. An attribution mechanism can become a theft target.

That overlap creates organizational pressure. Security teams need visibility into browser-side changes, while marketing teams need a review process that does not freeze every campaign. The difficult problem is governing fast-moving scripts without making normal storefront operations unworkable.

Cloudflare’s Findings Still Need a Careful Reading

The campaign evidence supports continuous monitoring, but it does not independently validate every product claim or quantify the merchants’ final losses.

Cloudflare discovered the samples, operated the detection system, and published the technical analysis. That gives the company direct access to valuable telemetry. It also means the central performance comparison comes from the vendor selling the advanced detection service.

The disclosure names eight payloads and explains their behavior, but it withholds affected merchant identities. That decision protects victims and avoids creating a new targeting list. It also limits independent verification of the incidents’ financial and operational consequences.

Cloudflare did not publish a controlled benchmark comparing its system against every scanner under identical conditions. Its evidence shows that VirusTotal lacked seven payloads and that urlscan.io returned no malicious verdicts. That is narrower than proving superior detection across the market.

Ingestion also differs from classification. A service cannot label a file it has never received. Cloudflare observed the scripts because affected traffic passed through its network and browser-reporting workflow. That access advantage is distinct from model accuracy.

The one payload already known to VirusTotal further complicates a simple winner-and-loser narrative. Public history did not reveal when the malicious verdict appeared. The available record therefore cannot establish which system identified it first.

False negatives deserve attention, but so do false positives. A system that flags unfamiliar JavaScript too aggressively can overwhelm analysts or block legitimate commerce. Cloudflare uses an additional language model partly because benign code often resembles malware structurally.

Cloudflare previously reported substantial reductions in false positives after adding that second stage. Those results were internal evaluations, not an independent peer-reviewed assessment. Customers should judge alert quality against their own script populations and incident outcomes.

The model pipeline also contains human choices. Decision thresholds determine which scripts advance. Prompting shapes the language model’s review. Model-ranking weights influence teacher votes. Human analysts resolve selected cases and feed labels back into training.

Those choices do not invalidate the findings. They show why “AI detected it” is an incomplete explanation. Detection quality depends on telemetry, model design, thresholds, analyst review, and the response process after an alert.

Content Security Policy, or CSP, remains another important layer. CSP tells browsers which resources and connections a page should allow. Its report-only mode can collect violations before enforcement, as described in the CSP reporting reference.

Yet reporting alone does not block malicious code. An overly broad allowlist can permit a compromised vendor. A direct insertion from an already trusted origin can also evade simple domain restrictions.

Strict enforcement introduces its own operational cost. Modern storefronts load advertising, experimentation, payment, personalization, support, and analytics services. Their domains and code can change frequently, making narrow policies harder to maintain.

Subresource Integrity can verify that a remotely loaded file matches an approved hash. It works best for stable resources. It becomes harder when a vendor intentionally changes scripts without publishing fixed, versioned files.

The practical conclusion is not that one control replaces all others. Continuous observation, script inventory, integrity checks, CSP, reputation intelligence, and incident response each cover different gaps.

Cloudflare’s strongest evidence concerns selective malware found in its own telemetry. The unproven areas concern realized revenue theft, second-stage activity, initial access, and performance across unobserved attacks. Those boundaries should shape any buying or deployment decision.

Three Signals Will Show Whether Continuous Detection Delivers

The next test is whether Cloudflare can turn these findings into repeatable detection, clearer evidence, and faster merchant response.

The first signal is broader technical validation. Security researchers can use the published indicators to search other environments for related infrastructure and code. Additional discoveries would show whether the four operations were isolated compromises or parts of wider campaigns.

Independent analysis could also confirm the scripts’ attribution behavior, remote-loading paths, and anti-analysis gates. If researchers reproduce those findings, Cloudflare’s interpretation becomes stronger. If they uncover benign explanations or different outcomes, confidence should narrow.

The second signal is detection quality after Cloudflare expands its sandbox workflow. Isolated browser execution could provide stronger evidence about payload behavior while protecting production systems. It could also reveal which model suspicions fail during runtime testing.

Useful reporting would include alert precision, analyst-confirmed attacks, overrides, and missed cases. Aggregate figures should separate analyzed traffic from unique scripts because repeated execution can distort performance measurements.

Customers should watch the quality of explanations, not just alert totals. A useful warning should identify the triggering code path, observed connection, affected pages, and relevant browser state. A generic malicious label creates work without guiding containment.

The third signal is merchant response time. A technically correct alert has limited value if it remains unseen, lacks ownership, or cannot trigger a coordinated investigation. Storefront teams need a route from browser evidence to containment.

That process should identify who can disable a tag, revoke credentials, restore a template, block an endpoint, and validate analytics afterward. It should also preserve evidence needed to determine whether commissions, customer data, or campaign measurements were affected.

Continuous monitoring becomes more persuasive when it shortens the interval between first malicious execution and successful removal. It becomes less persuasive if teams receive alerts but cannot distinguish actual compromise from routine script changes.

Store owners should ask a direct question: can their current controls explain which JavaScript reached a real customer, what that code did, and where it connected? A clean scan cannot answer all three.

Cloudflare Client-Side Security offers one approach to that visibility, backed by a technically detailed vendor disclosure. The evidence warrants attention, but buyers should still test alert quality and response integration within their own storefronts.

The immediate action is broader than purchasing a product. Inventory browser scripts, review tag-manager authority, test reporting policies, and define who owns client-side alerts. Then measure whether those controls detect behavior that ordinary availability and vulnerability scans leave unseen.