How do you patch or mitigate CVE-2022-41040 (Microsoft Exchange Server Server-Side Request Forgery)?

CISA’s required action for CVE-2022-41040 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Exchange Server in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What to do first when CVE-2022-41040 is in your environment

Start by confirming where Microsoft Exchange Server is actually deployed, including older or forgotten systems, internet-facing instances, and any environment where Exchange is still reachable through reverse proxies or edge controls. The right response is not abstract prioritisation, it is asset identification, version confirmation, and an immediate decision on whether you can apply the vendor update or mitigation on each server.

Because this is a server-side request forgery issue, the most important practical question is whether the vulnerable Exchange instance can still be reached from outside your trusted boundary. If patching cannot happen immediately, removing internet exposure or taking the product out of service is the safer fallback than leaving the flaw reachable while waiting for a maintenance window.

For broader remediation discipline, the Vulnerability Management Guide is the right place to anchor asset scope, prioritisation, exception handling, and verification after remediation.

How to reduce exploitation risk while the fix is pending

The practical mitigation path is to narrow the attack surface around Exchange before you assume the patch alone will solve the problem. That means controlling exposure, limiting who can reach the service, and checking whether any compensating control actually blocks the request path that SSRF abuses. If the application remains reachable from the public internet, you should treat the exposure as active until the server is patched or isolated.

Do not rely on “we have a firewall” as proof of safety. In SSRF cases, the flaw often matters because the application itself can be induced to make unexpected server-side requests, including requests that reach internal resources or metadata endpoints. Good mitigation therefore combines vendor remediation with exposure reduction and careful review of outbound request paths and allowlists.

The SSRF Prevention Guide is useful here because it covers the same control pattern, URL validation, outbound filtering, and metadata-service abuse.

For a concrete example of why SSRF should never be treated as a cosmetic bug, the Capital One breach 2019 shows how SSRF can become a credential-exposure path when server-side requests reach sensitive internal services.

What to check after patching Exchange Server

After the update or documented mitigation is in place, validate that the vulnerable service is no longer reachable in the way the exploit required. Then review logs for abnormal request patterns, suspicious internal fetches, unexpected proxy traffic, and any signs that the server was used as a pivot point before the fix landed. The value of the patch drops sharply if compromise already occurred and the environment is left unexamined.

If you find evidence that attackers reached internal resources through the vulnerable path, move quickly to containment and credential review for anything the server could have accessed. In Exchange incidents, the operational concern is often not just that the server was exploited, but that it may have been used to reach other internal systems or harvest information that enables follow-on activity.

The CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm the required action and to verify that this flaw is treated as actively exploited.

For vendor-level version and mitigation details, use the Microsoft advisory and CISA KEV entry rather than relying on secondary summaries alone.

Risk and Threat Considerations

CVE-2022-41040 matters because SSRF can turn a trusted server into an attacker-controlled request proxy. On an Exchange Server, that creates a route to internal-only services and can expose follow-on authentication material, internal metadata, or adjacent systems if the server is allowed to reach them.

Failure mechanism: The flaw is exploitable when the server accepts attacker-influenced requests and then makes outbound requests to destinations the attacker should not be able to reach directly, especially where network controls do not constrain that behaviour.

Impact: Successful exploitation can lead to internal reconnaissance, access to sensitive endpoints, and a much larger blast radius than the original internet-facing service suggests, which is why removal of exposure is a valid emergency measure when patching is delayed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Exchange SSRF remediation depends on timely vulnerability identification and patching.
Recommendation — Prioritise exposed Exchange systems for rapid remediation and verify closure after patching.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer centers on finding affected assets and validating remediation across the estate.
	SI-2 — Flaw Remediation	The question asks how to patch or mitigate a known exploited software flaw.
Recommendation — Scan for Exchange exposure, track remediation status, and confirm vulnerable instances are removed or updated. Apply the vendor fix or approved mitigation and document any exception until remediation is complete.
OWASP API Security Top 10	API7 — Server Side Request Forgery	The vulnerability type is SSRF, so the API SSRF control directly matches the mechanism.
Recommendation — Validate outbound request handling and block attacker-controlled server-side fetches.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Exchange is internet-facing in the scenario and the flaw is used to exploit the application externally.
	T1189 — Drive-by Compromise	SSRF exploitation can be delivered through crafted web requests to the exposed service.
Recommendation — Hunt for exploitation of the public-facing Exchange service and correlate suspicious inbound requests. Inspect web access paths and block malicious request patterns that trigger server-side fetches.

Practitioner Guidance

What to verify: Confirm every Exchange instance, every exposure path, and every exception that could leave the server reachable while you are still deciding on remediation. A patch is only meaningful if the vulnerable path is actually closed and the server is not silently left exposed through an alternate route.

Decision rule: If you can apply the vendor update or documented mitigation immediately, do that first; if not, remove internet exposure or take the service out of use until you can. For this class of issue, temporary isolation is often the safer operational choice than accepting a live exploitable edge service.

What to measure: Look for evidence of exploit attempts and post-exploitation activity, not just successful patch completion. Log review should focus on unusual request chains, unexpected internal destinations, and any sign that the server behaved as a pivot rather than a mail platform.

Practitioner takeaway: With Exchange SSRF flaws, the real priority is to close the reachable attack path first, then prove there was no earlier compromise, because patching alone does not undo abuse that already happened.