If malicious code, such as a Magecart payload, is hidden within the EXIF data of a favicon that’s loaded from a third party, standard repository scanning won’t detect it because the code isn’t directly in your repository. While teams are using Claude Code Security for static analysis, this shows exactly where AI code scanning ends and client-side runtime execution starts.

You can find a detailed explanation of Claude Code Security’s limitations and the scope of runtime monitoring here.

A Magecart attack discovered recently utilized a three-step process to conceal its malicious code in a favicon’s EXIF data. This code never appeared in the merchant’s code or repository but ran directly in the shopper’s browser during checkout. This raises the important question: What type of security tool is supposed to catch this?

Magecart‑like attacks usually aren’t due to common vulnerabilities in your own code but rather are caused by supply chain breaches. The malicious JavaScript usually comes from compromised third‑party resources like tag managers, payment/checkout tools, analytics, CDNs, and images loaded into the browser when it’s running. The organization didn’t create the code, doesn’t review it, and it’s often not in their repository.

This means a tool that analyzes your repository, like Claude Code Security, will be limited in this case. It can only analyze the code inside your repository or what you provide to it. It can’t detect malicious code that exists entirely in modified third‑party resources or dynamically loaded files. This isn’t a flaw but rather a limitation in its scope.

Here’s the initial code loader found on affected websites:

This code dynamically loads a script from what seems like a legitimate Shopify CDN. That script then constructs the actual malicious URL, using complex arrays:

Once decoded, the script connects to //b4dfa5[.]xyz/favicon.ico. The interesting part is that the script retrieves the favicon, parses the EXIF data to extract a malicious string and executes the code through new Function() — the payload resides within image metadata, remaining hidden from anything that doesn’t monitor the browser’s runtime activity.

The final call sends the stolen payment information to a server controlled by the attacker:

This process has four crucial aspects: the original loader looks like a safe third-party item, the malicious code is hidden in image metadata, the information theft happens directly from the shopper’s browser, and the merchant’s own code isn’t directly affected.

Claude Code Security is designed to scan codebases, track data flows, and suggest fixes for vulnerabilities in code written by your team. This makes it effective for securing your direct applications, but it’s not able to defend against this type of attack.

It has no way of seeing malicious code injected into third‑party, CDN, or tag‑manager‑hosted scripts that aren’t in your code repositories. It can’t analyze code hidden in images that aren’t part of your project. It also can’t assess the potential danger of domains used by attackers or detect unusual network requests during checkout. These are outside its capabilities.

Claude Code Security could be useful (but not as the primary defense) if your own code includes dynamic script injection, which code analysis tools may identify as risky. Also, static analysis can highlight any suspicious data collection or exfiltration endpoints found in your code.

The top four items are the most important in a Magecart scenario, and Claude Code Security can’t monitor any of them during runtime. 

The bottom two represent a different threat: a developer unintentionally writing questionable code within their own repository.

The favicon technique described above is sophisticated, but it’s part of a wider problem. Web supply chain attacks occur through several different methods, all having one similar characteristic: the malicious activity happens while the website is running, in the user’s browser, using resources not created by the merchant. See how AI-generated, polymorphic JavaScript is increasing the risks →

Here are a few more examples:

Malicious iframe injection. A compromised third-party widget secretly adds an attacker-controlled iframe on top of a legitimate checkout. The user sees the real page, but their keystrokes get sent to the attacker. The merchant’s code doesn’t change.

Pixel tracker abuse. Analytics and advertising pixels — used on nearly every e-commerce site — are loaded from external CDNs. If those CDNs are compromised, or the pixel provider is breached, the tracking code on every page becomes a way to steal data. The merchant’s code still connects to the same safe-looking endpoint it always did.

DOM-based credential harvesting. A script loaded through a tag manager silently monitors form field events during login or checkout, collecting data before it’s submitted. The attack lives only in the event handler, not in anything a static scanner would see.

Each of these follows the same logic as the Magecart example: the threat exists outside the repository, executes in a situation that static analysis can’t monitor, and exploits the difference between the code you built and what your users’ browsers actually run. You can view the full analysis illustrating how each method is covered with different tooling and the components of a comprehensive protection strategy in the guide linked below.

For web supply chain threats just like this Magecart attack, ongoing monitoring of what’s actually happening in users’ browsers, is the primary way to see the attack as it happens. Client‑side runtime monitoring solutions answer these questions, which static tools can’t: “What code is currently running in my users’ browsers, and what is it doing?”

At the same time, runtime monitoring provides just part of the solution. It’s best used as part of a multi-layered approach. Static analysis along with third-party supply‑chain management reduces the attack surface, while runtime monitoring catches anything that gets through and anything that does not live inside the code repository.

It’s a mistake to evaluate a repository-based tool like Claude Code Security against a runtime attack, not a deficiency. That’s like expecting a smoke detector to extinguish fires. It’s the wrong tool for the task, but the ideal one for its intended purpose. For a fire-safe building, you need smoke detectors as well as fire extinguishers, and for a secure website, you need both Claude Code Security and runtime monitoring. To detect and prevent Magecart and similar client‑side skimming attacks, you need runtime monitoring for browser activity because Static repository scanning doesn’t detect them.

For CISOs mapping tooling to threat classes, we’ve created a guide explaining how code security and runtime monitoring work together across all types of web supply chain threats — and when each one is no longer effective.