Traditional phishing attachments (macro-docs, PDFs) are losing traction. Attackers are pivoting to a lesser-suspected vector: SVG vector files, which look like harmless graphics yet contain interactive, script-enabled code. According to recent research by Hoxhunt, SVG attachments were nearly negligible in 2024 (~0.1 % of attacks) but ballooned to 4.9 % of phishing lures in just the first half of 2025 — and peaked near 15 % in March 2025.
Why does this matter? Because SVGs combine trust (image format) + capability (XML, scripting, external references) — making them ideal for stealthy, high-impact phishing.
What Makes SVGs Special (and Dangerous)
- SVG = Scalable Vector Graphic, i.e., text-based XML describing shapes, colors & links. So although an “.svg” extension suggests an image, under the hood it can act like a mini-web-page.
- Since SVG files are text/XML, they can embed:
<script>blocks or event handlers (e.g.,onmouseover,onclick)- Data URIs or base64-blobs pointing to malicious payloads
- Redirects, external links, “fake button” SVG elements that send users to credential harvesters
- Psychological Trust: Most users (and many security gateways) assume image attachments = safe. An invoice graphic, company logo, shipping label — all can be made via SVG and appear innocuous. The lure: “Open this graphic” rather than “Open this macro-document.”
- Technical Evasion: Because many gateways treat “image” attachments with lower scrutiny, embedded scripts or external references inside the SVG may bypass standard filters. Plus, attackers rotate domains, CDNs, blob names to evade signature-based detection.
- Operational Advantage: Attachment-first delivery (rather than link) helps bypass link-based scanners. Combine that with brand-styled visuals (“View Invoice”, “Open Shipping Label”) and you get a convincing social-engineering push.
Real-World Trend: Statistics & Growth
- In 2024, SVG-based phishing was essentially niche (~0.1 % of phishing lures) per Hoxhunt.
- By H1 2025, that figure rose to 4.9 %. In March alone it peaked around 15 % of phishing attachments.
- In short: this isn’t a one-off gimmick — it is a fast-growing vector.
- Observers note that as macro-document attachments become more locked down (Office defaults, email gateways), attackers shift to less scrutinized formats like SVG, HTML attachments, LNK files, etc.
Attack Flow – Example Scenario
- User receives an email with subject: “Invoice_0425_ShippingLabel.svg” or “Please view your statement”.
- The attachment is an SVG file that renders the recipient’s company name/logo + a “View Invoice” button.
- On clicking the button (embedded in SVG), the file uses an
<a href>oronclickto redirect the user to a credential-harvesting site, or triggers a script that steals session tokens or initiates MFA bypass. - Because the initial file looked like a logo/graphic, the user lets down their guard; meanwhile attachment scanning may have ignored the file or treated it as safe image.
- By the time the gateway blocks the redirection domain, the user has already entered credentials or approved malicious activity.
- From there the attacker may pivot — hijack session, move laterally, exfiltrate data.
Why It’s a Growing Problem
- Email gateways and endpoint software have improved for typical phishing (macro attachments, .exe, .pdf) → attackers go for formats with lower visibility.
- SVGs blur the line between “image” and “code” – many organizations treat them as assets rather than threats.
- The combination of brand-faithful design + image perception = high click-rates.
- Legacy filters often inspect file extension or MIME-type rather than deep content (XML tags, script blocks, external references).
- Supply-chain/mailing-list attachments often include graphics (logos, labels, marketing assets) — attackers piggyback on that trust environment (e.g., “Your invoice graphic is attached”).
Defenses & Best Practices
Policy & Prevention
- If your business does not need to receive SVG attachments → block them entirely at the secure email gateway. Allow only safer formats (PNG, JPG for images).
- If you must allow SVGs: enforce server-side sanitization or Content Disarm & Reconstruction (CDR) — strip scripts, event handlers, external references, enforce safe rendering.
- Render SVGs in a sandboxed viewer inside your environment that forbids outbound calls, JavaScript, iframes, external link calls — then log any attempted external fetches.
- Tune your email gateway/SEG to inspect inside the SVG (not just “image attachments”). Specifically flag:
<script>oronload/onmouseoverattributesdata:URIs orbase64blobs inside XML<foreignObject>,<a href>referencing external domains- Domains/CDNs embedded in XML that rotate rapidly
- Maintain a block/allow list for domains/CDNs used inside SVG attachments. Monitor domains that appear inside attachments and feed them back into blocklists.
People + Process
- Treat SVG as an active file type, not just a “picture”. Educate users accordingly: don’t trust invoice graphics/labels blindly, especially if from unverified vendor or unexpected sender.
- Include SVG phishing simulations in your phishing awareness drills — replicate real-world style: short subject lines, branded graphics, “click to view” images.
- Monitor “time-to-click” metrics, attachment types vs link-only phishing campaigns: track which types succeed more often, which employees click, and identify control gaps.
- Incident response should include:
- Isolate the mailbox, preserve the original SVG, inspect it in a safe viewer → check for
href,script,base64blobs. - Check if credentials were entered or secondary actions (MFA, OAuth consent) occurred; revoke sessions, tokens, rotate passwords.
- Update filter rules to capture that SVG variant (signature, blob pattern, domain) so future ones are blocked faster.
- Feed intelligence into SEG, WAF, and IR systems.
- Isolate the mailbox, preserve the original SVG, inspect it in a safe viewer → check for
Key Takeaway
SVG phishing is not a passing fad — it represents a strategic shift in phishing tactics: moving toward file-centric social engineering that leverages image trust + hidden code. Legacy defences treat “.svg” as “safe image”; attackers exploit that gap.
If your organization doesn’t need SVG attachments, block them. If you do, treat them with the same care as executable files: sanitize, sandbox, monitor, educate, get a professional website security services. Because attackers will continue evolving — defence is not “set & forget”; it’s continuous improvement.
