CVE-2026-45504 is a low-privileged, authenticated Exchange mailbox user can trick on-prem Exchange into reading arbitrary local files (config files, credential material) via a WOPI/WAC URL-parsing flaw. Microsoft patched it June 9, 2026. A public PoC dropped June 24, 2026. If you haven’t patched, do it now, exploitability just went from “less likely” to “trivial.”
Summary
- CVE: CVE-2026-45504
- Type: Elevation of Privilege via SSRF (CWE-918)
- CVSS 3.1: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
- Microsoft severity: Important
- Disclosed: June 9, 2026 (Patch Tuesday)
- PoC public: Yes, since June 24, 2026 (HawkTrace, GitHub)
- Affected: Exchange Server 2016 (CU23), Exchange Server 2019 (CU14/CU15), Exchange Server Subscription Edition (RTM)
- Not affected: Exchange Online
Microsoft’s original exploitability assessment said exploitation was “less likely.” A public PoC now exists, and the technique is simple enough to replicate quickly.
Reading our article? Try our product:
Root cause
The bug lives in Exchange’s WOPI/WAC integration — the code path that generates document-preview URLs for Outlook Web App. The relevant call chain (GetTokenRequestWebResponse → GetWacUrl → OneDriveProUtilities.TryTwice) fetches a WOPI provider’s OData XML response and pulls out WebApplicationUrl, AccessToken, and AccessTokenTtl — without validating the URL scheme on WebApplicationUrl.
That missing scheme check turns a garden-variety SSRF into arbitrary local file read. The trick is a URI fragment:
- Attacker stands up a malicious WOPI endpoint.
- The endpoint returns WebApplicationUrl: file:///C:/windows/win.ini#
- Exchange appends OAuth query parameters to build the “final” URL: file:///C:/windows/win.ini#&access_token=…&access_token_ttl=…
- Everything after the # is a URI fragment and gets dropped by the parser. The effective path stays file:///C:/windows/win.ini.
- Exchange issues the request via FileWebRequest, reads the file off disk, and hands the contents back to the requester.
Attack chain
No admin access required, just a mailbox:
- Attacker (any authenticated, low-privileged mailbox user) uses Exchange Web Services to create a ReferenceAttachment whose ProviderEndpointUrl points at an attacker-controlled server.
- Victim opens or previews the attachment in OWA (or another Exchange client).
- Exchange automatically fires a GetWopiTargetPropertiesByUrl request to the attacker’s endpoint.
- The attacker’s server returns the malicious file:// URL as described above.
- Exchange reads the file and serves it back through Exchange’s own response.
The public PoC demonstrates this against Exchange Server 2019, pulling C:\Windows\win.ini as a proof case — but the technique generalizes to any file the Exchange service account can read, including config files and credential material that enable further privilege escalation.
Patches
| Version | Build | KB |
|---|---|---|
| Exchange Server 2016 CU23 | SU22 | KB5094144 |
| Exchange Server 2019 CU14 | — | KB5094142 |
| Exchange Server 2019 CU15 | SU8 | KB5094140 |
| Exchange Server Subscription Edition RTM | SU7 | KB5094139 |
Note: Exchange 2016 and 2019 are past end of support; if you’re still receiving security updates for them, you should already be enrolled in Extended Security Updates. Subscription Edition is the only branch with a normal support lifecycle going forward.
What to do
Patch. This is the actual fix, there’s no real mitigation that closes the hole, only ones that reduce exposure while you get the update deployed.
If you can’t patch immediately:
- Restrict and monitor EWS access; flag any ReferenceAttachment objects with ProviderEndpointUrl values pointing to unfamiliar external domains.
- Restrict outbound traffic from Exchange servers to untrusted hosts — the attacker’s WOPI endpoint has to be reachable from the Exchange server for this to work.
- Watch for unusual WOPI/WAC token requests correlated with outbound connections to unknown infrastructure, and for unexpected local file access patterns on Exchange hosts.
- Run the Exchange Server Health Checker after patching to confirm install success and catch dependent issues.
After patching, validate the build number against the KB articles above — cumulative update misalignment is the most common reason orgs think they’re patched when they aren’t.
