CVE-2021-26855, known as ProxyLogon, is a server-side request forgery (SSRF) vulnerability in Microsoft Exchange Server rated CVSS v3.1 9.8 (Critical). It let a remote, unauthenticated attacker send crafted HTTP requests that Exchange would forward internally while authenticating as the server itself. On its own that is a serious auth bypass; chained with follow-on Exchange flaws it became a full pre-authentication path to remote code execution against on-premises mail servers exposed to the internet.
Timeline and impact
Microsoft released out-of-band security updates on March 2, 2021, attributing active exploitation to a state-sponsored group it tracked as HAFNIUM. ProxyLogon was not exploited alone: it was the entry point in a chain that combined CVE-2021-26855 (SSRF), CVE-2021-26857 (an insecure deserialization in the Unified Messaging service), CVE-2021-26858, and CVE-2021-27065 (post-authentication arbitrary file writes). Together they let attackers authenticate as the Exchange machine account, write a web shell to a known virtual directory, and run commands as the highly privileged Exchange process.
What made the incident historic was the speed and scale of follow-on exploitation. Once details were public, multiple threat actors mass-scanned the internet for unpatched Exchange servers and dropped web shells on tens of thousands of them within days — far faster than most organizations could patch. CISA issued an emergency directive ordering federal agencies to patch or disconnect. The lasting lesson is that an internet-facing application which authenticates internal requests on the client's behalf is a magnet for SSRF, and that the gap between an out-of-band patch and mass weaponization is now measured in hours. Note that Exchange Online (Microsoft 365) was not affected — this was strictly an on-premises Exchange Server problem.
Technical root cause
Exchange's Client Access frontend proxies requests to backend services. ProxyLogon abused how the frontend handled a specific cookie and Autodiscover endpoint: an attacker could supply a backend target and have the frontend forward the request to it while carrying the server's own credentials. In effect, the attacker chose where Exchange sent an authenticated internal request.
A sanitized illustration of the request shape — not a working exploit — looks like this:
POST /owa/auth/x.js HTTP/1.1
Host: exchange.victim.example
Cookie: X-BEResource=<internal-backend-target>~<version>
Content-Type: text/xml
<!-- the frontend forwards this to the chosen backend,
authenticated as the Exchange server itself -->
The core defect is trust: the frontend accepted an attacker-influenced destination and treated the resulting internal call as privileged. Because the request never required valid user credentials, the SSRF gave attackers the identity they needed to reach endpoints that assumed callers were already inside the trust boundary. From there, the deserialization and file-write flaws in the chain turned "I can make the server talk to itself" into "I can write a .aspx web shell and execute code."
The fix corrected how the frontend validates and constrains where proxied requests may go, so an external caller can no longer coerce the server into forwarding authenticated requests to arbitrary backends.
How to detect if you are affected
- Identify on-premises Exchange. Vulnerable products are Exchange Server 2013, 2016, and 2019 running the affected cumulative updates. Confirm the exact build number on each server; ProxyLogon is a per-build fix.
- Hunt for the chain's artifacts. Microsoft and CISA published indicators: unexpected
.aspxfiles in Exchange virtual directories (OWA/ECPauthpaths), suspicious child processes spawned by the Exchange worker process, and anomalous ECP activity in the IIS logs. - Search IIS logs for POST requests to
/owa/auth/,/ecp/, and Autodiscover endpoints carrying unusual cookies, especially any referencing backend resources.
Web shells often outlive the patch. Where an Exchange-style web application runs inside a container image, Safeguard's container security scanning inventories the shipped application layers so a stale or backdoored build does not slip through unnoticed.
Remediation and patched versions
- Apply the March 2021 (and later) security updates for your exact Exchange Server 2013/2016/2019 build. Microsoft shipped these out-of-band precisely because in-the-wild exploitation was already underway; there is no configuration workaround that substitutes for the patch.
- Assume compromise on any server that was exposed and unpatched. Patching removes the vulnerability but not an existing web shell. Run Microsoft's published detection and cleanup guidance, hunt for dropped shells and persistence, and rotate credentials that the machine account could reach.
- Reduce exposure. Restrict internet access to OWA/ECP where feasible, front Exchange with authenticated reverse proxies, and monitor the endpoints named above.
- Verify the fix took by re-checking build numbers across every node; partially patched clusters were a recurring reason organizations were re-exploited.
How Safeguard surfaces and helps you respond to ProxyLogon
ProxyLogon is a product vulnerability rather than a dependency in a manifest, but the failure mode that hurt organizations was the same one Safeguard is built to eliminate: nobody had a fast, authoritative inventory of what they ran and where, so nobody could patch inside the exploitation window. Safeguard's approach — continuous inventory, findings enriched with CISA KEV and EPSS exploit-probability signals, and prioritization that pushes actively weaponized, internet-facing flaws to the top — is exactly the discipline that shortens response time when an out-of-band Exchange advisory lands. Where your Exchange-adjacent or web-facing workloads are containerized, software composition analysis and container scanning resolve the components and their versions so a vulnerable build cannot hide.
For the components you actually build and ship, automated fix pull requests raise version bumps directly against your manifests and image definitions, and Griffin AI explains blast radius and the "patching alone is not enough — hunt for the web shell" nuance that ProxyLogon made famous. If you are weighing how KEV-driven prioritization compares to score-only scanners, our side-by-side comparison walks through the difference on actively exploited findings.
An SSRF became a global incident because the internet outran the patch cycle. The defense is boring and effective: know what you run, and patch the exploited things first.
Get started at app.safeguard.sh/register, or read the documentation at docs.safeguard.sh.