Is CVE-2021-26857 (Microsoft Exchange Server Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2021-26857 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, 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 remote code execution. Any organisation running the affected product should treat remediation as urgent.

Why this Exchange exploit should be treated as active, not theoretical

CVE-2021-26857 is the kind of issue you treat as live exposure, not a backlog item. CISA’s KEV listing means there is reliable evidence of exploitation in the wild, and the ransomware tag means the flaw has been folded into real intrusion chains rather than remaining a proof-of-concept concern. For defenders, that changes the question from “is it exploitable?” to “is any reachable instance still exposed?”

For organisations still running Microsoft Exchange Server, the practical risk is not just initial compromise but rapid conversion into mailbox access, internal reconnaissance, and follow-on abuse of trusted email infrastructure. A public-facing mail platform is often both an entry point and a credential-rich environment, so exploitation can immediately widen the blast radius.

What the KEV listing tells you about operational urgency

CISA’s catalogue is a prioritisation signal, not a patch bulletin, but it is one of the strongest indicators that remediation should move ahead of routine change windows. The right operational response is to confirm whether the vulnerable Exchange surface exists anywhere in production, staging, disaster recovery, or externally exposed lab environments, then treat each reachable instance as an urgent security issue.

If the server is internet-facing, behind published mail flow, or reachable through legacy administrative paths, exposure is materially higher. If the platform is used for core messaging, identity-linked workflows, or other business-critical mail functions, delay becomes a resilience decision as much as a security one. The vendor advisory and the CISA KEV entry should be your source of record for version-specific action.

What to check before and after remediation

Before you patch or mitigate, verify whether the server was externally reachable during the exposure window and whether any indicators of post-exploitation activity exist. For Exchange, that means looking for unusual administrative actions, unexpected authentication events, suspicious mailbox access, new forwarding rules, dropped web shells, and signs that attackers used the server as a foothold for broader network access.

After remediation, the priority is not only to confirm the version state but to validate that the environment is no longer using the vulnerable path and that any associated accounts, sessions, and secrets that could have been touched are no longer trusted by default. Where compromise cannot be ruled out, assume the attacker may have captured credentials or used the server to pivot further.

Because mail systems often interconnect with many downstream services, any compromise check should extend beyond the Exchange host itself. Review whether service accounts, delegated mail access, connected applications, and adjacent administrative accounts need rotation or review based on what the server could have exposed.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited Exchange flaws require rapid asset scope and remediation prioritisation.
Recommendation — Prioritise and remediate KEV-listed Exchange exposures immediately.
NIST CSF 2.0	ID.RA-05 — Vulnerabilities are identified and recorded	This is a live vulnerability-exposure question requiring identification and tracking of affected assets.
Recommendation — Identify exposed Exchange assets and record the active exploitation risk.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Known exploited Exchange RCEs require validated scanning and exposure confirmation.
	SI-2 — Flaw Remediation	The issue is an actively exploited flaw that demands urgent remediation and verification.
Recommendation — Scan for vulnerable Exchange instances and verify exposure before closing the issue. Remediate the Exchange flaw urgently and verify the fix is actually applied.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Active exploitation makes technical-vulnerability handling and escalation directly relevant.
Recommendation — Escalate and track the Exchange vulnerability through formal vulnerability management.

Practitioner Guidance

What to prioritise: Treat any exposed Exchange instance as a high-priority remediation item, then pair patching with compromise assessment rather than assuming the fix alone is sufficient. If you cannot immediately remove exposure, reduce reachable surfaces and raise monitoring around authentication, mailbox manipulation, and admin activity.

What to verify: Confirm whether the system was internet-facing, whether it handled privileged mail workflows, and whether any suspicious post-authentication activity occurred around the date of exposure. If logs are incomplete, assume your confidence is lower and widen the investigation scope accordingly.

Practitioner takeaway: For KEV-listed Exchange flaws, urgency comes from the combination of active exploitation and the server’s central role in trust, messaging, and credential-adjacent workflows, so remediation and compromise review should move together.