Do Not Blindly Whitelist Image Files: A 2026 Blue Team View

In our last post on SIEM log selection we said something that needs an immediate correction, or at least a very large footnote: strip static content like images, stylesheets and fonts from your proxy logs to save volume. That advice is still correct for cost, and it is also exactly the assumption that has let red teams walk into environments for the last three years. “It is only an image” is not a security property. It is a file extension.

This post is the other half of that conversation. If you are going to whitelist a file type, you need to know what that file format can actually do, because in almost every case the answer is more than you think.

Why Does “It Is Just an Image” Fail as a Security Assumption?

Every whitelist rests on a mental model of what a file type is. JPEG and PNG are containers of pixel data, so the mental model roughly holds. The problem is that the word “image” also covers formats that are not pixel data at all.

SVG is the clearest example. A Scalable Vector Graphics file is not an image in the sense a PNG is. It is an XML document that a browser parses and renders, and the SVG specification permits script elements, event handler attributes, external references, and a foreignObject element that can embed arbitrary HTML inside the graphic. When a browser opens an SVG directly, it renders it as a document with a full DOM. Your email gateway, your upload validator and your proxy log filter all classified it as image/svg+xml and moved on.

The numbers now reflect this. According to Hoxhunt’s 2026 phishing trends research, malicious SVG attachments rose roughly fiftyfold in 2025 compared to the previous year, and SVG now sits as the third most common malicious attachment type behind PDF and HTML. Microsoft’s Q1 2026 threat reporting described a single SVG-based campaign between 23 and 25 February 2026 that delivered around 1.2 million messages to more than 53,000 organisations across 23 countries. These are not fringe techniques any more.

💬 “On one engagement the client’s attachment policy blocked executables, archives, scripts, ISOs and macro-enabled documents. Comprehensive, genuinely well designed. Images were explicitly allowed because ‘the marketing team sends logos all day’. That single line in the policy was the whole entry path, and the blue team had no attachment telemetry for it because images were also excluded from gateway logging.”

What Can an SVG File Actually Do?

Without getting into anything you could copy and paste, the relevant capabilities are worth understanding at a conceptual level, because you cannot write a sensible policy for a format you have not read the specification of.

• Script execution in browser context. SVG supports script elements and inline event handlers. Opened directly from disk or served by a web server, that script runs.
• Embedded HTML. The foreignObject element allows HTML content inside the SVG, including form elements. This is how credential harvesting pages get shipped as attachments.
• External references. Links, embedded fonts and image references can pull content from remote infrastructure, giving the attacker tracking and staged delivery.
• Arbitrary text payloads. Because it is XML, an SVG can carry encoded data of any kind inside attributes or comments that the renderer ignores but a script reads.

For web applications, the risk is stored cross site scripting. If your app accepts SVG uploads, stores them, and later serves them back from your own domain, you have handed an attacker script execution in your origin. Session cookies, tokens, any DOM the user can see. This is not a theoretical finding, it is one of the most reliable wins available on any application that has an avatar or logo upload feature and validates only the MIME type.

The fix is not complicated, which makes the frequency of the bug more annoying. Serve user-uploaded files from a seperate origin that shares no cookies with the application, set Content-Disposition: attachment so the browser downloads rather than renders, apply X-Content-Type-Options: nosniff, and sanitise SVG server side with a library such as DOMPurify configured for SVG rather than trusting the extension or the declared content type.

📌 Official Resource: The OWASP File Upload Cheat Sheet covers validation, storage location, content type handling and the SVG problem specifically. Visit Official Website

Are PDFs Still Dangerous in 2026?

PDF remains the single most common malicious attachment type, but the threat model has shifted and a lot of defensive tooling has not caught up.

The old model was exploitation – a malformed PDF triggering a memory corruption bug in the reader. That still happens, but it is now the minority case. The modern PDF attack is almost entirely a delivery wrapper. The document contains a link, a QR code, or an embedded file, and its job is simply to get past a scanner that inspects the email body and not the attachment contents.

