July 2026 Exchange Server security updates: confirm the build before removing the interim mitigation

The July 2026 Exchange Server security updates shipped on 2026-07-14, and they change what an operator is supposed to do with the CVE-2026-42897 mitigation that has been sitting on Outlook Web Access since May. Installing the update does not take the mitigation off. Microsoft lists removal as a separate manual step in the July release post, so the sequence belongs to whoever runs the estate: confirm the installed build first, remove the URL rewrite rules second, re-check third.

What changed

Three Microsoft posts define the current state of this CVE, and each one moved the guidance a step.

The May post now carries an update dated 2026-07-14 saying that the July 2026 Security Update, once installed, removes the recommendation to keep the CVE-2026-42897 mitigation in place. The July release post spells out the removal path under a heading that says so directly: if the mitigation was applied by the Exchange Emergency Mitigation (EM) Service, take out the M2.1.0 IIS rules; if it was applied with the Exchange on-premises Mitigation Tool from https://aka.ms/UnifiedEOMT, roll it back with the same tool.

Separate the fix from the advice; they moved on different dates. The code fix is in the June 2026 SU: the Learn mitigation table records M2's highest applicable version as the June 2026 SU on Exchange SE, 2019 and 2016, so a server at that build or later is outside the mitigation's scope and the EM service stops applying it there. Microsoft still recommended leaving the rules in place after June, and July withdrew that recommendation. The July SU changed the advice, not the fix.

The July SUs also close four vulnerabilities of their own, and none of them is CVE-2026-42897. KB5103212 lists CVE-2026-55005, CVE-2026-55006, CVE-2026-55008 and CVE-2026-55009. NVD records Microsoft's CVSS 3.1 base score of 9.6 for CVE-2026-55008, another spoofing issue reached through web page generation, and 8.8 for CVE-2026-55005, a heap-based buffer overflow that requires an authenticated attacker. July is a patch-now release on its own merits, before the mitigation cleanup is even considered.

June is a prerequisite for every future mitigation

The June 2026 release post carries a second item that outlives its own release. Because of a service-side change, the Exchange EM and Exchange Feature Flighting services cannot use configuration files released in July 2026 or later unless Exchange is on the June 2026 update or newer. Mitigations already downloaded and applied keep working. New ones stop arriving. A server parked on the February 2026 SU is unpatched and also deaf to the next emergency mitigation, which is the failure mode nobody notices until the next zero-day.

Who is affected

CVE-2026-42897 impacts on-premises Exchange Server 2016, Exchange Server 2019 and Exchange Server Subscription Edition at any update level, per Microsoft's May advisory. Exchange Online is not impacted. Hybrid organisations still have to install the SU on every Exchange server, including boxes kept only for management tooling.

The triage inputs that justify treating this as urgent are all public. NVD lists Microsoft's CVSS 3.1 base score of 8.1 (HIGH) with the vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, so no authentication is required and the attacker needs the target to open a crafted message in OWA. NVD's own analyst score is lower at 6.1. CISA added CVE-2026-42897 to the Known Exploited Vulnerabilities catalog on 2026-05-15 with a BOD 22-01 remediation due date of 2026-05-29, and the SSVC record attached to the NVD entry marks exploitation as active. EU operators are not bound by BOD 22-01, but a KEV listing with an active-exploitation flag is the strongest public signal available for a patch-priority argument in front of an auditor.

Coverage is also gated on the cumulative update baseline. SUs exist for Exchange SE RTM, Exchange Server 2019 CU14 and CU15, and Exchange Server 2016 CU23. Anything below those CUs cannot take the SU until the CU is installed first.

Note the major version in the last row. Exchange Server 2016 reports 15.1, not 15.2. A single expected version string cannot cover all four SKUs. A check written against one 15.2 string either flags every 2016 server as non-compliant when it is in fact fully patched, or, where that string is used as a selection filter, skips those servers so they are never evaluated at all. Compare each server against the row for its own SKU. Build numbers and release dates above are taken from the Microsoft Learn build-numbers table.

Tenant check

Run this from the Exchange Management Shell on a Mailbox server. It answers two questions in order: what build is actually installed, and what mitigation state each server is carrying.

# 1. Installed build INCLUDING security updates.
#    Microsoft Learn option 2: ExSetup file version is the authoritative SU-level build.
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo } |
    Format-List ProductVersion, FileName

# 2. Do NOT trust this one on its own. Learn option 3 documents that
#    AdminDisplayVersion shows the CU level and omits installed SUs and HUs.
Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

# 3. Mitigation state per server: enabled, applied, blocked.
Get-ExchangeServer | Format-List Name, MitigationsEnabled, MitigationsApplied, MitigationsBlocked

# 4. Full mitigation detail (ID, type, description, status) for one server.
#    Get-Mitigations.ps1 is a SCRIPT in V15\Scripts, not a cmdlet, and has no
#    -MitigationName parameter. Run it from that folder.
.\Get-Mitigations.ps1 -Identity <ServerName>

# 5. Confirm the EM service can still reach the Office Config Service.
.\Test-MitigationServiceConnectivity.ps1

# 6. Organisation-level switch. If this is False, EM applies nothing anywhere.
Get-OrganizationConfig | Format-List MitigationsEnabled

Expected output for step 1 on an Exchange SE RTM server that has the July SU installed is a ProductVersion of 15.02.2562.045, matching the table above. For step 3, Microsoft Learn documents MitigationsApplied as a list of mitigation IDs; an entry beginning M2 means the CVE-2026-42897 URL rewrite mitigation is still in force on that server.

