Full technical details and a working public proof-of-concept exploit landed in early July for CVE-2026-45504, a server-side request forgery (SSRF) flaw in on-premises Microsoft Exchange that lets an authenticated, low-privileged user read arbitrary files off the server. By feeding Exchange a file:// URL through its document-preview (WOPI) path, an attacker turns a trusted internal request into an arbitrary-file-read primitive — enough to pull configuration files, credentials, and other secrets. Microsoft patched the CVE in its June 9, 2026 security updates; the reason it matters now is that HawkTrace has released a detailed writeup and a GitHub PoC, so exposure for any unpatched, internet-facing Exchange server has jumped sharply.

What the Vulnerability Is

The bug lives in Exchange’s OneDriveProUtilities component, in the code that fetches WOPI (Web Application Open Platform Interface) data and access tokens to render document previews. Functions such as TryTwice and GetWacUrl build outbound HTTP requests from a URL that ultimately comes from attacker-influenced input, and pass it straight into WebRequest.CreateHttp with no scheme validation.

The attack chain works like this. A low-privileged user creates a specially crafted reference attachment via Exchange Web Services (EWS) whose ProviderEndpointUrl points at an attacker-controlled server. When that attachment is accessed or previewed, Exchange makes a backend request to the attacker’s server to retrieve WOPI metadata. The attacker’s server replies with a malicious WebApplicationUrl — not an http(s):// URL, but a local file URI such as file:///C:/Windows/win.ini#.

The trailing # is the trick: when Exchange appends its own OAuth query parameters to the URL, everything after the fragment is discarded by the URI parser, preserving the original file path intact. Exchange then issues a FileWebRequest against the local filesystem and hands the file’s contents back to the attacker. Because Exchange trusts the WebApplicationUrl value returned by the remote endpoint and never restricts non-HTTP schemes, an SSRF becomes a straight arbitrary-file-read. The flaw was discovered and reported by Batuhan Er of HawkTrace, who published both the technical analysis and the PoC.

Why It Matters

  • Low bar to exploit. Only authenticated, low-privileged access is required — no admin rights and no separate privilege escalation. A single mailbox account is enough.
  • A working exploit is now public. HawkTrace’s PoC automates the whole flow (stand up a malicious server, authenticate, request a target file), so attackers no longer need to develop it themselves.
  • Reads secrets, not just noise. Arbitrary file read on an Exchange host means config files, connection strings, service credentials, and other sensitive data are exposed — useful fuel for deeper compromise.
  • Exchange is a high-value target. On-prem Exchange sits at the center of enterprise mail and identity, and internet-facing OWA/EWS endpoints are routinely reachable, making them a perennial favorite for attackers.

Am I Affected?

You are likely affected if all of the following are true:

  • You run on-premises Microsoft Exchange Server — Exchange Server 2019 or Exchange Server Subscription Edition — rather than Exchange Online / Microsoft 365.
  • The server has not received Microsoft’s June 9, 2026 security update (or a later cumulative/security update).
  • EWS and document-preview functionality are reachable by mailbox users, which is the default for most deployments with users who can authenticate.

Exchange Online (Microsoft 365) is not affected. If you are unsure of your build, check the installed cumulative/security update level in the Exchange admin tooling and compare it against Microsoft’s June 2026 advisory for CVE-2026-45504.

What to Do About It: Step-by-Step

Step 1: Patch first — apply the June 2026 (or later) security update

This is the fix. Install the current Exchange security update for your version, for example the June 9, 2026 update (KB5094139 for Exchange Server Subscription Edition) or the equivalent for Exchange Server 2019, and any later cumulative update.

Step 2: Confirm your build after patching

In the Exchange Management Shell:

Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo }

Verify the version corresponds to the June 2026 security update or newer per Microsoft’s advisory.

Step 3: Restrict outbound connections from Exchange

The exploit depends on Exchange reaching an attacker-controlled server. At the network/firewall layer, block or tightly scope outbound HTTP/HTTPS from Exchange servers so they can only reach known, required destinations.

Step 4: Limit exposure of EWS where you can

If your organization does not need EWS reachable from the internet, restrict it via client-access rules or reverse-proxy/WAF policy so only trusted networks and clients can invoke it.

Step 5: Hunt for exploitation attempts

Review IIS and EWS logs for anomalous reference-attachment activity and for outbound requests to unexpected external hosts, and monitor for SSRF-style patterns (unusual ProviderEndpointUrl/WOPI callbacks). Investigate any outbound Exchange request to an unfamiliar endpoint.

Step 6: Rotate anything a file read could have exposed

If you find evidence of exploitation, treat on-host secrets (service account credentials, connection strings, certificates/keys reachable on disk) as compromised and rotate them.

Step 7: Keep Exchange on a supported, patched cadence

On-prem Exchange is a recurring target; apply security updates promptly and keep to a supported version.

Quick-Win Checklist

  • Confirmed whether any on-prem Exchange 2019 / Subscription Edition servers are in scope.
  • Applied the June 2026 (or later) Exchange security update.
  • Verified the patched build with Get-ExchangeServer / ExSetup version.
  • Restricted outbound HTTP/HTTPS from Exchange servers to known destinations.
  • Limited internet exposure of EWS to trusted clients where feasible.
  • Reviewed IIS/EWS logs for rogue reference attachments and outbound SSRF patterns.
  • Rotated any on-host secrets if exploitation is suspected.

Sources