This is why QR code phishing statistics look strange in 2026. KnowBe4’s research found that in-body QR usage dropped to under 4 percent of phishing emails, while roughly 64 percent of QR codes are now placed inside an attachment rather than the message body. Microsoft separately reported QR-code phishing volume rising 146 percent over Q1 2026. The technique did not decline, it moved inside a file type everyone whitelists.

File Type	Common Assumption	What It Can Actually Carry	Log or Block?
SVG	Harmless image	XML with script, embedded HTML, forms, remote references	Block at gateway, always log
PDF	Static document	JavaScript, embedded files, launch actions, QR codes, links	Allow with sandboxing, always log
HTML / HTM	Web page	Full script execution, HTML smuggling of binaries	Block at gateway
ICS calendar invite	Meeting request	Embedded links, spoofed organisers, auto-added events	Allow, log, inspect URLs
LNK shortcut	Harmless pointer	Arbitrary command execution with a custom icon	Block at gateway
ISO / IMG	Disk image	Container that strips Mark of the Web from contents	Block at gateway
XLL / add-ins	Excel plugin	Native code loaded by Excel, no macro prompt	Block at gateway and by policy
OneNote / .one	Notes file	Embedded arbitrary attachments behind click-through	Block or heavily restrict

What Happened to Office Macros, and What Replaced Them?

Here is where a lot of defensive documentation in circulation is genuinely out of date. Microsoft began blocking VBA macros by default in files originating from the internet in 2022, across Word, Excel, PowerPoint, Access and Visio on Windows, after having already disabled Excel 4.0 XLM macros by default. The Mark of the Web attribute is what drives that decision.

That change worked. Macro-based initial access collapsed. What it did not do was reduce intrusions, because attackers simply moved to formats that do not carry the Mark of the Web through to their contents, or that sidestep file delivery altogether:

1. Container formats such as ISO and IMG, and to a lesser extent password protected archives, because files extracted from them historically did not inherit the origin marking that triggers the macro block.
2. LNK shortcut files, which can execute a command line while displaying whatever icon the attacker chooses.
3. XLL add-ins, which Excel loads as native code and which never show a macro warning at all.
4. ClickFix and its variants, which skip the file entirely and socially engineer the user into pasting a command into the Run dialog, Explorer address bar or a terminal.

That last one matters more than the rest combined. Recorded Future’s Insikt Group assesses ClickFix will remain a primary initial access vector through 2026, and Microsoft’s Digital Defense reporting placed copy-paste execution ahead of traditional phishing among observed initial compromises. MITRE has since added a dedicated sub-technique, T1204.004 Malicious Copy and Paste, to describe it.

The defensive lesson is uncomfortable. If your attachment policy was written around the macro era and has not been revisited since, you are filtering for a technique that largely retired itself while the replacements pass straight through. These kind of policies age badly and nobody schedules a review of them.

📌 Official Resource: Microsoft’s documentation on macros blocked from the internet, including how Mark of the Web drives the behaviour and how to manage exceptions. Visit Official Website

Which Whitelists Cause the Most Damage?

Whitelisting happens in at least four places in a typical enterprise, and most teams only think about one of them. From an offensive perspective, these are ranked roughly by how often they hand us something useful.

1. Antivirus and EDR path exclusions. The single most valuable misconfiguration in any environment. Somebody excluded a build directory, a backup agent path, or an entire drive letter to fix a performance complaint in 2019 and nobody revisited it. Anything dropped into that path is invisible. Exclusions should be scoped to a specific process and a specific file pattern, never a bare directory, and every one of them should have an owner and a review date.

2. Proxy and gateway logging exclusions. This is the direct continuation of our SIEM post. Dropping image and static content requests from indexed logs saves enormous volume, and it is the right call for the pixel formats. But an exclusion rule written as “content-type starts with image/” silently covers SVG too. Carve SVG out of that rule explicitly. The same applies to any rule that excludes CDN domains wholesale, since attacker payloads are routinely hosted behind the same CDNs your business relies on.

3. Upload validation allow-lists. Validating by file extension or by the Content-Type header the client supplied is not validation. Both are attacker controlled. Check the actual file signature server side, re-encode images where you can, and treat any format that a browser will render as a document rather than a picture as an executable content type.

