A Magecart payload can hide in the EXIF data of a dynamically loaded third-party favicon, and no repository scanner will find it because the bad code never actually touches your repo This article explores code security runtime. . As teams start using Claude Code Security for static analysis, this is the exact point where AI code scanning ends and client-side runtime execution starts.
You can find a full breakdown of where Claude Code Security ends and what runtime monitoring covers here. A Magecart skimmer that was recently found in the wild used a three-stage loader chain to hide its payload inside a favicon's EXIF metadata. It never touched the merchant's source code, never showed up in a repository, and ran entirely in the shopper's browser at checkout.
The attack makes us think about a question that needs to be answered: what kind of tool is supposed to catch this? It could help in situations where your own code has dynamic script-injection logic, which a code analysis tool might flag as risky, but it shouldn't be the main control. If first-party code hard-codes suspicious exfiltration endpoints or uses unsafe data-collection logic, static analysis can show those flows for review.
In a Magecart situation, the top four rows are the most important, and Claude Code Security can't see any of them while they are running. The last two pose a very different threat: a developer accidentally writing code that looks bad in their own repository.
Magecart is just one part of the attack surface, not the whole thing. The favicon steganography method above is advanced, but it's just one example of a larger pattern. Scanning a static repository by itself doesn't show where these attacks really happen.
If you're mapping tools to threat classes at the CISO level, we've made a short guide that shows how code security and runtime monitoring work together across all web supply chain vectors and when each one stops being useful. → The CISO's Guide to Claude Code Security
