ProxyNotShell, the colloquial name for the linked CVE-2022-41040 server-side request forgery and CVE-2022-41082 remote code execution vulnerabilities in Microsoft Exchange Server, hit in September 2022 and continued to bleed through the rest of that year. The story is less about the technical novelty of the exploit chain and more about how vendors and customers manage a CVE response when the initial mitigation guidance turns out to be inadequate. The pattern repeated several times in 2023 and 2024, and the operational lessons are still relevant for any team running on-premises Exchange in 2026.
This postmortem walks through the chain, the misleading mitigation guidance that defenders followed, the realistic exploitation footprint, and the structural lessons about patch triage when the vendor cannot or will not provide a complete fix immediately.
How did the exploit chain work?
The exploit chain required two distinct vulnerabilities combined. CVE-2022-41040 was a server-side request forgery in the Exchange autodiscover endpoint that allowed an authenticated user, any mailbox owner, to coerce the Exchange server into making internal HTTP requests. CVE-2022-41082 was a remote code execution flaw in Exchange's PowerShell remoting endpoint, reachable through the SSRF primitive. Combining the two gave an authenticated attacker code execution on the Exchange server with SYSTEM privileges. The authentication requirement was not a meaningful barrier, because any compromised mailbox credential, harvested through phishing or password reuse, was sufficient. The chain worked on Exchange Server 2013, 2016, and 2019 in their on-premises configurations. Microsoft Exchange Online was not affected, which highlighted again the divergence between on-prem and cloud Exchange security postures.
Why was the initial mitigation guidance wrong?
The initial Microsoft mitigation guidance, published before patches were available, recommended URL rewrite rules in IIS to block requests matching specific autodiscover patterns. Within 24 hours, multiple security researchers demonstrated trivial bypasses of these rules using URL encoding and pattern variations. Microsoft updated the guidance twice in the first week, and each iteration was bypassed by new variants. The underlying problem was that the URL pattern was a noisy signal for the actual attack, and exploits with semantically equivalent but textually different URIs flowed around the rewrite rules. Organizations that deployed the original guidance assumed they were protected and were not. CISA had to issue clarifying guidance, and the patch did not ship until November 8, 2022, nearly two months after initial disclosure. Many environments remained exposed throughout that window because the mitigation gave a false sense of completion.
What did exploitation look like in the wild?
Exploitation began before public disclosure. Vietnamese threat intelligence firm GTSC reported the vulnerability to ZDI in early August after observing active exploitation against Vietnamese government targets. The campaign appeared to be the work of a Chinese-linked group, later tracked under multiple labels including DEV-0866 and Tonto Team. After public disclosure in late September, exploitation broadened rapidly: ransomware operators including Play and BlackCat incorporated the chain into their initial access toolchains, and by November, ProxyNotShell was a common entry vector for ransomware against mid-market organizations. CISA reported confirmed exploitation against more than 250 organizations by year-end 2022, with the true number likely several times higher. Notable public incidents included intrusions at multiple US municipal governments and several Fortune 500 companies whose breach notifications referenced the CVEs.
What did the patching reality look like?
The patching reality reflected the structural problem of on-premises Exchange. Many environments ran Exchange versions that were already nearing or past end of life, including Exchange 2013, which exited extended support in April 2023. The Cumulative Update model meant that applying the security patch required first applying a CU, and many organizations had skipped CUs for years and faced multi-step upgrade paths. Vendor-managed Exchange deployments and managed service providers were a major bottleneck because patching required coordinated maintenance windows. By the time CISA called for federal agencies to complete patching, more than three months had passed since initial disclosure. Public scan data in mid-2023 still showed roughly 40% of internet-exposed Exchange servers running vulnerable versions, and the residual rate in 2026 hovers around 12% to 15% on the rapidly shrinking on-premises Exchange installation base.
What are the operational lessons?
The operational lessons sit at two levels. At the tactical level, mitigation guidance from vendors during an active exploitation window deserves heightened skepticism, particularly when the mitigation depends on pattern matching against attacker-controlled input. Validate proposed mitigations against known bypass techniques before declaring the exposure closed, and assume that initial guidance will be incomplete. At the strategic level, on-premises Exchange has been the source of so many catastrophic CVEs in the past five years, ProxyLogon, ProxyShell, ProxyNotShell, the AMSI bypass chain, and several others, that the prudent decision for most organizations is to migrate to Exchange Online or another cloud-hosted mail service. The on-prem product is on a slow path to retirement, and continuing to operate it accepts a vulnerability cadence that few teams can match with their patching capacity.
How Safeguard Helps
Safeguard's approach to high-profile patch triage events like ProxyNotShell combines inventory accuracy with exploitation intelligence. Our agent-collected inventory captures Exchange Server versions, cumulative update levels, and IIS configurations across hybrid environments, surfacing the exact patch state of each server. Griffin AI cross-references that inventory against CISA KEV and commercial exploitation feeds, surfacing exposed Exchange servers that match active exploitation patterns. Policy gates evaluate Exchange configurations against known vulnerability prerequisites, flagging servers that meet exploit conditions before patches are applied. TPRM scoring includes vendor and managed service provider response times on Exchange CVEs as an indicator of how they will handle the next incident. For organizations moving away from on-prem Exchange, our cloud security posture data includes migration readiness indicators across Exchange Online and competing platforms.