CVE-2021-27065 is a remote code execution vulnerability in Microsoft Exchange Server. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Microsoft Exchange Server contains an unspecified vulnerability that allows for remote code execution. This vulnerability is part of the ProxyLogon exploit chain.
What This Vulnerability Means in Exchange Server
CVE-2021-27065 is a remote code execution flaw in Microsoft Exchange Server, which makes it dangerous because successful exploitation can let an attacker run code inside a trusted messaging and directory environment. The fact that CISA added it to the KEV catalogue means it is not just theoretical, it was observed in real-world abuse.
For a product like Exchange, remote code execution is especially serious because the server often sits at the centre of mail flow, user access, directory integration, and administrative workflows. Once that boundary is crossed, an attacker is no longer limited to reading mail, they may be able to pivot into adjacent systems and abuse the trust that organisations place in the messaging platform.
Why Exchange RCEs Are So Dangerous
Remote code execution in an internet-facing collaboration platform can turn a single application bug into broad enterprise exposure. Microsoft Exchange Server is a high-value target because it is widely reachable, deeply integrated, and frequently trusted by users, administrators, and other services.
The ProxyLogon context matters because it shows how this vulnerability sat inside a broader exploitation pattern rather than an isolated defect. Attackers who gain code execution on Exchange can often pursue mailbox access, persistence, or follow-on privilege escalation, especially if the server is exposed and monitoring is weak. Vulnerability Management Guide is useful background for prioritising KEV-listed issues like this one.
How Organisations Check Exposure and Recover
Exposure review starts with asset inventory, service ownership, and a clear list of every Exchange server that is internet-facing or reachable from trusted internal networks. Teams should compare that inventory with vendor advisories and the CISA KEV catalogue rather than assuming patch status from configuration management alone. The relevant vendor guidance and KEV entry are the authoritative sources for version-specific remediation details.
If patching is delayed, compensating controls matter: isolate the server, reduce public exposure, review inbound management paths, and treat the system as a likely intrusion candidate if exploitation is suspected. NIST National Vulnerability Database and the CVE Program are the canonical references for tracking the record, while Vulnerability Management Guide supports the operational prioritisation process.
Detection and Post-Exploitation Review
Detection should focus on signs that the Exchange host was used as an initial foothold: unusual web requests, spawned processes that do not fit normal mail server behaviour, new administrative artefacts, and unexpected changes to accounts, mailbox rules, or scheduled tasks. Because exploitation can be chained into persistence, post-patch review should not stop at confirming the version is fixed.
When a KEV-listed Exchange flaw has been exploited, organisations should assume the attacker may have used the server to collect credentials, tokens, or other trust material from the surrounding environment. That means reviewing authentication logs, admin activity, and any downstream systems the server could reach through delegated trust or stored secrets.
Risk and Threat Considerations
Exchange RCE is dangerous because the server commonly sits on a high-trust path between external senders, internal users, and administrative functions. If an attacker reaches code execution, they may use the host as a launch point for persistence, mailbox theft, and lateral movement before defenders notice.
Failure mechanism: A remotely reachable flaw in a trusted server allows untrusted input to become executable code, which can then be chained into web shell placement, credential access, or internal pivoting.
Impact: Organisations can lose confidentiality of email and attached data, undermine integrity of directory-connected workflows, and face broader enterprise compromise if the server is used as an initial access and persistence point.
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 and NIST SP 800-53 Rev 5 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 RCE exposure depends on knowing which servers are vulnerable and internet-facing. |
| Recommendation — Inventory Exchange assets and map them against KEV-listed exposure to prioritise remediation. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This issue requires continuous identification of vulnerable Exchange hosts and exposed services. |
| SI-2 — Flaw Remediation | CVE-2021-27065 is a flaw that demands timely remediation and verification after patching. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploitation review depends on analysing logs for suspicious Exchange activity. | |
| Recommendation — Scan Exchange deployments, confirm exposure, and track remediation until the flaw is removed. Apply the vendor fix, then verify the vulnerable condition is no longer present. Review Exchange and authentication logs for exploitation, persistence, and lateral movement indicators. | ||
Practitioner Guidance
Why practitioners should care: A KEV-listed Exchange RCE should be handled as active exposure, not routine housekeeping. The operational question is whether the server can still be reached, abused, or used as an internal pivot while remediation is pending.
What to watch for: Review the server for web shell indicators, unexpected child processes, unusual authentication activity, and mailbox or transport-rule changes that do not fit normal administration. If exploitation is suspected, treat identity material and administrative access paths as potentially compromised and validate them independently.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org