Step 5 matters more than it looks. The EM service validates the signature on every mitigation XML it downloads, checking the issuer, the Extended Key Usage and the certificate chain. Microsoft's Learn page warns that routing officeclient.microsoft.com through an SSL inspection workflow could break that certificate validation logic. When it breaks, the server stops applying new mitigations, and the only signals are Event 1008 from source MSExchange Mitigation Service in the Windows Application Event Log plus the EM service log under V15\Logging\MitigationService, neither of which most monitoring watches.

Removing the M2 rules in the right order

Microsoft's Learn documentation lists the M2 rollback as three commands: back up the OWA web.config, then delete the outbound rewrite rule and its precondition. Run them per server, from an elevated Exchange Management Shell, only after step 1 of the tenant check confirms a June 2026 SU build or later.

# Back up the file being modified.
Copy-Item -Path "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config" `
  -Destination "$env:ExchangeInstallPath\FrontEnd\HttpProxy\owa\web.config.$((Get-Date).ToString('yyyyMMdd-HHmmss')).bak"

# Remove the M2 outbound rule.
Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" `
  -Filter "system.webServer/rewrite/outboundRules" -Name "." `
  -AtElement @{name="EEMS M2.1 OWA CSP - outbound"}

# Remove its precondition.
Remove-WebConfigurationProperty -PSPath "IIS:\Sites\Default Web Site\owa" `
  -Filter "system.webServer/rewrite/outboundRules/preConditions" -Name "." `
  -AtElement @{name="EEMS M2.1 OWA SPA HTML shell - precondition"}

# Re-check. MitigationsApplied should no longer list an M2 entry.
Get-ExchangeServer | Format-List Name, MitigationsApplied, MitigationsBlocked

The re-check is not ceremony. The EM service polls the Office Config Service hourly and reapplies any mitigation it still considers applicable, which is why the June release post told operators to block M2.1.0 before removing it: at that point Microsoft had not yet updated the mitigation to skip patched builds. The Learn table now excludes the fixed builds, and the July release post drops the blocking step. If the re-check shows M2 back in MitigationsApplied an hour later, block it explicitly with Set-ExchangeServer -Identity <ServerName> -MitigationsBlocked @("M2") and remove the rules again.

One caveat from the Learn page that catches people: site-level and vDir-level rewrite mitigations live in the relevant web.config and are cleared when a CU is installed, while server-level mitigations are written into applicationHost.config and stay until removed by hand.

Work out the exposure window on the estate in front of you

No published figure applies here, because the window is a property of the estate, not of the CVE. Compute it directly. For each internet-facing Exchange server, the window opens the moment the M2 rules are deleted from a server below the June 2026 SU, and it closes the moment a verified June 2026 SU build or later is serving OWA. Remove the rules only from servers already at that build and the value is zero.

Where the order slips, one formula covers it:

window = (median SU install + reboot + health check duration)
         x (number of internet-facing servers still at an unfixed build)

Assumption: servers are patched one at a time.
If members are patched in parallel, substitute the elapsed
time until the last member is verified.

Both terms come off the estate rather than off this page. The server count comes from Get-ExchangeServer narrowed to the internet-facing Mailbox servers still below the June build; the duration is the median recorded during the last patch cycle. Which shape applies depends on whether removal is scripted per server or fired once across the organisation; the organisation-wide variant puts every server into the window at once.

Limitations

This note stops applying in several places, and each of them is worth naming.

• Exchange Online only. If no on-premises Exchange server exists, none of this applies. Microsoft states Exchange Online is not impacted by CVE-2026-42897.
• Exchange 2016 and 2019 without Period 2 ESU. The July SU is not obtainable. The build check will keep failing and no command here changes that; the path forward is the ESU enrolment or migration to Exchange Server SE, and the relevant work is an Exchange migration to SE or Exchange Online rather than a patch cycle.
• The ESU window is finite. Microsoft's own framing covers Exchange 2016 and 2019 updates released between May and October 2026. This note says nothing about what happens after October 2026 and should not be read as implying a further period exists.
• Servers below the CU baseline. Below Exchange 2019 CU14 or CU15, or Exchange 2016 CU23, the SU will not install. The CU comes first and its own change surface is out of scope here.
• Air-gapped and EOMT-mitigated servers. The M2 rollback commands above target the EM Service rewrite rules. If the mitigation was applied with the on-premises Mitigation Tool, roll back with that tool instead; running the IIS commands is the wrong instrument.
• Internet Explorer and Edge in IE mode. Microsoft's May advisory records that the mitigation never protected those clients, because Internet Explorer does not support Content Security Policy. Mitigation state was never the whole answer for those users, and only the SU is.
• Version drift. Build numbers here are the July 2026 values. Microsoft revises the build-numbers table with every release, and an August or September SU supersedes every figure in the table above. Re-read the source rather than this page once a newer SU exists.
• No claim about the July CVEs. The four vulnerabilities the July SU fixes are named for triage, not analysed. Nothing here says whether they are exploited, and the KEV catalog is the place to check that before assuming they are not.

The tenant-side controls around a hybrid Exchange organisation, Conditional Access and privileged identity in particular, are a separate surface from the on-premises build state and are covered under Microsoft 365 tenant hardening.

Last verified 2026-07-28. Checked against the Microsoft Exchange Team release posts for the July and June 2026 Security Updates and the May 2026 CVE-2026-42897 advisory, the Microsoft Learn pages for Exchange build numbers and the Exchange Emergency Mitigation Service, KB5103212, the NVD records for CVE-2026-42897, CVE-2026-55005 and CVE-2026-55008, and the CISA Known Exploited Vulnerabilities catalog file dated 2026-07-27.