CVE-2026-45504 Part 4: Detection, Hardening, and Patching Priority
The single highest-leverage action against CVE-2026-45504 is also the least interesting one to write about: patch. Microsoft shipped fixes for every affected version and edition on June 9, 2026 (KB5094139, KB5094140, KB5094142, KB5094144), and a public proof-of-concept has existed since shortly after disclosure. Every day an on-prem Exchange server goes unpatched past that date is a day it’s exploitable by anyone holding one working mailbox login, which, per Part 3, is a lower bar than most of the credential-access techniques this site has covered. Patch status should be treated the same way this blog has treated every other post-disclosure proof-of-concept: as an active, not theoretical, risk.
Detection has to work at two layers, because the vulnerability itself spans both. On the Exchange server, EWS and OWA activity logging is the first place to look. A ReferenceAttachment pointing at a ProviderEndpointUrl outside of known-good SharePoint or OneDrive hosts is not normal attachment-preview traffic, and Exchange’s own message tracking and IIS logs record enough about EWS calls to build a baseline of what legitimate WOPI provider hosts actually look like in a given environment. An account suddenly generating ReferenceAttachment requests against endpoints it’s never touched before is a reasonable anomaly signal, independent of whether the specific request matches this CVE or the next SSRF bug in the same feature area.
The second layer is the network, and it’s the one this site already has tooling for. Exchange servers have a fairly predictable outbound profile: talking to other Exchange servers, domain controllers, and a small number of known external services. A server-side request forgery bug, by definition, gets the Exchange process to make an HTTP request it wouldn’t otherwise make, often to a host nobody in the organization has ever configured Exchange to talk to. Watching the Fabric covers building exactly this kind of outbound-traffic baseline and alerting on deviation from it using FortiAnalyzer and FortiMonitor, and Impacket Deep Dive Part 10 makes the same argument from the AD side: internal hosts making connections they’ve never made before is one of the more reliable signals available, precisely because it doesn’t depend on recognizing any specific exploit.
None of this replaces patching, and none of it is specific to Exchange. It’s the same defense-in-depth argument this site keeps returning to across the Impacket, Pivoting and Tunneling, and BloodHound series: assume some layer will eventually fail, and make sure the layers around it are watching for exactly that failure. Password Cracking Part 8 already made the credential-side half of that argument for this specific series. svc-legacy-scan’s password should never have stayed valid for six years, and Kerberos pre-authentication should never have been disabled on an account that didn’t need it disabled. CVE-2026-45504 is the other half: even a properly rotated, properly scoped mailbox credential is worth more than it should be, on a server that trusts it more than it should, until the WOPI request it can trigger gets validated the way every other server-side request should be.