Exchange OWA Inline Images Disappeared After May 2026: Root Cause and Fix

Last updated: May 20, 2026

⚠️ Update May 20, 2026: If images are broken in classic Outlook desktop (not OWA) — this is a separate Microsoft bug introduced in build 19929.20164+, unrelated to EEMS. See the Outlook Desktop Bug section at the bottom.

The Problem

Users started reporting that screenshots pasted into emails were no longer visible in OWA. The images showed up fine in Outlook desktop, but anyone reading the same message through the browser saw an empty space where the image should be, or a Download link instead.

The issue affected all users, all mailboxes, both Exchange servers. Nothing in the server configuration had changed. No IIS errors. No Exchange service failures.

The Investigation

The usual suspects turned out to be innocent:

• IIS AppPools – all started and healthy
• Exchange services – all running
• OWA virtual directories – correctly configured
• Transport rules – no RTF or TNEF-related rules
• Remote Domain settings – TNEFEnabled was already False
• GPO for Outlook message format – applied but made no difference

The key diagnostic clue came from the email headers. Every message sent with a pasted screenshot showed:

Content-Type: application/ms-tnef; name="winmail.dat"

This is the TNEF (Transport Neutral Encapsulation Format) container – the classic winmail.dat problem. Outlook wraps messages containing clipboard-pasted images in TNEF, and OWA cannot render inline images from TNEF containers.

But this had worked before. Something changed.

The Real Cause: CVE-2026-42897 Mitigation

On May 14, 2026, Microsoft disclosed CVE-2026-42897, a cross-site scripting vulnerability in Exchange OWA with a CVSS score of 8.1. The vulnerability allows an attacker to execute arbitrary JavaScript in a user’s browser by sending a specially crafted email that the recipient opens in OWA.

Microsoft confirmed active exploitation in the wild. CISA added it to the Known Exploited Vulnerabilities catalog.

To protect on-premises Exchange servers immediately, before a permanent patch was ready, Microsoft automatically deployed mitigation M2.1 through the Exchange Emergency Mitigation Service (EEMS). This service is enabled by default on Exchange 2016 and later, and it applied the mitigation silently on May 14, 2026.

The mitigation added a URL Rewrite rule to the OWA frontend web.config that appends a Content-Security-Policy header to HTML responses:

script-src-attr 'none'

This blocks inline script execution – which is exactly what the XSS exploit needed. But it also broke inline image rendering in OWA as a side effect. Microsoft acknowledged this in their advisory:

“Inline images might not display correctly in the recipients OWA reading pane.”

How We Confirmed It

Checking the mitigation service logs confirmed the exact moment M2.1 was applied:

2026-05-14T17:16:29.250Z,MAILSERVER1,ApplyMitigation,
S:Message=Mitigation M2.1 is currently applied

And the rule was visible in the OWA frontend web.config:

Select-String -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
  -Pattern "M2.1|rewrite" -CaseSensitive:$false

Output confirmed the presence of:

<rule name="EEMS M2.1 OWA CSP - outbound" ...>
    <action type="Rewrite" value="{R:1}; script-src-attr 'none'" />
</rule>

Timing matched perfectly: the mitigation was applied on May 14, which was the same day users noticed inline images had stopped working.

How to Check Mitigation Status

Exchange 2016

Use the built-in script from Exchange Management Shell:

cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"
.\Get-Mitigations.ps1

If M2.1 shows as Applied with Type UrlRewrite – that is your problem.

You can also do a quick check directly in web.config on each server:

Select-String -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
  -Pattern "M2.1|rewrite" -CaseSensitive:$false

Any output means M2.1 is present. No output means the rule is not applied.

Note: Get-Mitigation and Set-Mitigation are Exchange 2019+ only and will throw a CommandNotFoundException on Exchange 2016.

Note: On some Exchange 2016 servers the EM Service may show an error Index was outside the bounds of the array when trying to apply mitigations. This is a bug in the mitigation engine on older builds. The mitigation may still get applied on some servers but not others, which can explain inconsistent behavior across a DAG.

