Microsoft has initiated a significant security update for its Outlook email clients, specifically targeting the use of inline SVG images, which have become a potent vector for cyberattacks[1]. Starting in September 2025, Outlook for the web and the new Outlook for Windows will no longer render these images, instead displaying a blank space[1][2]. This change is a direct response to threat actors exploiting the XML-based nature of SVG files to embed and execute malicious scripts, leading to cross-site scripting (XSS), data theft, and system compromise[1]. The retirement of this feature is expected to affect fewer than 0.1% of all images used in Outlook, indicating a highly targeted mitigation against a specific, high-risk threat[1].
For security leadership, this action closes a notable security gap that was being actively exploited. A recent campaign used SVGs as “mini web pages” or full phishing kits, with a retrospective VirusTotal scan linking 523 SVG files to the activity, 44 of which were undetected by any antivirus engine at the time[2]. Justin Fier, SVP of Offensive Security, described Microsoft’s change as closing off “a powerful delivery vector for any attacker hoping to sneak active content into a message body”[2]. This move aligns the behavior of these Outlook clients with the classic Outlook desktop application, which has long blocked inline SVG rendering[1][3].
Technical Rationale and the SVG Threat
The core security issue with inline SVGs stems from their fundamental structure. Unlike raster images such as PNG or JPG, Scalable Vector Graphics (SVG) are XML-based text files. This allows them to contain embedded JavaScript, which can be executed automatically when the image is rendered by an application that supports it, such as a web browser or a permissive email client[1]. This capability transforms a seemingly harmless image into a vehicle for active code execution within the context of the user’s email session.
This method has been documented in security advisories from firms like Trustwave and VIPRE, which have detailed the rise of “SVG-borne phishing attacks”[2]. In a typical attack, a threat actor would craft an email with an inline SVG that references an externally hosted malicious script. When the email client renders the SVG, the script executes, potentially leading to session cookie theft, credential harvesting, or redirection to a phishing landing page. The technical implementation involves embedding the SVG directly into the HTML source code of the email, a process not typically available through the standard Outlook user interface[1][4].
Historical Context and Client Discrepancies
The challenge of securely handling SVG in email is not a new phenomenon. For over a decade, support for the format across various email clients has been inconsistent and problematic[6]. A Stack Overflow question from 2011 highlights that even then, SVG support was “very mixed,” with many webmail services and desktop clients choosing to block it entirely[6]. This historical lack of support was, in effect, an early security control.
Within the Microsoft ecosystem, the behavior has been particularly inconsistent. While the classic Outlook desktop application (often referred to as Outlook Classic) has consistently blocked the rendering of inline SVGs, displaying only a blank placeholder, Outlook for the web and the new Outlook for Windows client have until now rendered them[1][3]. Furthermore, user reports from as early as 2018 on the Inkscape Community Forum revealed a misleading implementation where Outlook and Word claimed to support SVG but performed a covert conversion to a JPG raster image upon insertion or sending[9]. A user named “Grobe” noted, “There is no svg when opening the mail, only an attached jpg image… Outlook clearly doesn’t attach the svg file in any way, it just does a dummy-conversion to jpg without notifying the user”[9]. This history shows a long-standing tension between feature support and security.
Impact and Required Actions
The primary impact of this change is on security, positively reducing the attack surface available to threat actors. However, there is a secondary impact on organizations or users who have come to rely on inline SVGs in their email signatures or marketing templates. Third-party signature management tools, such as the CodeTwo Signatures Web Add-in, may fail with an error stating “Your signature could not be inserted” if a signature contains an inline SVG[8]. This necessitates a proactive review and update of corporate email templates and signature systems.
The recommended alternative is to use high-resolution PNG or JPG files. To ensure sharp display on high-resolution screens, a best practice is to use an image with dimensions twice the intended display size and then set the HTML `width` and `height` attributes to half the original dimensions[8]. For example, to display a crisp image at 150×150 pixels on a 4K or Retina display, the source image should be 300×300 pixels, with the HTML attributes set to `width=”150″ height=”150″`. It is also advised to ensure all image dimensions are even numbers to avoid fractional pixel values during scaling, which can cause blurring[8].
The following table summarizes the behavior of different Outlook clients before and after this change:
| Outlook Client | Pre-Change Behavior (Inline SVG) | Post-Change Behavior (Inline SVG) |
|---|---|---|
| Outlook Classic | Blocked (showed placeholder) | No change (Blocked) |
| Outlook for the web / New Outlook | Rendered | Blocked (shows blank space) |
| Outlook Mobile | Renders | No change (Renders) |
It is critical to note that this change only affects inline SVGs. SVG files sent as standard email attachments will remain accessible to users, though they still pose a security risk if the user downloads and opens them in a web browser[1]. This distinction is important for security awareness training.
Relevance and Remediation Steps
This development is highly relevant for defensive security postures. Blocking a known and exploited code execution vector within the email client directly prevents a class of client-side attacks, reducing the burden on endpoint detection and user vigilance. For threat intelligence, it signals a continued trend of attackers abusing legitimate file formats and features, necessitating a focus on monitoring for shifts in TTPs (Tactics, Techniques, and Procedures) following this mitigation.
For system administrators and those managing corporate email environments, the remediation steps are clear. All existing email signatures and templates should be audited for the use of inline SVGs. Any found should be replaced with PNG or JPG images, following the high-resolution best practices outlined above. Security teams should consider updating their security awareness communications to remind users that while one vector is being closed, SVG files received as attachments should still be treated with caution and not opened unless from a trusted source.
Microsoft’s decision to retire inline SVG support in its mainstream web and new Windows clients is a calculated and security-focused move. It addresses a tangible threat that was being exploited in the wild with low overall disruption to legitimate email functionality. This action brings consistency to the Outlook client family and aligns Microsoft with the security-first approach long adopted by other major email platforms. Organizations should view this as an opportunity to harden their email security posture by proactively updating their digital assets to comply with this new, more secure standard.