4. Email attachment policy. Blocking a list of bad extensions is a losing game because the list is always one technique behind. An allow-list of business-necessary types, combined with detonation for documents and stripping or rewriting for anything active, ages considerably better.

💬 “We found an EDR exclusion on an entire software distribution share during one assessment, added by a packaging team years earlier. We did not need a single novel technique after that. The most interesting part was the debrief, where three of the four blue team members did not know the exclusion existed and the fourth had approved it as a temporary measure.”

There is a common thread here. Almost none of these are failures of the security tooling. They are failures of documentation and review. Someone made a reasonable decision with the information they had, and the environment changed around it.

How Do You Whitelist Safely?

You cannot avoid whitelisting. Volume, cost and business usability all demand it. What you can do is make each exception deliberate rather than inherited.

1. Write down what the format can do before you allow it. If nobody on the team can describe the format’s capabilities, that is your answer for now.
2. Separate “do not block” from “do not log”. These are two different decisions and conflating them is how blind spots form. Allowing a file type through the gateway while still recording its transit costs almost nothing and preserves your investigation.
3. Exclude by specific type, never by category prefix. Name image/png and image/jpeg explicitly rather than matching image/* and inheriting whatever gets added to that category next.
4. Give every exclusion an owner, a reason and an expiry date. An exclusion with no expiry is permanent by default, which is how a temporary fix from 2019 is still live.
5. Validate server side using content, not metadata. File signatures over extensions, always, and re-encode where the format allows it.
6. Review quarterly against current threat reporting. The attachment landscape changed materially between 2022 and 2026, and it will change again.
7. Test your own exclusions. If you have a red team or a purple team exercise budget, the exclusion list is the highest value thing you can point it at.

If you only take one action from this post, make it the second point. Most organisations we assess have reasonable blocking policy and terrible visibility into what their policy allowed through, which means an incident that starts inside a whitelisted file type is invisible from the very first minute.

Frequently Asked Questions

Should we block SVG attachments entirely at the email gateway?

For most organisations, yes. Legitimate business email almost never requires an SVG attachment, and the format’s rise as an attack vector makes the trade-off straightforward. If a design or marketing team genuinely needs it, route those files through a file sharing platform instead.

Are PNG and JPEG files safe to whitelist?

They are far safer than SVG because they carry pixel data rather than markup, and browsers do not execute anything from them. The residual risk is parser vulnerabilities and steganographic payloads retrieved by malware already on the host, neither of which a gateway whitelist meaningfully affects.

Do Office macros still matter now that Microsoft blocks them?

They matter less for internet-sourced files, since Mark of the Web triggers the block by default. They still matter for documents arriving through channels that do not apply that marking, and for internal lateral movement, so macro execution telemetry remains worth collecting.

How do I check whether my proxy exclusions cover SVG accidentally?

Search your filtering rules for any wildcard matching on the image content type category, then test by requesting a known SVG through the proxy and confirming it appears in your logs. Many teams discover the gap only when they run that test.

What is the most commonly forgotten whitelist in an enterprise?

Antivirus and EDR path exclusions, without much competition. They are added under operational pressure, rarely documented properly, and almost never expire, which makes them extremely reliable for an attacker who finds them.

Is blocking file types still useful when ClickFix does not use files at all?

Yes, because attackers use whichever vector is cheapest and file-based delivery has not disappeared. Attachment controls and clipboard-execution detections address different stages and neither substitutes for the other.

---

Final Thoughts

The pattern behind every example in this post is the same. A file extension became a shorthand for a risk level, the shorthand was encoded into a rule, and then the format’s actual capabilities drifted away from the assumption while the rule stayed put. SVG was always XML. PDF always supported active content. Nothing new was invented, attackers just noticed the gap between the policy and the specification.

The impact of these gaps are consistently underestimated by defenders, mostly because a whitelist produces no alerts by definition. You do not get a daily reminder that a rule exists. You find out during an incident, or during an assessment, and one of those is considerably cheaper than the other.

If you take this seriously, start with an audit rather than a redesign. Export every exclusion you have across EDR, proxy, email and upload validation into one list, and for each line write down who owns it and why it exists. In most environments that exercise alone surfaces two or three entries nobody can justify. That is a good afternoon’s work and a genuinely better security posture by evening.