A newly disclosed server-side request forgery (SSRF) vulnerability in Microsoft Exchange Server 2019, tracked as CVE-2026-45504, allows any authenticated, low-privileged user to read arbitrary files from the server without additional authorization.
Security researcher Batuhan Er of the HawkTrace team published a technical breakdown along with a working proof of concept (PoC), assigning the flaw a CVSS score of 8.8.
The vulnerability, an SSRF-driven file-read issue, affects on-premises deployments of Exchange, Microsoft’s server-based messaging platform for managing email, calendars, contacts, and tasks via clients such as Outlook.
Microsoft Exchange SSRF Flaw
The root cause lies in Exchange’s OneDrive and WOPI (Web Application Open Platform Interface) integration, specifically within OneDriveProUtilities.GetWacUrl and its supporting helper functions, TryTwice and GetTokenRequestWebResponse.
These methods handle token retrieval for opening Office documents via SharePoint’s WOPI API, but fail to validate the scheme of the WebApplicationUrl returned by a WOPI provider before using it to build a follow-up request.
The TryTwice function passes a URL directly into WebRequest.CreateHttp(url), meaning any address supplied by an attacker-controlled endpoint gets requested without restriction, while GetTokenRequestWebResponse transforms that URL into a SharePoint REST API call.
An attacker can exploit this chain by creating an EWS ReferenceAttachment with a ProviderEndpointUrl pointing to an attacker-controlled server. When a victim opens the attachment preview, Exchange sends a request to that server.
The attacker’s server then responds with a crafted WebApplicationUrl, such as file:///C:/windows/win.ini#. Because Exchange appends OAuth parameters (access_token, access_token_ttl, and sc) directly to this URL, a plain file path would normally break the syntax.
The # fragment character solves this for the attacker, since everything after it is treated as a URI fragment and discarded by the parser, leaving Exchange to fetch the file via FileWebRequest and return its contents.
HawkTrace stated that the exploitation path traces cleanly through Exchange’s OWA server core, beginning with GetWacAttachmentInfo.ExecuteAsync, which initiates attachment processing, before moving to the reference attachment logic.
From there, OneDriveProUtilities.GetWacUrl (both internal and wrapper forms) constructs the vulnerable request, while GetTokenRequestWebResponse and TryTwice execute the SSRF call and parse the malicious XML response for the WebApplicationUrl, AccessToken, and AccessTokenTtl fields.
Because this entire chain is reachable through standard EWS calls used to create an attachment, no elevated privileges beyond a valid mailbox account are required to trigger it.
Mitigation
CVE-2026-45504 allows attackers to exfiltrate sensitive local files, including configuration files, credentials, or other data stored on the Exchange server, solely via crafted attachment metadata and a malicious WOPI response.
Microsoft’s permanent fix requires strict scheme validation on WebApplicationUrl values returned by WOPI providers, explicitly blocking file:// and other non-HTTP(S) schemes before they reach WebClient.OpenRead().
Until patches are applied, administrators should:
- Audit WOPI and OneDrive integration settings on all on-premises Exchange servers
- Monitor logs for anomalous outbound requests from Exchange to unfamiliar external endpoints
- Restrict or disable EWS
ReferenceAttachmentfunctionality where feasible - Apply Microsoft’s official patch immediately upon release
No Comment! Be the first one.