Exchange 2019 and newer

Use the native cmdlet from Exchange Management Shell:

# List all mitigations and their current status
Get-Mitigation

# Check M2.1 specifically
Get-Mitigation -Identity M2.1 | FL

If M2.1 shows as Applied – that is your problem.

All versions – check EEMS status across all servers at once

Get-ExchangeServer | FL Name, MitigationsEnabled

The Fix

Before removing the mitigation, understand the tradeoff. CVE-2026-42897 is actively exploited. Removing M2.1 exposes your OWA to the XSS vulnerability until Microsoft releases a permanent patch. Evaluate your own risk posture – perimeter controls, email filtering, WAF coverage, before proceeding.

If you decide to remove the mitigation:

Step 1: Back up the web.config

Copy-Item `
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config.M2.1.bak"

Step 2: Remove the M2.1 rewrite block

$file = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config"
$content = Get-Content $file -Raw

$blockToRemove = @"
        <rewrite>
            <outboundRules>
                <rule name="EEMS M2.1 OWA CSP - outbound" preCondition="EEMS M2.1 OWA SPA HTML shell - precondition" patternSyntax="ECMAScript" stopProcessing="false">
                    <match serverVariable="RESPONSE_Content_Security_Policy" pattern="(.*)" />
                    <action type="Rewrite" value="{R:1}; script-src-attr 'none'" />
                </rule>
                <preConditions>
                    <preCondition name="EEMS M2.1 OWA SPA HTML shell - precondition" logicalGrouping="MatchAll" patternSyntax="ECMAScript">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                        <add input="{REQUEST_URI}" pattern="^/owa/?(`$|\?|default\.aspx|projection\.aspx|readingPane\.aspx|popout\.aspx)" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
"@

$newContent = $content.Replace($blockToRemove, "")
Set-Content $file -Value $newContent -Encoding UTF8
Write-Host "Done"

Step 3: Restart IIS

iisreset /noforce

Step 4: Verify the block is gone

Select-String -Path "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" `
  -Pattern "M2.1|rewrite" -CaseSensitive:$false

No output means the rule has been removed.

Step 5: Repeat on every Exchange server in your DAG

Each server has its own web.config. The mitigation is applied per-server, so you need to remove it from each one individually.

Critical: Preventing EEMS from Re-applying M2.1

⚠️ This step is mandatory. If you only remove the rewrite rule from web.config without disabling EEMS, the mitigation will be automatically re-applied within a few hours. EEMS checks mitigation status periodically and restores any missing rules.

After removing the rule on each server, disable EEMS so it does not restore M2.1 automatically. The commands differ depending on your Exchange version:

Exchange version	Command	Effect
2016	Set-ExchangeServer -MitigationsEnabled $false	Disables EEMS entirely
2019+	Set-Mitigation -Identity M2.1 -Action Disable	Disables M2.1 only, EEMS stays active
2019+ (alternative)	Set-ExchangeServer -MitigationsEnabled $false	Also works, but disables all of EEMS

On Exchange 2019 and newer, the targeted approach is preferred – it blocks M2.1 from returning while keeping EEMS active for future emergency mitigations.

Exchange 2016

Run from Exchange Management Shell (not regular PowerShell):

# Check current EEMS status
Get-ExchangeServer -Identity <ServerName> | FL MitigationsEnabled

# Disable EEMS
Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $false

# Verify
Get-ExchangeServer -Identity <ServerName> | FL MitigationsEnabled
# Expected: MitigationsEnabled : False

Note: Get-Mitigation and Set-Mitigation are Exchange 2019+ only and will throw a CommandNotFoundException on Exchange 2016.

Exchange 2019 and newer

# Check all mitigations and their status
Get-Mitigation

# Disable M2.1 only — EEMS remains active
Set-Mitigation -Identity M2.1 -Action Disable

# Verify
Get-Mitigation -Identity M2.1 | FL

All versions – check all servers at once

Get-ExchangeServer | FL Name, MitigationsEnabled

Note: Disabling EEMS entirely (Exchange 2016) means Microsoft can no longer push emergency mitigations to your servers automatically. This is a deliberate tradeoff – you are taking responsibility for monitoring CVE announcements and applying patches manually. When Microsoft releases the permanent fix for CVE-2026-42897, re-enable:

# Exchange 2016
Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $true

# Exchange 2019+
Set-Mitigation -Identity M2.1 -Action Enable

How to Roll Back

If you need to restore the mitigation, you have two options regardless of Exchange version.

Option 1: Restore web.config from backup (all versions)

Copy-Item `
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config.M2.1.bak" `
  "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\web.config" -Force

