Hackers Are Hiding Malware in 1-Pixel SVGs — What Every Designer Needs to Know About SVG Security in 2026

A Single Pixel Stole Millions in Credit Card Data

On April 7, 2026, security researchers at Sansec discovered something chilling: 99 Magento e-commerce stores had been silently compromised by a credit card skimmer hidden inside a 1×1 pixel SVG element. The entire malware payload — the fake checkout form, the data encryption, the exfiltration logic — was encoded in a single onload attribute.

No external scripts. No suspicious network requests to flag. Just one invisible pixel, quietly stealing every credit card number entered on the checkout page.

The entry point? A vulnerability called PolyShell (APSB25-94), disclosed in mid-March 2026, that affects every production version of Magento Open Source and Adobe Commerce. By the time Sansec found the skimmers, 56% of all vulnerable stores had already been targeted — within just one week of the vulnerability's disclosure.

And here's the worst part: as of April 12, 2026, Adobe has not released a production security patch. The fix exists only in a pre-release alpha build (2.4.9-alpha3+). An estimated 130,000 online stores running Magento remain vulnerable, representing $173 billion in annual gross merchandise value.

Step 1: The PolyShell Entry

The attacker exploits Magento's REST API file upload functionality. When a product option has type "file," Magento processes an embedded file_info object with base64-encoded file data. The uploaded file is a polyglot — it functions simultaneously as a valid image AND an executable script.

According to Searchlight Cyber's analysis, the file is written to pub/media/custom_options/quote/ on the server, and depending on server configuration, leads to remote code execution (RCE) or stored XSS leading to account compromise.

Active exploitation began on March 19, 2026 — just two days after disclosure. No less than 50 IP addresses engaged in automated mass scanning (source).

Step 2: The Invisible SVG

Once inside, the attacker injects a tiny SVG element into the store's HTML:

<svg width="1px" height="1px" onload="(()=>{setTimeout(atob('KGZ1bmN0aW9uKCl7IGlm...'),1)})()"></svg>

The entire skimmer payload is base64-encoded inside an atob() call and executed via setTimeout. As Sansec's researchers noted:

"

This technique avoids creating external script references that security scanners typically flag. The entire malware lives inline, encoded as a single string attribute.

Step 3: The Fake Checkout

When a buyer clicks checkout, the script intercepts and displays a convincing "Secure Checkout" overlay — complete with a lock icon for perceived legitimacy. The form includes credit card fields and billing address, with real-time Luhn validation of card numbers. Victims see exactly what they expect to see.

Step 4: The Exfiltration

Captured payment data is:

1. XOR-encrypted with the key "script"
2. Base64-obfuscated via btoa()
3. Sent via fetch() POST with no-cors mode (fallback: hidden iframe; some variants use WebRTC for stealthy exfiltration)
4. Routed to /fb_metrics.php — disguised as Facebook analytics

Six exfiltration domains were identified, all hosted at IP 23.137.249.67 (IncogNet LLC, AS40663, Netherlands):

A _mgx_cv key is set in the browser's localStorage after data capture, preventing duplicate victim submissions. On April 10, IncogNet confirmed they deactivated the offending account — but the underlying Magento vulnerability remains unpatched.

Security researchers at Fortinet have documented four primary SVG attack vectors:

1. Cross-Site Scripting (XSS) — SVGs support ECMAScript via <script> elements. Any SVG with a script tag can execute arbitrary JavaScript in the viewer's browser.

2. HTML Injection — The foreignObject element enables XHTML embedding inside SVGs, bypassing HTML context restrictions that would normally prevent injection.

3. XML Entity Processing — Internal and external entity declarations can expose sensitive data or trigger server-side request forgery (SSRF). The classic "Billion Laughs" attack uses recursive entity expansion.

4. Denial of Service — Recursive xlink:href usage with <use> elements can crash XML parsers by creating infinite loops.

Dangerous SVG elements and attributes to watch for:

Recent high-severity CVEs involving SVGs:

• CVE-2026-33172 (CVSS 8.7) — Statamic stored XSS via SVG reupload bypasses sanitization
• CVE-2026-22610 (CVSS 8.5) — Angular XSS via SVG script attributes; sanitization schema fails to recognize href and xlink:href on SVG <script> elements. Fix requires Angular v21.0.7+.

IBM X-Force tracked a global SVG phishing campaign throughout 2025 targeting financial institutions, using weaponized SVGs with embedded JavaScript for multi-stage malware infections. Infrastructure included Amazon S3 and Telegram for C2.

How Can You Protect Your SVGs? (Interactive Checklist)

Whether you're a designer uploading SVGs to client sites, a developer building an upload feature, or an e-commerce store owner, these seven rules will protect you:

Recommended sanitization libraries:

SVGs created by manual coding or exported from design tools can contain event handlers, scripts, or metadata that you didn't intentionally add. SVGs downloaded from unknown sources are even riskier.

VectoSolve takes a fundamentally different approach. We generate SVGs from raster images using Recraft AI — the output is pure vector geometry:

• No JavaScript — our SVGs contain only <path>, <circle>, <rect>, and other shape elements
• No event handlers — no onload, onclick, or any other executable attributes
• No foreignObject — no embedded HTML or iframes
• No external references — no xlink:href to remote URLs
• SVGO post-processing — every SVG is optimized and stripped of unnecessary metadata, comments, and editor data

Our SVGs are clean by design, not by sanitization. There's nothing malicious to strip because we never generate it in the first place. The entire pipeline is: raster image → AI vectorization → SVGO optimization → clean SVG output.

1. Search your HTML source for SVG tags with onload containing atob()
2. Check browser localStorage on your checkout page for _mgx_cv
3. Monitor server logs for requests to /fb_metrics.php
4. Block connections to IP 23.137.249.67 and the six domains listed above
5. Search for files in pub/media/custom_options/quote/ that shouldn't be there
6. Apply the pre-release patch (2.4.9-alpha3+) or implement WAF rules
7. Consider a full security audit — if PolyShell was exploited, other backdoors may exist

If you work with SVGs:

1. Complete the security checklist above — all 7 items
2. Never upload SVGs from untrusted sources without server-side sanitization
3. Use <img> tags (not <object> or <iframe>) to render external SVGs
4. Set Content-Security-Policy headers to block inline scripts
5. Generate your SVGs through vectorization tools like VectoSolve that produce clean output by design

Need clean, safe SVGs? Try VectoSolve — our vectorization produces pure geometry with zero executable code. No scripts, no surprises.