A credit card skimmer campaign discovered in early 2025 and still actively tracked as of April 2026 has compromised an estimated 100 online stores by hiding malicious JavaScript inside a file most security tools would never think to inspect: a single-pixel SVG image. If you have shopped at a small or mid-size online retailer recently and noticed an unexpected charge on your card, this technique may explain how your data was stolen without anyone, including the store, realizing it happened.
How the attack works
SVG, or Scalable Vector Graphics, is an image format built on XML. Unlike a JPEG or PNG, an SVG file can legally contain embedded JavaScript because browsers treat it as structured markup, not just a picture. The attackers in this campaign exploit that dual nature by injecting a tiny SVG element, rendered as a single invisible pixel, directly into the HTML of a store’s checkout page.
When a shopper loads the checkout form, the browser parses the SVG and executes the JavaScript hidden inside it. That script quietly attaches itself to the payment form fields, capturing card numbers, expiration dates, CVV codes, and billing details as the customer types. The stolen data is then transmitted to a remote server controlled by the attackers. Because the legitimate transaction still completes normally, neither the shopper nor the merchant sees any sign of interference.
The technique is effective precisely because it exploits a trust assumption baked into most web defenses. Web application firewalls and content security policies routinely whitelist image files, treating them as inert visual assets. A 1×1-pixel SVG raises no file-size alarms and produces no visible change on the page. The malicious payload rides inside the image’s XML structure, where it can define inline scripts or event handlers that fire the moment the browser renders the element.
Which stores are affected
The campaign targets stores built on Magento, the Adobe-owned open-source e-commerce platform that powers a significant share of small and mid-size online retail worldwide. Security researchers tracking the activity have estimated that close to 100 Magento-based stores have been compromised, though no independent audit or formal breach notification has confirmed that number. No specific store names have been published as of May 2026.
The skimmer activates only on checkout pages, meaning it fires exclusively when a shopper is entering payment information. That selective triggering helps the malware evade automated security scanners that crawl product listings and other non-payment sections of a site. It also means that a store owner browsing their own homepage would see nothing unusual.
How the attackers gained initial access to inject the SVG code has not been publicly documented. Magento stores have historically been compromised through unpatched vulnerabilities, stolen admin credentials, and malicious third-party extensions. Whether this campaign exploited a new flaw or reused known entry points remains an open question. As of May 2026, Adobe has not released a public statement confirming the scope of the compromise or announcing mitigations specific to this vector. It is not known whether Adobe has been contacted for comment by the researchers who published the initial findings.
What makes this hard to detect
MageCart-style skimmers have been a persistent threat to online retail since at least 2018, when high-profile breaches at British Airways and Ticketmaster brought the tactic into public view. What distinguishes this SVG-based wave is the evasion method. Earlier MageCart campaigns typically injected malicious JavaScript through compromised third-party scripts, tampered CDN resources, or hidden iframes. Those approaches left signatures that security vendors learned to flag.
Hiding the payload inside an image file sidesteps many of those detection rules. Security tools that scan for suspicious script tags or external resource calls may not inspect the contents of what appears to be a harmless graphic. The SVG format’s ability to carry executable code is well-documented in web standards, but it is not something most e-commerce security configurations account for in practice.
Some secondary reporting has described the technique as hiding code inside “large pixel” SVG files rather than 1×1-pixel images. That discrepancy has not been resolved by any primary forensic source. “Large pixel” may refer to the file’s byte size on disk, which could be larger than a legitimate one-pixel image due to the embedded script, rather than its visual dimensions on screen. For defenders, the distinction matters less than the underlying behavior: any SVG element on a payment page that contains JavaScript should be treated as suspicious regardless of its pixel dimensions or file weight.
What online shoppers should do
Because this skimmer operates silently and leaves no visible trace on the checkout page, consumers have limited ability to detect it in real time. But there are practical steps that reduce exposure and catch fraud early:
- Monitor bank and credit card statements closely. Look for small, unfamiliar charges. Skimmed card data is often tested with low-value transactions before larger fraudulent purchases are attempted.
- Use virtual card numbers or one-time payment tokens when your bank or card issuer offers them. Services from major issuers like Capital One, Citi, and privacy-focused tools like Privacy.com generate disposable card numbers that limit what a thief can do with stolen data.
- Enable transaction alerts. Most banks and credit card apps allow real-time push notifications for every charge. This is the fastest way to spot unauthorized activity.
- Prefer well-known payment intermediaries. Checkout flows that redirect to PayPal, Apple Pay, Google Pay, or Shopify Payments never expose your raw card number to the merchant’s page, which means an on-page skimmer cannot capture it.
- If you suspect your card has been compromised, contact your issuer immediately to freeze or replace the card and dispute any unauthorized charges.
What merchants should do now
For merchants running Magento stores, the practical takeaway is blunt: standard image-file whitelisting is not sufficient to prevent script injection through SVGs.
The first step is to inspect the raw HTML of every checkout page template for unfamiliar SVG tags, especially those containing <script> blocks or event-handler attributes such as onload or onmouseover. Administrators should cross-reference recent file changes in the site’s template directory and review deployment logs for unexpected modifications. Where possible, compare production templates against a known-good version from source control to identify unauthorized insertions.
Beyond manual review, merchants should tighten content security policies to block inline script execution from image contexts. Web application firewalls need to be configured to inspect SVG content, not just file extensions or MIME types, and to flag any instance where an image resource contains executable code. Disabling SVG uploads entirely in the content management system is another option, though it may affect legitimate design assets.
The fundamentals still apply as well: regular vulnerability scanning, timely patching of Magento core and all extensions, and multi-factor authentication for every admin account. These controls reduce the likelihood that attackers can gain the access needed to plant skimmers in the first place.
Why this matters beyond Magento
The SVG skimming method signals a broader shift in how attackers conceal malicious code on the web. If a one-pixel vector image can carry a full card-stealing payload past web filters, other XML-capable formats, including certain document previews and embedded vector graphics, could serve the same purpose on any site that accepts or displays user-uploaded content. E-commerce platforms are the immediate targets, but any web application that renders SVG from untrusted sources faces a version of the same risk.
For security teams across industries, the lesson is that trust decisions based purely on file type or visual appearance are increasingly unreliable. Defensive controls need to account for what a resource can do inside the browser, not just what it looks like on the page. Treating SVG as potentially active content, subject to the same scrutiny as JavaScript or HTML templates, is an adjustment that many organizations have not yet made.
As more forensic details about this campaign surface, the merchants and security teams that will fare best are those that act on the known behavior now rather than waiting for a final incident count.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
