If the Magecart payload is hidden within the EXIF data of a dynamically loaded third-party favicon, the malicious code never actually touches the repository and repository scanners cannot catch it. If your team employs 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 the scope of runtime monitoring can be found here.
The recently discovered Magecart skimmer used a three-stage loader chain to hide its payload within the favicon’s EXIF metadata. It never touched the merchant’s source code, was never visible in the repository, and ran entirely within the shopper’s browser at checkout. This attack raises questions that are worth pinpointing. It’s about what category of tools are actually supposed to capture this.
Magecart exists outside the codebase
Magecart-style attacks are rarely about classic vulnerabilities in proprietary source code. They are an intrusion into the supply chain. Malicious JavaScript typically arrives via compromised third-party assets: tag managers, payment/checkout widgets, analytics tools, scripts hosted on CDNs, and images loaded in the browser at runtime. The victim organization did not write the code, did not review it in PR, and in many cases, the code does not exist in the repository at all.
This means that repository-based static analysis tools such as Claude Code Security are limited by design in this scenario, as they can only analyze content within the repository or content that you explicitly feed into the repository. Skimmers that exist only in modified third-party resources or dynamically loaded binaries in production are never in sight. This is not a product bug. It’s a scope mismatch.
Flow of attack: how skimmers hide
Below is the initial loader seen on the compromised website.
This stub dynamically loads a script that looks like a legitimate Shopify CDN URL. The loaded script then uses the obfuscated index array to construct the actual malicious URL.
When decoded, this points to //b4dfa5[.]xyz/favicon.ico. What happens next is what makes this technique interesting. The script retrieves the favicon as binary data, parses the EXIF metadata to extract the malicious string, and executes it via new Function(). The payload resides within the image metadata, so it is invisible to non-monitoring browsers at runtime.
The final extraction call silently POSTs the stolen payment data to an attacker-controlled server.
This chain has four properties that are important to the description of the tool below. The initial loader looks like a benign third-party include. The payload is hidden in binary image metadata. The leak is done directly from the shopper’s browser. And none of that requires touching the seller’s own source code.
What you can and cannot see with Claude Code Security
Claude Code Security is designed to scan your codebase, track data flows, and suggest fixes for vulnerabilities in the code you or your team writes. While this helps secure first-party applications, it also defines a blind spot for this attack class.
In this scenario, there is virtually no visibility into malicious code that is never stored in the repository and is only injected into scripts hosted by third parties, CDNs, or tag managers. It also cannot inspect payloads hidden in binary assets such as favicons or images that are not part of the source tree. It is not possible to assess the risk or real reputation of an attacker-controlled domain that only appears at runtime. It also extends to real-time detection of anomalous browser-side network requests during checkout.
This can have an impact (though not as a primary control) if your own code contains dynamic script injection logic, a pattern that code analysis tools can flag as dangerous. Additionally, if first-party code hardcodes suspicious exfiltration endpoints or uses insecure data collection logic, static analysis can highlight and review those flows.
The top four lines are the most important in the Magecart scenario, but Claude Code Security cannot see them at runtime.
The bottom two represent fundamentally different threats. That is, a developer accidentally writes malicious code into their repository.
Magecart is one vector, not the entire attack surface
The favicon steganography technique described above is sophisticated, but is an example of a broader pattern. Web supply chain attacks arrive through several different mechanisms, each with the same characteristics. This means that malicious activity occurs at runtime, within the browser, and through assets not created by the seller. See how AI-generated polymorphic JavaScript is profitable →
There are a few others worth mentioning.
Malicious iframe injection. A compromised third-party widget silently overlays a legitimate checkout form with an attacker-controlled iframe. The user sees the actual page, but the keystrokes are sent to the attacker. No changes are made to the merchant’s repository.
Exploitation of pixel tracker. Analytics and advertising pixels, which are almost universal on e-commerce sites, are loaded from external CDNs. If these CDNs are compromised, or the pixel provider itself is compromised, the tracking code running on every page becomes an exfiltration channel. The merchant’s code continues to call the same legitimate-looking endpoint as before.
DOM-based credential collection. A script loaded via Tag Manager silently listens for form field events on the login or payment page and captures the data before it is submitted. This attack is not visible to static scanners and resides entirely within event handlers registered at runtime.
Each of these follows the same logic as the Magecart case. That is, threats exist outside the repository, run in a context unobservable to static analysis, and target the gap between what is shipped and what actually runs in a user’s browser. How each vector maps to the tool’s coverage and what a defense-in-depth program across them all looks like is explained in detail in the guide linked below.
Why runtime monitoring is important (but not the only control)
For web supply chain threats like this Magecart campaign, continuous monitoring of what is actually running in a user’s browser is a key layer of direct visibility when an attack occurs. Client-side runtime monitoring platforms answer some questions that static tools cannot answer. “What code is currently running in the user’s browser and what is it doing?”
At the same time, runtime monitoring is only part of the picture. This works best as part of a defense-in-depth strategy. Static analysis and supply chain governance reduce the attack surface, and runtime monitoring catches what slips through the cracks and what resides entirely outside the repository.
Reconfiguring “testing”: Categories rather than abilities
Evaluating repo-centric tools like Claude Code Security against runtime attacks is a category error, not a product failure. It’s like hoping a smoke detector will put out a fire. It’s the wrong tool for the job, but the ideal tool for what it was designed for. A fire-safe building requires smoke detectors and fire extinguishers, and a secure website requires Claude Code Security and runtime monitoring in the stack. Magecart and similar client-side skimming attacks require a runtime window in the browser. Static repository scanning alone cannot determine where these attacks actually exist.
If you’re mapping tools to threat classes at the CISO level, we’ve put together a short guide on how code security and runtime monitoring work together across all vectors in the web supply chain, and where each becomes useless.
CISO’s Claude Code Security Guide →
CISO’s Claude Code Security Guide →
Source link
