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

Yes. CISA added CVE-2021-26855 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.

What this exploitation status means for Exchange defenders

CISA’s KEV listing is the practical signal that matters most here: it means defenders should treat the issue as confirmed active exploitation, not just a theoretical product flaw. For Microsoft Exchange Server, that shifts the response from normal patch planning to immediate exposure verification, emergency remediation, and compromise assessment for any server that was internet-facing or reachable from higher-trust segments.

The first question is not whether the vulnerability exists in the abstract, but whether any instance is reachable in your environment and whether the affected service path is still exposed. For Exchange, that usually means checking externally accessible web services, reverse proxy paths, and any legacy access route that still terminates on the server. If the product is present, the condition is actionable until proven otherwise.

Because CISA lists the flaw as known to be used in ransomware campaigns, defenders should assume that exploitation may be opportunistic rather than targeted only at high-value organisations. That makes detection and blast-radius reduction as important as patching. For a practical remediation path, the Vulnerability Management Guide is the right starting point for prioritisation, exception handling, and remediation tracking.

How to reduce exposure before and during remediation

When a patch or vendor fix cannot be applied immediately, the goal is to narrow the attack surface fast enough that the known exploit path becomes difficult to reach. That typically means removing internet exposure where possible, tightening allowlists, isolating administrative access, and monitoring the Exchange host and adjacent identity stores for suspicious sign-ins, new mailbox rules, unexpected web requests, and unusual process creation.

Temporary mitigation should be treated as an exception, not a substitute for repair. If the server must stay online, segment it from sensitive internal systems, limit who can reach its management interfaces, and preserve logs before making major changes. The practical lesson from Zero-Day and Exploited Vulnerabilities Guide is that urgent triage, containment, and post-change verification matter just as much as the patch itself.

In Exchange incidents, credential and session exposure can become a secondary problem even when the original flaw is an application RCE. If you find signs of execution on the host, review service accounts, administrator sessions, and any credentials the server may have accessed or cached. When the environment includes adjacent email controls, the Email Security Guide is useful for understanding how mailbox abuse, forwarding rules, and message remediation fit into the containment sequence.

What to check after suspected compromise

If exploitation may already have occurred, focus on evidence of execution, persistence, and post-exploitation activity rather than only on the patch status. On Exchange, that means reviewing web logs, Windows event logs, suspicious scheduled tasks or services, newly created accounts, mailbox delegation changes, and outbound connections that do not fit normal mail flow. A clean patch does not prove a clean server if attacker activity happened earlier.

Also validate whether the system touched other trust anchors in the environment, especially directory services, mail transport settings, and any automated admin tooling tied to the server. Attackers commonly use initial server compromise to move into identity infrastructure, harvest secrets, or stage further access. The safest assumption is that any machine that ran the vulnerable service and was reachable during the exploitation window deserves a compromise assessment.

If you need a broader incident lens for what attackers often do after server compromise, The State of NHI & AI Agent Breach Report 2026 is helpful for understanding how stolen credentials, tokens, and delegated access commonly extend an intrusion beyond the first foothold.

Risk and Threat Considerations

The main risk is not just remote code execution, but what that execution enables next: mailbox access, credential theft, internal pivoting, and ransomware staging on a system that often has broad trust and visibility. Exchange servers are attractive because they sit close to identity, email, and directory infrastructure, so a single compromise can create disproportionate downstream exposure.

Failure mechanism: An attacker reaches the vulnerable Exchange interface, executes code on the server, and then uses that foothold to enumerate accounts, harvest secrets, alter mail flow, or move laterally into more valuable systems.

Impact: The organisation can face mailbox compromise, credential replay, privilege escalation, service disruption, data theft, and ransomware deployment, often before the original vulnerability is even fully remediated.

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed Exchange exploitation requires prioritised scanning and remediation.
Recommendation — Prioritise and remediate exposed Exchange systems using continuous vulnerability management.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This is an actively exploited vulnerability, so exposure verification and scanning are central.
	IR-4 — Incident Handling	Suspected exploitation requires containment, evidence preservation, and compromise assessment.
Recommendation — Scan for exposed Exchange instances and confirm remediation after the fix is applied. Trigger incident handling and preserve evidence when Exchange exploitation is suspected.
OWASP ASVS	V16 — Security Logging and Error Handling	Post-exploitation review depends on trustworthy logs and alerting around server activity.
Recommendation — Retain and review security logs to reconstruct Exchange exploitation and follow-on activity.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Exchange exploitation commonly begins through a public-facing service path.
Recommendation — Map Exchange exposure to public-facing application exploitation and hunt accordingly.

Practitioner Guidance

What to prioritise: Verify whether any Exchange instance is still exposed, then treat every exposed or recently exposed server as a potential compromise candidate. Patch status alone is not enough if the host was reachable during the exploitation window.

What to verify: Confirm log retention, web request history, account changes, scheduled tasks, and outbound traffic for the period before remediation. If those records are missing, raise the incident severity because you have lost the evidence needed to bound the event.

Decision rule: If the server served internet traffic or was reachable from untrusted networks, perform containment and compromise assessment first, then recovery. If it was never reachable and you can prove that, remediation can be narrower.

Practitioner takeaway: For KEV-listed Exchange flaws, the right question is not whether a patch exists, but whether the server was exposed long enough for exploitation to matter and whether you still trust the identities and sessions that passed through it.