Sending Logs, Alerts, and Telemetry Through a Data Diode

Find Out How
We utilize artificial intelligence for site translations, and while we strive for accuracy, they may not always be 100% precise. Your understanding is appreciated.

SVG-Delivered Malware Is Flooding Emails. Here Is What Actually Blocks It.

The file contains no macro, executable, or known signature. It instead carries a script that runs the moment your browser opens it. This is why security teams are re-evaluating how attachments are handled before delivery.
By David Mitchell, VP, Products
Share this Post

Key Takeaways

  • SVG files are not binary image data like JPEG or PNG. They are XML-based and can contain executable script that a browser will run immediately upon opening.
  • Malicious SVG attachments increased fifty-fold in 2025 compared to 2024 and now rank as the third most common malicious email attachment type globally, according to Hoxhunt's 2026 Phishing Trends Report.
  • Each SVG payload is personalized to the recipient's email address. The redirect destination is split, encrypted across multiple variables, and assembles only at runtime, appearing as gibberish to any scanner that reads the file statically.
  • Traditional detection depends on recognizing known attack patterns, whether through signatures or heuristics.
  • Deep CDR™ Technology removes active content from supported image files before they reach the user, regardless of whether the threat has been seen before. No signature and no prior exposure are required.

No Macro. No Executable. Just an Image Capable of Executing Script.

On June 2, 2026, SANS Internet Storm Center handler Xavier Mertens published an analysis of a fresh phishing campaign that had been landing in his inbox for several days. The attachment in each email was an SVG file, the kind of file most people associate with icons, illustrations, and web graphics. Nothing about it suggested a threat.

Double-clicking it opened the default browser, the embedded script ran silently, and the browser redirected to a credential-harvesting page personalized to the recipient's email address. There was zero indication that anything had happened until it was too late.

The attack required no special software, no macro-enabled document, and no user permission beyond the reflex to open an attachment. The entire mechanism relied on a common assumption: that an image file is inherently low risk.

JPEG Renders. SVG Executes. That Difference Is the Attack.

The assumption is understandable. JPEG and PNG files are rendered as pixel data, limiting their attack surface at the file level.

SVG is different. It is written in XML (Extensible Markup Language), the same markup language that underlies web pages, which means an SVG file can contain script tags, anchor elements, and other active web content that a browser processes the same way it would any web page.

That is the capability attackers are exploiting. The files in the campaign Mertens analyzed contained no graphical content at all. They were purely code: obfuscated JavaScript wrapped in the thinnest possible SVG shell, where the SVG container existed for one reason only, which was to reach the victim's browser while being classified as an image attachment by the email gateway.

Why This Has Become a Pressing Issue

SVG as an attack vector is not new, but its use at scale has accelerated. Researchers have documented malicious SVG attachments in email since around 2017, which raises the obvious question of what changed to make this a problem worth discussing today.

Two things changed, primarily.

First, scale changed dramatically. Malicious SVG attachments increased fifty-fold in 2025 compared to 2024 (Hoxhunt 2026 Phishing Trends Report), and in a single campaign in February 2026, Microsoft tracked delivery of 1.2 million SVG-based phishing messages to more than 53,000 organizations across 23 countries. The technique is not new, but the industrial adoption of it is.

Second, the defensive landscape shifted in ways that made SVG more attractive. Microsoft disabled Office macros by default in 2022, PDF-based threats came under heavier scrutiny, and SVG arrived at many gateways with a relatively clean reputation history, which meant attackers following the path of least resistance quickly found SVG very appealing.

The evasion technique Mertens documented is subtle. The JavaScript embedded in the SVG is declared using the type application/ecmascript rather than the standard text/javascript, and while browsers treat both identically and execute scripts labeled with either, the divergence between what browsers accept and what security tools inspect is precisely where the attack happens.

When RFC 9239 updated the standard in 2022, security vendors followed it and removed application/ecmascript from their inspection lists. Browsers, built for backward compatibility, kept executing it anyway. The standard said the type was retired. Browsers never got that memo.

The result is a durable gap. application/ecmascript is not a novel or obscure identifier but has a history stretching back to the early 2000s. Attackers did not invent it. They noticed that the RFC transition created an asymmetry between browsers running the old behavior and scanners enforcing the new standard, and that asymmetry does not close on its own. Any gateway that has not explicitly added deprecated ECMAScript MIME aliases back into its inspection rules remains exposed, not because it is outdated, but because it implemented a standard that browsers did not follow.

How the Attack Is Personalized in Order to Reach the Inbox

The recipient's address is encoded in Base64 and embedded directly in the SVG payload, which means every single attachment in this campaign generates a unique, personalized phishing URL aimed at one specific recipient, at close to zero cost.

