Why “Harmless” File Types Like SVG Aren’t Harmless At All

The SVG Voicemail Scam That Ran for Two Months Unnoticed

Between June 1 and August 4, 2026, a phishing operation sent 26,589 messages to 5,527 organizations, each one disguised as a missed-voicemail notification. Email security vendor INKY, which detected and published the analysis, found that 99.5% of the messages worked the recipient’s own email address into the lure, and 95% spoofed the recipient’s own domain as the sender which arriving from an unauthenticated external source made to look internal. It was broad, high-volume spray, not a handful of targeted spear-phishing attempts: the largest single spike, on June 3, hit 2,432 messages across 1,149 organizations in one day.

The mechanism that let it run for two months comes down to one mislabeled field. The SVG attachments were tagged with a MIME type of text/plain instead of the correct image/svg+xml. Most email scanners key their classification on the MIME type a message declares, not on what the file actually contains, so a scanner saw “plain text” and moved on, while the attachment itself carried obfuscated JavaScript that reconstructed itself at runtime and reached out to a remote endpoint only after the file was already sitting in an inbox. Seventy-five percent of the messages scored a Microsoft Spam Confidence Level of 0–1 hence effectively invisible to spam filtering.

Why SVG Is Different From a “Real” Image

The reason this works on SVG specifically, and wouldn’t work the same way on a JPEG, is structural. A JPEG or PNG is a grid of pixel data — there’s no execution context inside it for a browser to run. An SVG file is XML. It’s markup, not pixels, and XML can carry more than shapes: SVG’s own specification supports embedded script tags and a foreignObject element that can wrap ordinary HTML inside what’s nominally an image file. Open one in a browser, which is what double-clicking an SVG attachment typically does, and you’re not viewing a picture. You’re rendering a small web page, complete with working links, forms, and any script the file chose to include.

Security researchers at Kaspersky’s Securelist documented the two dominant patterns: using script to inject clickable HTML that redirects to a credential-harvesting page, and embedding JavaScript that automatically pops a fraudulent login form the moment the file opens. Their detection data shows this isn’t a one-off: 2,825 SVG-based phishing emails in Q1 2025 alone, then 1,324 more in just the first half of April — a trend accelerating, not fading. The format’s flexibility is a legitimate feature for designers who want text and interactivity inside a graphic. It’s also exactly what a phishing kit needs.

SVG Isn’t Alone — The Pattern Repeats Across Formats

What makes the SVG story worth paying attention to isn’t that SVG is uniquely bad. It’s that SVG is the newest entry in a category of techniques that all exploit the same blind spot: a security tool trusts what a file claims to be, or what its extension suggests, rather than inspecting what it can actually do.

• HTML smuggling (MITRE ATT&CK T1027.006). Instead of attaching the malicious payload directly, the attacker embeds it a.k.a. encoded, inside a JavaScript Blob or a data URL, within an ordinary-looking HTML file. The HTML itself is genuinely benign at rest; it’s typically flagged with an innocuous MIME type like text/html or text/plain. The payload only gets reconstructed and written to disk client-side, inside the victim’s own browser, after the file has already sailed past the network gateway. MITRE documents APT29 using this to smuggle ISO files embedded in HTML email attachments, and EnvyScout malware built specifically to extract and write out the hidden blob. QakBot, tied to Black Basta ransomware operations, distributed ZIP payloads the same way.
• LNK Stomping (CVE-2024-38217). Windows shortcut (.lnk) files are supposed to carry a “Mark of the Web” tag once downloaded from the internet, which is what triggers Microsoft’s protected-view warnings. Elastic Security Labs researcher Joe Desimone disclosed a technique in 2024 for building deliberately malformed .lnk files — abnormal path structures that trick Windows Explorer into silently stripping that tag when it “normalizes” and re-saves the file. Samples using the pattern were sitting on VirusTotal for at least six years before anyone flagged the mechanism. Microsoft patched it in September 2024, and CISA added it to its Known Exploited Vulnerabilities catalog the same day — confirmation it wasn’t theoretical.
• Scripts appended to genuinely valid images. A SANS Internet Storm Center writeup published August 24, 2026 detailed a “ClickFix”-style loader, DOUBLECUP, that takes a fully valid PNG and appends a PowerShell script directly after the image data ends. The picture still opens fine. The appended script starts with a carriage-return/line-feed pair, a plain line terminator in Windows, which is enough for the attacker to extract it with nothing more exotic than the built-in findstr command, piped straight into PowerShell. No custom tooling, no real steganography — just a file that’s a little larger than it should be, and a scanner that never looked past the part of the file it expected to find.

The Common Thread

None of these techniques rely on a zero-day. They rely on a mismatch between the layer where security tools make their decision, a declared MIME type, a file extension, a magic-byte signature check, and the layer where the file’s real content lives. SVG and HTML formats are text by nature, so they can carry executable logic without ever tripping a “this is an executable” check. LNK files are metadata Windows itself is willing to rewrite, so the very act of the OS “helpfully” normalizing a path can erase the safety tag security depends on. A PNG with a script taped onto the end is still, technically, a valid PNG.

What This Means for Defenders

The practical lesson from all four examples is the same one, repeated in a different file format each time: never let a declared type stand in for an inspected one. A scanner that trusts a MIME-type header, a browser that trusts a file extension, or an OS that trusts its own re-saved metadata is trusting information the attacker gets to write. Catching this category of attack means looking past what a file says it is and checking what it’s actually structured to do by parsing the real content, not the label on the wrapper before it ever reaches a user’s inbox or reaches execution.

Sources