Microsoft Exchange EWS SSRF CVE-2026-45502: PoC Published and On-Premises Estates Fully Exposed

A public proof-of-concept exploit has been released for CVE-2026-45502, a server-side request forgery vulnerability in Microsoft Exchange Server's Exchange Web Services component. The flaw allows authenticated attackers to force Exchange servers to make outbound HTTP requests to arbitrary internal or external URLs, enabling reconnaissance of internal network infrastructure and access to protected services behind the Exchange server.

The vulnerability was disclosed by Microsoft in its June 2026 security update and carries a CVSS 3.1 score of 5.0, classified as medium severity. Independent analysis under CVSS 4.0 yields a lower score of 2.3, reflecting the blind nature of the SSRF and the credential requirement. The medium classification, however, substantially understates the practical risk for on-premises Exchange deployments, where a design flaw in how the SSRF protection is implemented means the security check does not apply at all.

Why On-Premises Deployments Are Fully Exposed

The vulnerability resides in the SynchronousDownloadData.DownloadDataFromUri() method within Microsoft.Exchange.Data.ApplicationLogic.dll. When an authenticated user submits an Exchange Web Services InstallApp SOAP request containing a ManifestUrl parameter, Exchange fetches the manifest from the supplied URL. A critical design flaw causes the SSRF protection to be entirely bypassed in on-premises deployments.

The intranet address check is gated on an isBposUser flag, a parameter that is true only for cloud-hosted Microsoft 365 tenants. Since all on-premises Exchange deployments set this flag to false, the SSRF validation condition short-circuits immediately and no internal address check occurs. The server proceeds to make an HTTP GET request to the attacker-controlled URL, appending a correlation ID parameter in the process.

In practice, an attacker with valid Exchange mailbox credentials can use this flaw to probe internal services behind the Exchange server, access cloud instance metadata endpoints such as the AWS instance metadata service at 169.254.169.254, interact with internal REST or management APIs, and map internal network topology through response timing analysis.

The proof-of-concept script published on 22 June 2026 confirmed this by starting a local HTTP listener and triggering a callback GET request from the Exchange server IP, confirming successful exploitation requiring only valid mailbox credentials and network access to port 443.

Affected Versions

The following on-premises Exchange Server versions are confirmed vulnerable:

• Microsoft Exchange Server 2016 Cumulative Update 23
• Microsoft Exchange Server 2019 Cumulative Update 14
• Microsoft Exchange Server 2019 Cumulative Update 15
• Microsoft Exchange Server SE RTM

Patch and Remediation

Microsoft addressed CVE-2026-45502 in the June 2026 security update under KB5094139. The patch replaces the single isBposUser-gated check with a two-tier defence using new feature flags, both enabled by default, that enforce a URL allowlist permitting only [https://officeclient.microsoft.com](https://officeclient.microsoft.com) and administrator-configured entries regardless of deployment type.

Fixed builds are 15.01.2507.069 for Exchange 2016 CU23, 15.02.1544.041 for Exchange 2019 CU14, 15.02.1748.046 for Exchange 2019 CU15, and 15.02.2562.043 for Exchange SE RTM.

GCC Context and Action Required

Microsoft Exchange Server remains one of the most widely deployed on-premises email platforms across GCC government entities, financial institutions, and enterprise environments. Many GCC organisations operate hybrid Exchange environments where on-premises servers coexist with Exchange Online, and the vulnerability specifically targets the on-premises component. A successful SSRF exploit against an Exchange server in a hybrid environment can expose internal network infrastructure, management APIs, and cloud metadata endpoints that sit behind the trust boundary established by the Exchange deployment.

For GCC enterprises operating under UAE NESA Information Assurance Standards or Saudi Arabia's NCA Essential Cybersecurity Controls, this vulnerability is directly relevant to email infrastructure security controls and patch management obligations. The public availability of a working proof-of-concept since 22 June means the window between patch release and active exploitation may already be closing.

Organisations should verify their current Exchange build versions against the fixed build numbers above and apply KB5094139 without delay. Security operations teams should also audit Exchange Web Services logs for anomalous InstallApp SOAP requests, which would indicate prior exploitation attempts.

The pattern of attackers probing internal services via SSRF is consistent with the lateral movement preparation documented in FortiBleed and other recent campaigns targeting GCC infrastructure, where initial access through a trusted enterprise platform was used to map the internal network before escalating to credential harvesting and lateral movement.