SVG phishing: when an image file becomes the attack

If you investigate suspicious email attachments, an .svg file deserves a closer look. It can look like an ordinary image while sending a recipient to a credential-harvesting page.

A voicemail notification arrives in your inbox. The message is short, the sender looks familiar, and the attachment ends in .svg. You open it and your browser shows a security check, followed by a sign-in page asking for your credentials. The attachment is the first stage of a phishing attack.

On August 27, 2026, INKY reported through Kaseya on a campaign that delivered 26,589 messages to 5,527 organizations between June 1 and August 4. The attackers used fake voicemail notifications and SVG attachments containing obfuscated JavaScript. They also declared the attachments as text/plain, which could confuse security controls that rely too heavily on the declared file type.

SVG phishing works because the format is both an image and structured markup that browsers can interpret.

What is an SVG file?

Unlike a JPEG or PNG, which stores an image as pixels, an SVG describes what should be drawn using XML markup.

That makes SVG useful for logos, icons, diagrams, and graphics that need to scale without becoming blurry. But the format can describe more than static shapes.

SVG can support hyperlinks, event handlers, external resources, embedded content, and scripting. MDN documents how SVG script elements can reference external scripts and warns about the risks of accepting untrusted script URLs.

Whether active content runs depends on how the SVG is rendered and the security context around it. But the important point is simple: an SVG should not automatically be treated like inert pixel data.

When a recipient opens a standalone SVG in a browser, the browser may process XML elements, links, events, and other supported active behavior. Attackers abuse that flexibility to turn an innocent-looking attachment into a redirector, a phishing page, or a launcher for the next stage of an attack.

Why attackers use SVG attachments

Attackers do not use SVG because every security product ignores it. They use it because the format gives them several ways to make the phishing chain less obvious.

The first advantage is perception. Most people associate image files with passive content. An attachment called Voicemail_Message.svg, Invoice_Copy.svg, or Document_Review.svg may not create the same suspicion as an executable or script file.

The second advantage is flexibility. Because SVG is XML-based, an attacker can put text, links, encoded strings, scripts, event-driven behavior, and external references inside the same document. Mimecast documented campaigns where attackers used embedded JavaScript in SVG attachments to redirect victims to credential-harvesting pages or malware delivery infrastructure.

SVG also gives attackers room to hide what the file is doing. URLs can be encoded, split into multiple strings, or constructed at runtime instead of appearing as one obvious destination inside the attachment.

The final phishing content can also live somewhere else. The SVG may only need to send the browser to the next stage. Cloudflare documented SVG phishing campaigns where the file acted as a scripted redirector to external credential-harvesting pages.

Inside an SVG phishing attack

In February 2026, Microsoft Threat Intelligence reported a large campaign that sent more than 1.2 million phishing messages to users at over 53,000 organizations across 23 countries between February 23 and February 25.

The emails used account statements, 401(k) updates, payment notices, overdue invoices, and voicemail notifications as lures. Many also contained a fake confidentiality notice to make the message feel more credible.

Each email carried an SVG attachment named to fit the lure.

The attack chain looked like this:

1. 1
   Phishing email
2. 2
   SVG attachment
3. 3
   Browser opens the SVG
4. 4
   External content is requested
5. 5
   CAPTCHA
6. 6
   Fake sign-in page
7. 7
   Credential theft

When the recipient opened the attachment, the browser contacted attacker-controlled infrastructure. The user first saw a security-check CAPTCHA. After completing it, they reached a fake sign-in page.

The CAPTCHA does more than make the page look legitimate. It can also make automated analysis harder, because a scanner may reach the first page without reaching the credential-harvesting page behind the interactive challenge.

Microsoft also saw SVG files become the most common delivery method for CAPTCHA-gated phishing in February before falling again in March. Do not expect one attachment type to remain dominant for long.

Attackers can change the delivery format quickly. The objective stays the same: move the victim from a believable email into an attacker-controlled authentication flow without exposing too many obvious indicators at the first stage.

How attackers hide URLs and user information inside SVGs

A suspicious SVG does not always contain one clear phishing URL waiting to be extracted.

Attackers can use encoding, string manipulation, external references, and personalization to make the document harder to understand.

One common technique is Base64 encoding. Base64 is not encryption. It turns readable text into a longer encoded string, making URLs, email addresses, and other values less obvious during a quick inspection.

The February 2026 campaign used this technique for personalization. Microsoft found that SVG filenames included a Base64-encoded version of the recipient's email address. The attackers combined that data with themes such as invoices, statements, retirement documents, and voicemail notifications.

Recipient data can help attackers create unique filenames, track interactions, generate victim-specific URLs, or pre-populate information later in the phishing flow.

The more recent voicemail campaign reported by INKY showed another form of personalization: 99.5% of observed subject lines contained the recipient's own email name.

Attackers can also build destinations from several values instead of storing one complete URL. A scanner that only searches raw text for obvious https:// strings may miss context that becomes clear only after the SVG is parsed.

Inspect the SVG for:

Detection signals

Do not rely on the .svg extension alone to detect SVG phishing.

First, compare the file extension, declared MIME type, and actual content. An .svg attachment declared as text/plain, as seen in the 2026 voicemail campaign, deserves additional inspection.

Next, inspect the SVG structure. A normal logo and a document containing obfuscated JavaScript are both SVG files, but their behavior is very different. Script elements, automatic events, encoded blobs, external requests, and redirect logic should increase scrutiny.

The surrounding email is just as important. Does this sender normally send SVG files? Does a voicemail service normally deliver recordings as vector images? Has the recipient communicated with the sender before? Does the attachment name contain recipient-specific information?

Campaign-level context can make weak signals much stronger. One unusual SVG may be inconclusive. Hundreds of messages with similar SVG structures, repeated JavaScript patterns, related domains, or slightly different filenames can expose a coordinated attack.

Useful detection signals include:

No single signal should decide the verdict. The strongest detection combines attachment behavior with sender identity, message intent, relationship history, infrastructure, and campaign activity.

How to analyze SVG attachments safely

Do not double-click a suspicious SVG on your normal workstation. Opening it in a browser may be exactly what the attacker expects.

Start with static inspection:

Move to controlled execution only when static analysis cannot answer the important questions. Use an isolated sandbox with no production credentials, and monitor browser activity, DNS requests, redirects, downloaded content, and follow-on processes.

Then widen the investigation. Search for similar attachments across other recipients, compare structure and behavior rather than filenames alone, and review sender history or authentication activity that followed delivery.

If a recipient entered credentials, treat the incident as a potential account compromise. Reset exposed credentials, revoke active sessions, remove suspicious persistence, and review mailbox and identity-provider activity.