Is CVE-2022-41040 (Microsoft Exchange Server Server-Side Request Forgery) being exploited in the wild?

Yes. CISA added CVE-2022-41040 to its Known Exploited Vulnerabilities catalogue on 30 September 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft Exchange Server allows for server-side request forgery. Any organisation running the affected product should treat remediation as urgent.

What makes this CVE operationally urgent?

CVE-2022-41040 matters because it is not a theoretical flaw. The direct answer already confirms active exploitation and ransomware use, so the practical question is whether Exchange is present, exposed, and still reachable from untrusted networks or untrusted internal paths. For Exchange, SSRF is especially dangerous because it can become a stepping stone to deeper trust abuse rather than a single-request issue.

An organisation should treat this as an exposure-management problem first and a patching problem second. The key issue is whether an attacker can reach the vulnerable Exchange surface and use it to probe internal resources, metadata services, or adjacent management functions. If that path exists, the risk is broader than the initial web request and may include follow-on credential or session abuse.

For current triage and remediation sequencing, the most useful reference is the CISA Known Exploited Vulnerabilities Catalog, because the catalogue status is what moves this from general vulnerability awareness into urgent operational response.

How SSRF on Exchange becomes a breach path

Server-side request forgery is dangerous in mail and gateway products because the server can often reach destinations that the attacker cannot. On Exchange, that can turn a request-processing weakness into internal request execution, including access to services that were never intended to be externally reachable. That is why a flaw framed as SSRF often has impact well beyond simple URL fetching.

The practical concern is not only exploitation of the original request, but what the server can be induced to talk to next. In a mature environment, SSRF controls should block outbound reachability to sensitive endpoints and reduce implicit trust between application tiers. In a weak environment, the same flaw can expose internal control planes, metadata endpoints, or privileged administrative interfaces.

This is the same pattern defenders should recognise in the SSRF Prevention Guide, where the central defensive issue is constraining what the server can reach after the initial request is accepted.

For a broader application-security view of the attack path, the Web Application Attacks Guide helps place SSRF alongside other request-driven abuse patterns that exploit server trust rather than user mistakes.

What should teams do if patching is delayed?

If remediation cannot happen immediately, defenders should assume that the vulnerable service may already be probed and that later compromise checks will matter as much as patching. The most important interim step is to reduce the reachable attack surface, especially internet exposure and unnecessary internal egress, while monitoring for suspicious Exchange-originated requests that do not match normal mail-flow or administrative behaviour.

Teams should also verify whether Exchange has been used as a pivot into the rest of the environment. That means reviewing authentication anomalies, unusual backend requests, unexpected child processes, and signs that internal services were contacted from the Exchange host in patterns not used by normal operations. Where the flaw is paired with any stolen credential or token exposure, treat that as a separate containment problem, not just a vulnerability ticket.

A useful precedent for the trust-boundary problem is Capital One breach 2019, which shows how SSRF can turn into access to privileged infrastructure data when the server is allowed to reach sensitive internal services.

Zero-Day and Exploited Vulnerabilities Guide is also relevant here because the response posture for known exploited flaws should prioritise emergency containment, rapid verification, and post-change hunting rather than waiting for routine patch windows.

Risk and Threat Considerations

The risk is not just that Exchange is exploitable, it is that Exchange is often trusted to sit close to identity, mail, and internal application boundaries. Once SSRF is available on that server, an attacker may be able to use it as a launch point for internal reconnaissance, metadata access, or chained exploitation. That makes the issue particularly dangerous in environments where Exchange still has broad network reach.

Failure mechanism: The server accepts attacker-controlled requests and relays them toward internal or privileged destinations that were assumed to be trusted, letting the attacker abuse Exchange as an internal proxy.

Impact: The likely consequence is deeper compromise than the original HTTP request suggests, including internal enumeration, lateral movement, credential exposure, and ransomware-enabling access paths.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Exchange SSRF exploitation requires identifying exposed assets and known weaknesses.
	PR.AA-01 — Identity Management, Authentication and Access Control	SSRF on Exchange can expose internal trust paths and privileged access routes.
	PR.PS-01 — Configuration Management	Hardening network reachability and service configuration reduces SSRF abuse potential.
Recommendation — Inventory exposed Exchange assets and track them against known exploited vulnerabilities. Restrict Exchange access paths and remove unnecessary trust to internal services. Harden Exchange and its egress paths to block unintended internal requests.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A known exploited CVE requires timely remediation of the vulnerable software flaw.
	SC-7 — Boundary Protection	SSRF abuse depends on weak network boundaries and excessive internal reachability.
	AU-6 — Audit Review, Analysis, and Reporting	Post-exploitation hunting depends on reviewing logs for unusual Exchange-originated activity.
Recommendation — Remediate the Exchange flaw on an emergency timeline and verify completion. Limit outbound and internal request paths from Exchange to approved destinations. Review logs for anomalous Exchange requests and follow-on access patterns.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CISA KEV status makes prioritised vulnerability handling central to this CVE.
	CIS-12 — Network Infrastructure Management	Network control is critical to reducing SSRF reach and lateral request abuse.
Recommendation — Prioritise and verify remediation for KEV-listed vulnerabilities like this one. Constrain network reachability from Exchange to only required services.
OWASP ASVS	V4 — API and Web Service	SSRF is a web-service abuse pattern that must be tested and constrained at the request layer.
Recommendation — Validate web-service request handling and block server-side request forgery paths.

Practitioner Guidance

What to verify: Confirm whether the Exchange instance is internet-facing, whether it can reach sensitive internal destinations, and whether outbound filtering would stop the specific SSRF path if exploitation were attempted again. Do not rely on patch state alone if the host has already been used as a pivot.

Decision rule: If the server is reachable from untrusted networks or has broad internal egress, treat the situation as a containment and compromise-assessment exercise, not just a software update task. If there is any sign of suspicious backend activity, investigate before returning the service to normal trust assumptions.

Practitioner takeaway: With a known exploited SSRF on Exchange, the right question is not only whether the CVE is patched, but whether the server ever had enough reach to become an internal attack bridge.