How to Fix ProxyLogon (CVE-2021-26855) on Exchange Server

ProxyLogon (CVE-2021-26855) is a server-side request forgery flaw in on-premises Exchange Server 2013, 2016 and 2019 that lets an unauthenticated attacker who can reach HTTPS authenticate as the Exchange server itself. Fix it by installing security update KB5000871, or better the latest CU plus current SU, then hunt for web shells before trusting the server.

What the scanner is actually detecting

Nessus reports ProxyLogon CVE-2021-26855 under two plugins, and they test different things:

• 147171, Microsoft Exchange Server Authentication Bypass (family: Windows, severity Critical). Tenable describes it as a direct, uncredentialed check: it tests whether the Exchange instance responds to the CVE-2021-26855 exploit itself, rather than reading a version number. If it fires from an external scanner, anyone on the internet can run the same test.
• 147003, Security Updates for Microsoft Exchange Server (March 2021) (family: Windows : Microsoft Bulletins). This is a local version check that needs a credentialed scan. It flags a missing KB5000871 and covers the whole March 2021 set: CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 and CVE-2021-27078.

Both list the same solution: install KB5000871. Seeing 147171 means the server is exploitable from where your scanner sits. Seeing only 147003 means the installed build is missing the fix, whether or not something in front of the server is currently blocking the attack.

Real-world risk

This is one of the few findings where “critical” is not an overstatement. Microsoft disclosed on March 2, 2021 that CVE-2021-26855 was being used as a zero-day by the group it tracks as HAFNIUM, and within days reported multiple other actors exploiting unpatched servers. The SSRF gives the attacker an authenticated session as the server; chained with CVE-2021-26858 or CVE-2021-27065 (post-authentication arbitrary file write), it was used to drop ASPX web shells for persistent access. CISA’s Known Exploited Vulnerabilities catalog lists CVE-2021-26855 and flags known use in ransomware campaigns; our explainer on the CISA KEV catalog covers what that listing means for remediation deadlines.

The honest limits: Exchange Online is not affected, and the first step of the chain needs an untrusted connection to the Exchange server’s web front end. An Exchange server reachable only from the internal network is less exposed, but any compromised workstation can still reach it. More important, Microsoft is explicit that installing the update or a mitigation will not evict an attacker who already got in. A server that sat unpatched and internet-facing should be investigated, not just patched.

How to confirm it on the host

Check the installed build

Get-ExchangeServer shows only the CU, not installed security updates. To see the SU level, read the ExSetup.exe file version from the Exchange Management Shell, as Microsoft’s build numbers page describes:

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

Compare the result with the first fixed build for your CU (from Microsoft’s Exchange build numbers page). Anything lower is vulnerable:

On Exchange 2016 or 2019, Microsoft’s HealthChecker.ps1 script (from the CSS-Exchange GitHub repository) reports the build, detected security updates and known vulnerabilities in one pass. Run it as Administrator in the Exchange Management Shell with .HealthChecker.ps1.

Look for signs of exploitation

Microsoft’s Test-ProxyLogon.ps1 automates all four log checks from the HAFNIUM advisory. To check every Exchange server and save reports:

Get-ExchangeServer | .Test-ProxyLogon.ps1 -OutPath $homedesktoplogs

If you want to see the raw evidence for CVE-2021-26855 yourself, Microsoft’s advisory gives this query against the HttpProxy logs (slow on large log sets, trimmed here to fewer columns):

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILESMicrosoftExchange ServerV15LoggingHttpProxy" -Filter '*.log').FullName |
  Where-Object { $_.AnchorMailbox -like 'ServerInfo~*/*' -or $_.BackEndCookie -like 'Server~*/*~*' } |
  Select-Object DateTime, AnchorMailbox, UrlStem, RoutingHint, BackEndCookie, UserAgent

Then review the web shell locations Microsoft observed for unexpected or recently modified .aspx files:

Get-ChildItem -Path 'C:inetpubwwwrootaspnet_client' -Recurse -Filter *.aspx
Get-ChildItem -Path "$env:ExchangeInstallPathFrontEndHttpProxyowaauth" -Filter *.aspx | Sort-Object LastWriteTime

The owaauth folder contains legitimate .aspx files, so look for names and timestamps that do not match the rest. Finally, download the current Microsoft Safety Scanner on each Exchange server, run a full scan and read the log at %SYSTEMROOT%debugmsert.log. The scanner expires 10 days after download, so fetch a fresh copy each time.

How to fix it

Step 1: contain the server if you cannot patch today

Microsoft’s highest-assurance interim step is to block access to the vulnerable server from untrusted networks until it is patched. If you are not sure which Exchange hosts are reachable from outside, that is an external attack surface scoping problem worth solving first. Microsoft’s Exchange On-premises Mitigation Tool (EOMT) can add an IIS URL Rewrite rule for this CVE:

.EOMT.ps1 -CVE "CVE-2021-26855"

Its current documentation lists Exchange Server SE on Windows Server 2019 or later, IIS 7.5 or later and the IIS URL Rewrite module among its requirements, so confirm your server qualifies. Microsoft states plainly that EOMT is temporary and that the security update is the only full protection.

