How do you patch or mitigate CVE-2021-27065 (Microsoft Exchange Server Remote Code Execution)?

CISA’s required action for CVE-2021-27065 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 patching CVE-2021-27065 means in practice

Exchange Server exploitation is usually a lifecycle problem, not just a software update problem. The first task is confirming every reachable Exchange instance, including forgotten or internet-exposed servers, because a partial inventory leaves a live attack path even if some hosts are patched. For the authoritative advisory trail, use the CISA Known Exploited Vulnerabilities Catalog and the vendor’s own guidance for the exact update path.

Because the flaw was actively exploited, patching should be treated as both remediation and exposure reduction. If the vendor update cannot be applied immediately, the safer fallback is to remove the server from direct internet access or retire it from service rather than leave a known exploitable edge system in place. That is especially important for legacy messaging systems that are hard to replace but easy to forget.

Why exposed Exchange servers are still high-risk after the patch

The practical risk is not only initial compromise, but also the chance that an attacker already used the bug before you remediated it. Once an Exchange server is reachable from the internet, exploitation can happen quickly, and the server often sits in a privileged position with access to mailboxes, directory-connected workflows, and administrative interfaces.

Failure mechanism: A publicly reachable, unpatched Exchange instance gives an attacker a direct route to code execution, then to post-compromise activity such as web shell placement, credential capture, mailbox access, or lateral movement into adjacent systems.

Impact: Even after the update is installed, an environment can remain compromised if defenders do not check whether the server was touched before remediation. That is why log review, integrity checks, and follow-on investigation are part of the fix, not optional extras.

How to verify containment and recover safely

After the update or mitigation is applied, validate the exact server list again and confirm which hosts were reachable during the exposure window. If the server was exposed, review authentication, IIS, Exchange, and security logs for suspicious requests, unusual process creation, anomalous admin activity, or signs of a web shell. If you cannot prove the host was clean, assume earlier compromise until evidence says otherwise.

When earlier exploitation is plausible, credential hygiene matters as much as patching. Rotate privileged credentials, reset any accounts that may have been used on the server, and review service-account usage where Exchange integrations depended on stored secrets or delegated access. If the server handled sensitive mail flow, also review whether message access or forwarding rules were abused.

Risk and Threat Considerations

The main threat is not just that an attacker can execute code, but that Exchange often has enough trust and reach to make that code execution strategically valuable. A successful compromise can expose mail content, enable persistence, and provide a foothold into identity-connected infrastructure, so delaying remediation increases both blast radius and dwell time.

Failure mechanism: Attackers look for exposed Exchange servers because they are high-value, externally reachable, and often integrated with authentication, messaging, and admin workflows. A successful exploit can be followed by stealthy persistence and secondary abuse of trusted access paths.

Impact: The longer a vulnerable instance stays online, the more likely it becomes that defenders must respond to both the vulnerability and the compromise that occurred through it. That increases recovery time, forensics scope, and the chance of downstream account abuse.

Standards & Framework Alignment

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

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 patching and exposure review are core vulnerability management tasks.
Recommendation — Prioritise exposed Exchange instances for rapid remediation and verification.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue is a known flaw that requires vendor update or mitigation.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch log review is needed to detect earlier exploitation.
	AC-4 — Information Flow Enforcement	Removing internet exposure is a mitigation when patching cannot be completed immediately.
Recommendation — Apply the vendor update or documented mitigation and verify remediation. Review Exchange and system logs for signs of compromise after remediation. Restrict or remove external access to vulnerable Exchange servers until fixed.

Practitioner Guidance

What to prioritise: Patch the exposed Exchange population first, then verify whether any instance was ever internet-facing during the vulnerable window. Internet exposure changes the response from routine remediation to compromise assessment.

What to verify: Confirm the vendor update or documented mitigation is actually in place on every instance, and confirm the server is no longer reachable from untrusted networks if patching is deferred. A patched server that remains unnecessarily exposed still belongs on the watchlist.

Decision rule: If you cannot prove the host was clean before remediation, treat the event as possible intrusion and escalate to incident response before closing the ticket.

Practitioner takeaway: For Exchange, the right question is not only “is it patched?” but “was it exposed long enough to be abused, and what evidence do we have that it was not?”