That level of personalization matters because it defeats the heuristics that catch generic campaigns, since there is no repeated payload, no shared redirect URL, and no pattern that scales across recipients the way mass phishing does.

The redirect destination is encoded in Base64 and then encrypted using a key assembled from two separate variables at runtime. This is not sophisticated cryptography, but what makes it effective against automated scanners is the key assembly itself.

Detection systems that attempt to reverse obfuscation need to know both the algorithm and the key, and the key here does not exist as a single value anywhere in the file. It is split across two variables and concatenated only at execution, which means a scanner cannot reconstruct the destination URL without first resolving the runtime assembly, and that requires executing the script rather than just reading it. Static analysis yields little usable signal, and the payload only becomes readable inside a live browser environment, which is exactly where most gateway inspection does not happen.

Each evasion layer alone might be caught, but stacked together, an attachment format categorized as an image, an obsolete MIME type, an encrypted payload, and a destination domain on a top-level domain with limited abuse history combine to increase the probability of reaching the inbox significantly.

Your Gateway Did Not Fail. The Attack Sidestepped Detection.

Detection-based email security operates on a fundamental question: does this file match a known or recognizable threat? Its effectiveness depends on prior knowledge, whether through signatures or behavioral patterns.

That dependency is the structural limitation this campaign exposes. The obfuscation stacking means there is genuinely little for a scanner to find, and the SVG categorization means the file may not receive the same scrutiny as an Office document or executable. If your gateway classifies SVG as an image format and applies lighter inspection accordingly, this campaign was likely not caught at the gateway level. This is a case where the attack operates outside what detection can evaluate.

This is not an argument that detection does not work. It works well against known threats, and no email security architecture is effective without it. The question is what happens with entirely novel threats that detection systems have never seen before.

Prevention-First Means Preemptively Removing All Active Content

A prevention-first approach introduces a complementary response alongside detection: does this file still contain active content?

Deep CDR™ Technology does not attempt to determine whether a file is malicious. Instead, it deconstructs the file, removes any potentially malicious or out-of-policy elements, and delivers a sanitized, usable version. For an SVG carrying active script, that means the user receives a file that renders as intended if there is legitimate graphical content, but without the script that enables the attack.

This approach is validated by the first-ever 100% rating in SE Labs content disarm and reconstruction test, which recognized Deep CDR™ Technology as the first-ever CDR solution to achieve a 100% Protection and Accuracy score.

Not every threat is neutralized by sanitization alone. Evasive payloads, meaning files engineered to appear benign under static analysis and activate only at runtime, require behavioral inspection that goes beyond what sanitization covers. MetaDefender Aether™ covers that gap through dynamic sandbox analysis, exposing malicious behavior through emulation and returning a single trusted verdict. With a 99.9% zero-day detection rate, Aether addresses the residual exposure that sanitization and multiscanning alone are not designed to address.

A Pattern Worth Watching Beyond SVG

SVG is the current example and it will not be the last. The pattern is broader than SVG: any file format that looks legitimate while concealing executable content is a candidate for the same treatment.

HTML attachments smuggle payloads past gateways. QR codes embedded in PDFs redirect to credential-harvesting pages. Steganographic payloads hide inside image metadata. In each case the file is exactly what it claims to be at the structural level, while carrying content that the surface-level classification check was never designed to find.

The lesson is not that any specific format is dangerous. It is that "this file looks harmless" is no longer a defensible basis for delivery decisions. When a file passes every detection check, should it be automatically delivered, or should it be sanitized regardless?

How OPSWAT Applies a Multi-Layered Approach to Email Security

Everyday attackers act with the assumption that detection is the last line of defense. For us, it’s part of a multi-layered approach that combines different technologies to maximize security at the perimeter for our customers. MetaDefender™ Email Security applies that logic across two deployment models:

  • MetaDefender™ Email Gateway Security deploys on-premise as software at the SMTP/MX level. Deep CDR™ Technology across 200+ file types removes active content from every attachment and recursively scans nested archives for deep sanitization, Metascan™ Multiscanning across 30+ AV engines runs detection in parallel, Predictive Alin AI delivers a verdict in milliseconds whether the attachment contains threats without detonation, MetaDefender Aether™ sandbox technology covers evasive payloads that require deeper behavioral analysis, and Proactive DLP™ technology prevents leaks at the source across 125+ file types.
  • MetaDefender™ Cloud Email Security applies the same prevention-first question inside Microsoft 365 environments with no MX record changes, no hardware, and no disruption to mail flow. Deep CDR™ Technology, MetaDefender Aether, Metascan Multiscanning with up to 17 AV engines and Predictive Alin AI inspect and sanitize every attachment across inbound and outbound email, including encrypted files, before they reach the user.

Stay Up-to-Date With OPSWAT!

Sign up today to receive the latest company updates, stories, event info, and more.