Step 2: install the KB5000871 Exchange security update or a later build

• Exchange 2019: KB5000871 installs on RTM through CU8. The better target is the latest CU (CU15) plus the latest SU available to you.
• Exchange 2016: KB5000871 installs on CU8 through CU19. The better target is CU23 plus the latest SU available to you.
• Exchange 2013: KB5000871 installs on SP1, CU21, CU22 and CU23. Use CU23. Exchange 2013 left extended support in April 2023 and receives no further fixes.
• Exchange 2010: not affected by CVE-2021-26855. Microsoft says it is only affected by CVE-2021-26857, which has its own update.
• Hybrid: Microsoft says a hybrid server kept only for management still needs the update.

The March 2021 builds for older CUs were a stopgap to get servers patched quickly; they are not a destination. Also note that Exchange 2016 and 2019 went out of support on October 14, 2025. Security updates released from December 2025 onward go only to customers enrolled in Microsoft’s Extended Security Update program, and Microsoft’s guidance for everyone else is to migrate to Exchange Server SE or Exchange Online.

Installing a security update (.msp)

Do not double-click the file. KB5000871’s known issues say that with UAC enabled, some files are not updated when you do, which can break Outlook on the web and the Exchange Control Panel. Open an elevated command prompt and type the full path of the downloaded file:

C:Updates<downloaded SU file>.msp

Installing a cumulative update

Take a tested backup of Active Directory and Exchange, put DAG members in maintenance mode, mount the CU ISO and run setup from an elevated prompt (E: is the mounted ISO here):

E:Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /Mode:Upgrade

That switch is required for CUs released from September 2021 onward. Exchange 2013 CU23 predates the change and still uses /IAcceptExchangeServerLicenseTerms. Restart the server after the CU, and patch internet-facing servers first.

How to verify the fix and rescan

1. Re-run Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo} and confirm the build is at or above the fixed build for your CU.
2. Check that every Exchange service is running and log in to Outlook on the web and the Exchange admin center to confirm they load.
3. If you applied EOMT, run .EOMT.ps1 -ShowMitigationStatus -CVE “CVE-2021-26855”. Once it reports the code fix as installed, the rule can be rolled back.
4. Rescan with both checks: an uncredentialed scan from the same network position that originally raised 147171 (an external scanner for internet-facing servers), and a credentialed scan so 147003 can read the installed build. An uncredentialed scan that does not report 147003 proves nothing.

What can break and how to roll back

• OWA or ECP errors after an SU: usually the non-elevated install problem. Reinstall the .msp from an elevated prompt.
• Exchange services left disabled: a documented KB5000871 issue. List them with Get-Service MSExchange* | Where-Object StartType -eq ‘Disabled’, restore the startup type in Services and start them.
• Lost customizations after a CU: a CU overwrites customized web.config and other Exchange XML configuration files, plus operating system TLS and cipher settings. Exchange 2019 CU13 and later back up the most common configuration files automatically; record the rest before you start.
• Add-in trust prompts that keep returning: KB5000871 notes this can happen when the browser blocks third-party cookies.

Rollback is asymmetric. An SU can be uninstalled if it causes a problem, though Microsoft advises careful vetting first. A CU cannot: uninstalling it removes Exchange from the server entirely, so your rollback path for a CU is the backup, not an uninstall. EOMT rules roll back with .EOMT.ps1 -RollbackMitigation -CVE “CVE-2021-26855”.

Common false positive reasons

• Load balancer or reverse proxy in front. Nessus 147171 attaches the result to the IP you scanned. If that is a virtual IP, check the build on every pool member rather than the one you happened to patch.
• Stale results. The server was updated after the scan that raised the finding. Rescan before escalating.
• Mitigated, not fixed. A firewall rule or URL Rewrite rule does not change the build, so 147003 keeps reporting. That is correct behavior, not a false positive.
• “Installed” but not really. An SU applied by double-click with UAC on can leave old files in place. The version check is right; reinstall elevated.

FAQ

Is patching enough if the server was exposed?

No. Microsoft states that the update does not evict an attacker already inside. Run Test-ProxyLogon and the Safety Scanner, and follow your incident response plan if either finds evidence.

Can EOMT replace the update?

No. Microsoft describes its URL Rewrite rules as a temporary measure until the security update is installed.

Which plugin should I trust, 147171 or 147003?

Both. 147171 shows the attack works from where the scanner sits; 147003 shows the installed build lacks the fix. Close both.

Does this affect Exchange Online?

No. Only on-premises Exchange Server is affected, including hybrid servers.

Tracking this finding across many hosts

With several Exchange servers, DAG members and hybrid boxes, the hard part is proving each one was both patched and checked. If you use SITEY, you can upload your .nessus export to track 147171 and 147003 per host, have AI triage flag suspected false positives with evidence for a human to decide, and use per-finding Nessus retest to confirm each server is closed.

Sources

• Tenable: Nessus plugin 147171
• Tenable: Nessus plugin 147003
• Microsoft KB5000871: Security update for Exchange Server 2019, 2016 and 2013
• Microsoft Security: HAFNIUM targeting Exchange Servers with 0-day exploits
• Microsoft Learn: Exchange Server build numbers and release dates