Is CVE-2022-41080 (Microsoft Exchange Server Privilege Escalation) being exploited in the wild?

Yes. CISA added CVE-2022-41080 to its Known Exploited Vulnerabilities catalogue on 10 January 2023, 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 contains an unspecified vulnerability that allows for privilege escalation. Any organisation running the affected product should treat remediation as urgent.

How to confirm whether CVE-2022-41080 is actively exploited

The practical test is not whether the CVE is listed somewhere, but whether the affected Exchange Server instance is exposed, reachable, and still within the vulnerable operational footprint. For this question, CISA’s KEV listing is the strongest public signal that exploitation has been observed, and the remediation question should start from that assumption rather than from theoretical risk alone.

Use your asset inventory to identify every Exchange Server deployment, including hybrid environments, test systems, and any legacy instance that may have been forgotten. Then verify whether the environment matches the vendor’s advisory and whether compensating controls, such as filtering or reduced exposure, are actually in place rather than just documented.

For authoritative tracking, compare your internal exposure view with the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database, then use the CVE Program record to align internal tracking and reporting.

Why privilege escalation in Exchange becomes urgent so quickly

A privilege-escalation flaw in a mail server is rarely just a local issue. In Exchange, elevated access can quickly expand into mailbox access, message interception, internal reconnaissance, and downstream trust abuse, especially where the server is integrated with directory services and administrative workflows. That is why active exploitation matters more than the vulnerability label itself.

When an exploit is already in the wild, attackers do not need to invent a path, they only need a reachable target and enough time before remediation lands. A mail platform is especially sensitive because it often sits at the intersection of user identity, internal communications, and reset or recovery workflows, which gives an intruder multiple ways to turn one foothold into broader access.

If you need a threat-model reference for how privilege escalation fits into real intrusion chains, the MITRE ATT&CK Enterprise Matrix is useful for mapping privilege escalation, credential access, and lateral movement after initial exploitation.

What to do if patching or mitigation is delayed

If remediation cannot happen immediately, reduce exposure first. The most useful containment steps are to limit external reachability, verify that only necessary management paths remain open, and watch for signs that the server has already been used as an entry point. For a mail platform, delayed action is not a neutral state, because exploitation can be automated once public knowledge exists.

Also treat authentication material and administrative sessions as potentially exposed if the server has been reachable during the exploitation window. If the instance handled privileged mail flow, connector configuration, or administrative access, review adjacent accounts and sessions for suspicious use rather than assuming the flaw only affected the server process itself.

Where you need a triage model for urgency and prioritisation, the FIRST EPSS service helps estimate exploitation likelihood, while the Zero-Day and Exploited Vulnerabilities Guide gives a practical response pattern for confirmed exploitation cases.

Risk and Threat Considerations

Once a vulnerability is in CISA’s KEV catalogue, the main question becomes blast radius, not abstract severity. For Exchange, privilege escalation can be the bridge from ordinary server access to email compromise, persistence, and further internal abuse, especially if the attacker can use the server to pivot into administrative or identity-adjacent systems.

Failure mechanism: An attacker abuses the Exchange flaw to raise privileges on a reachable system, then uses that elevated position to access mail data, tokens, or administrative paths that were not intended to be available from the original foothold.

Impact: The result can include mailbox compromise, internal message visibility, lateral movement, and faster follow-on exploitation, with ransomware activity becoming more plausible once the attacker has a trusted internal presence.

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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	CVE-2022-41080 is a privilege-escalation issue used in intrusion chains.
	T1021 — Remote Services	Exchange exploitation often precedes remote administrative access and lateral movement.
Recommendation — Map exploitation paths to T1068 and hunt for privilege gain after initial access. Review remote access paths and segment admin services from Internet-facing systems.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about active exploitation and urgent remediation of a known vulnerable product.
Recommendation — Prioritise KEV-listed vulnerabilities and verify remediation against asset inventory.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	A KEV-listed Exchange flaw requires validated exposure tracking and remediation oversight.
	SI-2 — Flaw Remediation	Confirmed exploitation makes prompt flaw remediation the central control response.
Recommendation — Scan for vulnerable Exchange instances and track remediation to closure. Apply urgent flaw remediation for affected Exchange systems and verify completion.

Practitioner Guidance

What to prioritise: Treat any exposed Exchange Server as a high-priority remediation item until you have verified patch state, exposure, and compromise status. If the server is Internet-facing or supports privileged workflows, move it to the front of the queue even if no alert has fired.

What to verify: Confirm whether the server has shown suspicious authentication events, unusual administrative activity, or unexpected mailbox access during the exposure window. If the server was reachable while unpatched, check adjacent identity and session activity rather than limiting the review to the host alone.

Practitioner takeaway: For KEV-listed Exchange flaws, “no incident detected” is not a safe default, because confirmed exploitation means you should assume exposure until patching, containment, and compromise checks prove otherwise.