CVE-2022-41040 is a server-side request forgery vulnerability in Microsoft Exchange Server. CISA added it to the Known Exploited Vulnerabilities catalogue on 30 September 2022, which means attackers have used it in real attacks. Microsoft Exchange Server allows for server-side request forgery. Dubbed “ProxyNotShell,” this vulnerability is chainable with CVE-2022-41082 which allows for remote code execution.
What makes this vulnerability class dangerous in Exchange Server
Server-side request forgery in Microsoft Exchange Server is dangerous because the server can be induced to make requests on the attacker’s behalf, often reaching internal services, metadata endpoints, or trusted administrative paths that are not directly exposed to the internet. In a product that brokers mail, directory, and web access, that trust boundary matters.
This class of flaw is especially concerning when it sits inside a chainable exploit path. In the ProxyNotShell chain, SSRF is not just a standalone bug, it can become the first step that opens the door to deeper compromise when paired with a separate execution flaw.
How organisations assess exposure
Exposure review starts with a precise inventory of Exchange instances, their internet exposure, and whether they are reachable through reverse proxies, load balancers, or other publishing layers. Organisations should then compare what they run against vendor advisories and the CISA KEV catalogue, because KEV inclusion signals real-world abuse rather than theoretical risk.
For this class of issue, it is also important to verify whether adjacent services, trust relationships, and internal endpoints are reachable from the Exchange server’s network position. SSRF problems are often missed when teams look only at the application endpoint and not at what the server itself can access.
Practitioners often use vulnerability management processes to connect asset scope, exploitability, and remediation priority. NHI Mgmt Group’s Vulnerability Management Guide is useful here because it ties KEV awareness to prioritisation and verification.
Remediation and compensating controls
The first-line response is to apply the vendor-recommended fix path for the exact Exchange build in use. Until that can happen, organisations should reduce exposure by tightening internet-facing access, isolating the system from unnecessary outbound reach, and removing any trust paths that let the server reach sensitive internal services.
Compensating controls matter because SSRF weakness is often useful before a patch is available or while patching is staged across complex environments. Network segmentation, allowlisting, and restricted egress can limit what an exploited server can contact even if the bug is still present.
For a broader attack-path view, Web Application Attacks Guide covers SSRF among other web exploitation patterns, and Capital One breach 2019 shows why SSRF becomes severe when a server can reach privileged internal or metadata services.
Detection and post-compromise review
Detection should look for anomalous outbound requests generated by Exchange, especially requests to internal IP ranges, loopback targets, link-local addresses, or unusual administrative endpoints. Sudden changes in web request patterns, abnormal proxy activity, and unexplained access to internal services are all worth review.
After a suspected exploitation event, assume the attacker may have moved beyond the initial SSRF. Review logs, outbound connections, command execution traces, and any evidence of follow-on web shell placement or credential theft. If the SSRF was chained, the second-stage activity may be the real business impact.
For contextual examples of exploitation chains and attacker movement, The State of NHI & AI Agent Breach Report 2026 is useful as a breach-pattern reference, even though the control lesson here is broader than non-human identity alone.
Risk and Threat Considerations
Once an attacker can make Exchange Server issue requests on their behalf, they may be able to reach internal-only targets, harvest information, or pivot into adjacent systems that were never meant to be externally reachable. The danger increases when SSRF is paired with another flaw that turns that internal reach into code execution or credential access.
Failure mechanism: The server’s trusted network position becomes the attacker’s relay, allowing access to internal services, metadata, or privileged endpoints that the attacker could not directly query from outside.
Impact: Exposure can expand from a single web application flaw to broader compromise, including internal reconnaissance, credential abuse, and in chained cases, remote code execution and deeper environment takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventoried | Exchange exposure depends on knowing which servers exist and where they are reachable. |
| PR.PS-01 — Configuration Management | SSRF risk is reduced by hardened configuration, segmentation and constrained service reachability. | |
| DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Detecting SSRF requires monitoring unusual outbound requests and internal-target access patterns. | |
| Recommendation — Inventory every Exchange instance and its exposure path before prioritising remediation. Harden Exchange and restrict its reachable network paths to limit SSRF blast radius. Monitor Exchange egress and internal request patterns for anomalous server-initiated traffic. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Exchange SSRF response depends on monitoring for abnormal outbound and internal service access. |
| SC-7 — Boundary Protection | SSRF is a boundary-crossing issue, so network boundary controls materially affect exposure. | |
| Recommendation — Tune monitoring to flag anomalous Exchange-initiated requests and follow-on compromise indicators. Restrict Exchange egress and internal reachability with boundary controls and segmentation. | ||
| OWASP ASVS | V4 — API and Web Service | SSRF is a web-service request handling weakness that belongs in application security verification. |
| Recommendation — Verify server-side request handling to block attacker-controlled internal fetches. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Exchange SSRF is exploited through an externally reachable application entry point. |
| Recommendation — Map Exchange SSRF to public-facing application exploitation and hunt for initial access activity. | ||
Practitioner Guidance
Why practitioners should care: Treat Exchange SSRF as a boundary-breaking issue, not just a web bug. The operational question is not only whether the service is patched, but whether the server can reach anything sensitive if it is coerced into acting as a proxy.
What to watch for: Prioritise internet-facing Exchange, unexpected outbound requests, and any indication that the server can access internal services or metadata-style endpoints. That combination is what turns a contained flaw into an enterprise incident.
Practitioner takeaway: The safest posture is to reduce both exposure and reachability, because SSRF becomes materially worse when the compromised server still has broad internal network access.