iisreset /noforce

Option 2: Re-enable EEMS and let it restore M2.1 automatically

Exchange 2016:

Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $true
Restart-Service MSExchangeMitigation

Exchange 2019+:

# Re-enable M2.1 specifically (if you only disabled the mitigation)
Set-Mitigation -Identity M2.1 -Action Enable

# Or if you disabled EEMS entirely, re-enable it first
Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $true
Restart-Service MSExchangeMitigation

EEMS will re-apply M2.1 within an hour.

What to Watch For

Microsoft has stated they are working on a permanent security update that will fix CVE-2026-42897 without the inline image side effect. Monitor the Exchange Team blog at techcommunity.microsoft.com/blog/exchange for the release announcement.

When the permanent patch is available:

• Install it on all Exchange servers
• Re-enable EEMS on Exchange 2016: Set-ExchangeServer -Identity <ServerName> -MitigationsEnabled $true
• Re-enable EEMS on Exchange 2019+: Set-Mitigation -Identity M2.1 -Action Enable (or Set-ExchangeServer if you disabled it entirely)
• The URL Rewrite mitigation M2.1 will no longer be needed

Outlook Desktop Bug: Separate Issue

If users report that images are broken in the classic Outlook desktop client (not OWA), this is an entirely separate issue that coincided with the EEMS mitigation by timing.

Microsoft officially acknowledged this bug on May 18, 2026.

Starting with Version 2604 Build 19929.20164+ of Microsoft 365 Apps / classic Outlook, images using Wrap Text: Top and Bottom formatting stop rendering. The error message is identical:

“The linked image cannot be displayed. The file may have been moved, renamed, or deleted.”

Key diagnostic: open the same email in an older Outlook (e.g. Office 2016) – the image will display correctly. The issue is in the new build of the Outlook client, not on the Exchange server.

How to confirm:

1. Open the affected email in classic Outlook
2. Ribbon → Move → Actions → Other Actions → View Source
3. Search for cid — if you see <v:imagedata src="cid:image001.png@..."> and the image still does not render, you are hitting this bug

Official workaround: Avoid setting images with Wrap Text → Top and Bottom. For screenshots pasted via Ctrl+V, try inserting via Insert → Pictures → This Device instead, which avoids the wrap text setting.

Status: Microsoft is investigating. No patch released yet. Reference: Microsoft Support KB 74600b12

Summary

What	Detail
What happened	EEMS automatically applied mitigation M2.1 for CVE-2026-42897 on May 14, 2026
Side effect	Inline images stopped rendering in OWA reading pane
Root cause	CSP header script-src-attr 'none' blocks inline content including images
Fix	Remove the URL Rewrite rule from FrontEnd HttpProxy OWA web.config
⚠️ Critical extra step	Exchange 2016: Set-ExchangeServer -MitigationsEnabled $false — Exchange 2019+: Set-Mitigation -Identity M2.1 -Action Disable — otherwise rule returns automatically
Risk	CVE-2026-42897 XSS vulnerability is re-exposed until permanent patch is installed
Permanent fix	Pending – Microsoft is working on a security update
Separate Outlook bug	Build 19929.20164+ breaks image rendering in classic Outlook desktop – unrelated to EEMS, Microsoft investigating