Claude Code Security and Magecart: Getting the Threat Model Right

When a Magecart payload hides inside the EXIF data of a dynamically loaded third-party favicon, no repository scanner will catch it – because the malicious code never actually touches your repo. As teams adopt Claude Code Security for static analysis, this is the exact technical boundary where AI code scanning stops and client-side runtime execution begins.

A detailed analysis of where Claude Code Security stops — and what runtime monitoring covers — is available here.

A Magecart skimmer recently found in the wild used a three-stage loader chain to hide its payload inside a favicon's EXIF metadata — never touching the merchant's source code, never appearing in a repository, and executing entirely in the shopper's browser at checkout. The attack raises a question that’s worth getting precise about: which category of tool is actually supposed to catch this?

Magecart Lives Outside Your Codebase

Magecart‑style attacks are rarely about classic vulnerabilities in your own source code. They are supply chain infiltrations. The malicious JavaScript typically arrives via compromised third‑party assets: tag managers, payment/checkout widgets, analytics tools, CDN‑hosted scripts, and images that are loaded into the browser at runtime. The victim organization didn't write that code, doesn't review it in PRs, and it often doesn't exist in their repository at all.

That means a repository‑based static analysis tool, such as Claude Code Security, is therefore limited by design in this scenario, because it can only analyze what's in the repo or what you explicitly feed it. Any skimmer that lives solely in modified third‑party resources or dynamically loaded binaries in production never enters its field of view. That's not a bug in the product; it's a scope mismatch.

The Attack Flow: How the Skimmer Hides

Here is the initial loader seen on compromised websites:

This stub dynamically loads a script from what appears to be a legitimate Shopify CDN URL. The loaded script then constructs the actual malicious URL using obfuscated index arrays:

Once decoded, this points to //b4dfa5[.]xyz/favicon.ico. What happens next is where the technique gets interesting: the script retrieves the favicon as binary data, parses the EXIF metadata to extract a malicious string, and executes it via new Function() — the payload lives inside image metadata, so it’s invisible to anything that isn't watching the browser at runtime.

The final exfiltration call POSTs stolen payment data silently to an attacker-controlled server:

The chain has four properties that matter for the tooling discussion that follows: the initial loader looks like a benign third-party include; the payload is hidden in binary image metadata; exfiltration happens directly from the shopper's browser; and none of it requires touching the merchant's own source code.

What Claude Code Security Can and Can't See

Claude Code Security is designed to scan codebases, trace data flows, and suggest fixes for vulnerabilities in the code you or your teams write. That makes it useful for securing first‑party applications, but it also defines its blind spots for this attack class.

In this scenario, it has no practical visibility into malicious code that’s only injected into third‑party, CDN, or tag‑manager‑hosted scripts that are never stored in your repos. It can’t interrogate payloads hidden in binary assets like favicons or images that are not part of your source tree either. It can’t assess the risk or live reputation of attacker‑controlled domains that only appear at runtime, and real‑time detection of anomalous browser‑side network requests during checkout is also beyond its scope.

Where it could contribute (though not as the primary control) would be in cases where your own code contains dynamic script‑injection logic, a pattern that a code analysis tool may flag as risky. And if first‑party code hard‑codes suspicious exfiltration endpoints or uses unsafe data‑collection logic, static analysis can highlight those flows for review.

The top four rows are what matter most in a Magecart scenario, and Claude Code Security has no runtime visibility into any of them.

The bottom two represent a fundamentally different threat: a developer accidentally writing malicious-looking code in their own repository.

Magecart is One Vector, Not the Whole Attack Surface

The favicon steganography technique above is sophisticated, but it's one instance of a broader pattern. Web supply chain attacks arrive through several distinct mechanisms, each with the same defining characteristic: the malicious activity happens at runtime, in the browser, through assets the merchant didn't create. See how AI-generated, polymorphic JavaScript is raising the stakes →

A few others worth naming:

** Malicious iframe injection.** A compromised third-party widget silently overlays a legitimate checkout form with an attacker-controlled iframe. The user sees the real page, but their keystrokes are sent to the attacker. Nothing in the merchant's repository changes.

** Pixel tracker abuse.** Analytics and advertising pixels — nearly universal on e-commerce sites — are loaded from external CDNs. When those CDNs are compromised or the pixel provider itself is breached, the tracking code running on every page becomes an exfiltration channel. The merchant's code still calls the same legitimate-looking endpoint it always did.

** DOM-based credential harvesting.** A script loaded via a tag manager silently listens for form field events on login or payment pages, capturing data before it's ever submitted. The attack lives entirely in the event handler registered at runtime, not in anything a static scanner would ever see.

Each of these follows the same logic as the Magecart case: the threat lives outside the repository, executes in a context that static analysis cannot observe, and targets the gap between what you shipped and what actually runs in your users' browsers. You can find the full breakdown of how each vector maps to tooling coverage — and what a defense-in-depth program looks like across all of them — in the guide linked below.

Why Runtime Monitoring Is Critical (But Not the Only Control)

For web supply chain threats like this Magecart campaign, continuous monitoring of what actually runs in users' browsers is the primary layer with direct visibility into the attack as it happens. Client‑side runtime monitoring platforms answer a couple of questions that static tools cannot: "What code is executing in my users' browsers right now, and what is it doing?"

At the same time, runtime monitoring is only one part of the picture. It works best as part of a defense‑in‑depth strategy. Static analysis and supply‑chain governance reduce the attack surface, while runtime monitoring catches what slips through, and what lives entirely outside your repos.

Reframing the "Test": Category, Not Capability

Evaluating a repo-centric tool like Claude Code Security against a runtime attack is a category error, not a product failure. It's like expecting a smoke detector to put out fires. It’s the wrong tool for that job, but the ideal one for what it was designed to do. For a fire-safe building, you need smoke detectors and fire extinguishers, and for a safe website, you need Claude Code Security and runtime monitoring in your stack. For Magecart and similar client‑side skimming attacks, you need that runtime window into the browser. Static repository scanning, by itself, simply doesn't see where these attacks truly live.

If you're mapping tooling to threat classes at the CISO level, we’ve put together a short guide on how code security and runtime monitoring fit together across the full range of web supply chain vectors — and where each one stops being useful.