CVE-2026-45504 Part 2: Inside the WOPI SSRF and Arbitrary File Read

CVE-2026-45504 is a Server-Side Request Forgery vulnerability in on-prem Exchange Server 2016 and 2019, including Subscription Edition, rated CVSS 8.8 and disclosed by Microsoft on June 9, 2026 (KB5094139, KB5094140, KB5094142, KB5094144, depending on version and edition). Microsoft’s own advisory classifies it as an elevation-of-privilege issue: an authenticated attacker can abuse it to reach resources and privileges that shouldn’t be available from their session. Independent research published by HawkTrace narrows that description to something more specific: arbitrary local file read, triggered through Exchange’s own document-preview pipeline.

The feature involved is Exchange’s integration with WAC, the same rendering layer used for Office Online document previews, over WOPI, the protocol Office Online Server and SharePoint use to fetch and display files without a full desktop application. When a user views an email attachment inline in Outlook on the web, Exchange doesn’t render the file itself. It asks a WAC-capable service to do it, and that request travels through Exchange’s own OneDriveProUtilities component, in functions named GetWacUrl and TryTwice, which build the request and parse the response. Critically, the attachment being previewed doesn’t have to be a file already sitting in the mailbox. EWS supports a ReferenceAttachment type, meant for cases like SharePoint or OneDrive links, where the attachment is really just a pointer: a ProviderEndpointUrl that tells Exchange where to go get the content. That endpoint is meant to be a legitimate SharePoint or OneDrive host. CVE-2026-45504 exists because Exchange doesn’t verify that it actually is one.

An attacker who controls where that ProviderEndpointUrl points controls what Exchange’s own server-side code fetches, on Exchange’s own network position, with Exchange’s own credentials. That’s the SSRF. HawkTrace’s published write-up goes further and describes a URL-parsing quirk that lets the attacker’s endpoint hand back a file:// URL rather than an https:// one, with a crafted fragment that causes Exchange’s own OAuth parameters to be appended after the fragment marker, where the parser ignores them. The practical effect, per that research, is that Exchange ends up reading a local file on its own filesystem and returning the contents to the requesting session, rather than fetching a remote preview.

This post describes that mechanism at the level Microsoft and HawkTrace have already made public. It doesn’t reproduce the crafted request, the exact ReferenceAttachment payload, or working proof-of-concept code. HawkTrace’s own analysis and the public proof-of-concept repository, both linked at the end of this post, are the primary sources for anyone who needs the literal syntax, and they’re a better reference than a second-hand copy would be regardless. What’s worth taking from this post instead is the shape of the bug: a feature that lets an authenticated, low-privilege mailbox account tell the Exchange server to go fetch a resource of the attacker’s choosing, with no check on where that resource actually lives. SSRF bugs follow that shape constantly, across products. This is what it looks like inside a mail server that’s also trusted throughout the domain.

Part 3 connects this back to the credential side of the story, and to a specific account this blog has already spent two other series getting a working password for.

Sources for this post: Microsoft’s advisory for CVE-2026-45504, HawkTrace’s technical write-up, and the public proof-of-concept repository.