How to Fix ProxyShell on Exchange Server (CVE-2021-34473)

ProxyShell is a chain of three Microsoft Exchange Server flaws (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207) that lets an unauthenticated attacker run code on on-premises Exchange 2013, 2016 and 2019. Fix it by installing the May 2021 security update (KB5003435) or any later build, ideally the latest CU plus SU, then check for web shells and rogue mailbox exports.

What the scanner is actually detecting

Nessus usually raises ProxyShell through two plugins that test different things:

• 152458, Microsoft Exchange Server RCE (ProxyShell) (family: Windows, severity Critical). Tenable describes it as a remote, unauthenticated check that needs Outlook on the web (OWA) to be present on the target. It covers CVE-2021-34473. If it fires from an external scanner, the server is reachable and exploitable from the internet.
• 148476, Security Updates for Microsoft Exchange Server (April 2021) (family: Windows : Microsoft Bulletins). A local version check that needs a credentialed scan. It flags a missing KB5001779 and covers CVE-2021-28480, CVE-2021-28481, CVE-2021-28482, CVE-2021-28483, CVE-2021-33766, CVE-2021-34473 and CVE-2021-34523.

Both plugins name KB5001779 as the solution, but neither lists CVE-2021-31207, the third link in the chain, which Microsoft fixed a month later in KB5003435. Clearing both findings with the April update alone leaves part of the chain open. Target May 2021 or later.

Real-world risk

ProxyShell was presented by Orange Tsai of DEVCORE at Black Hat USA in August 2021, after first being used at Pwn2Own 2021. The three bugs work together: CVE-2021-34473 is a pre-authentication path confusion in the Autodiscover front end that reaches backend URLs as the Exchange machine account, CVE-2021-34523 lets the attacker impersonate an Exchange admin in the PowerShell backend, and CVE-2021-31207 abuses New-MailboxExportRequest to write a file, typically an ASPX web shell, anywhere on disk.

Exploitation attempts were reported in the wild from August 6, 2021. Tenable’s coverage cites LockFile ransomware deployed through ProxyShell, and Mandiant documented attackers granting the Mailbox Import Export role, exporting mailboxes into .aspx files under inetpubwwwrootaspnet_client and, in one intrusion, going on to copy the Active Directory database. CISA added all three CVEs to its Known Exploited Vulnerabilities catalog on November 3, 2021, with known ransomware use; see our explainer on the CISA KEV catalog for what that listing means for deadlines.

The honest limits: the attacker must reach the server’s HTTPS front end, and Exchange Online is not in the affected product list. The fixes shipped in April and May 2021, so a server that still reports this finding has missed years of updates, and an internet-facing one should be treated as possibly compromised. Patching closes the entry point; it does not remove a web shell or a rogue role assignment already in place.

How to confirm it on the host

Check the installed build

From the Exchange Management Shell, read the ExSetup.exe version. Get-ExchangeServer shows only the CU, not installed SUs:

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

Compare the result with Microsoft’s build numbers page:

Exchange 2019 CU10 (15.2.922.7) and Exchange 2016 CU21 (15.1.2308.8), both released June 29, 2021, and every later CU already include these fixes. Microsoft’s HealthChecker.ps1 reports the build and detected updates in one pass.

Look for signs of exploitation

Mandiant’s detection guidance flags requests to /autodiscover/autodiscover.json that also contain powershell, mapi/nspi, mapi/emsmdb or X-Rps-CAT. Search the IIS logs:

Get-ChildItem -Path "$env:SystemDriveinetpublogsLogFiles" -Recurse -Filter *.log |
  Select-String -Pattern 'autodiscover.json.*(powershell|X-Rps-CAT|mapi/nspi|mapi/emsmdb)' |
  Select-Object Filename, LineNumber, Line -First 100

Remote ProxyShell checks, possibly including the one that raised this finding, hit the same endpoint, so compare source IPs with your scanner addresses before drawing conclusions.

ProxyShell web shells are PST exports renamed to .aspx, so they begin with the PST signature !BDN. List .aspx files in the web folders and flag any with that header:

$paths = 'C:inetpubwwwrootaspnet_client', (Join-Path $env:ExchangeInstallPath 'FrontEndHttpProxy')
Get-ChildItem -Path $paths -Recurse -Filter *.aspx -ErrorAction SilentlyContinue | Where-Object {
  $fs = [System.IO.File]::OpenRead($_.FullName)
  try { $b = New-Object byte[] 4; [void]$fs.Read($b, 0, 4) } finally { $fs.Close() }
  [System.Text.Encoding]::ASCII.GetString($b) -eq '!BDN'
} | Select-Object FullName, LastWriteTime

Also review any .aspx file in aspnet_client you cannot account for, even without that header. Then check the Exchange side of the chain:

Get-ManagementRoleAssignment -Role "Mailbox Import Export" -Delegating $false |
  Format-Table Name, RoleAssigneeName, WhenCreated
Get-MailboxExportRequest -ResultSize Unlimited | Format-List *
Search-AdminAuditLog -Cmdlets New-MailboxExportRequest,New-ManagementRoleAssignment -ResultSize 5000 |
  Format-Table RunDate, Caller, CmdletName, ObjectModified
Get-RoleGroupMember "Organization Management"

Microsoft notes that the Mailbox Import Export role is not assigned to any role group by default, so every assignment needs an owner and a reason. You need that role yourself to run Get-MailboxExportRequest. An export whose file path ends in .aspx or points into a web folder is a strong indicator. The admin audit log keeps entries for 90 days by default, so an empty result does not clear an older compromise. Review Domain Admins and other privileged AD groups for unexpected members, and run a freshly downloaded Microsoft Safety Scanner, which expires 10 days after download and logs to %SYSTEMROOT%debugmsert.log.

How to fix it

Interim: restrict access

If you cannot patch today, block the server’s HTTPS endpoints from untrusted networks. That is containment, not a fix.

Update by version

• Exchange Server SE: not affected. Stay on the latest SU (15.2.2562.49, September 2026, at the time of writing).
• Exchange 2019: KB5003435 installs on CU8 and CU9. The better target is CU15 plus the latest SU available to you.
• Exchange 2016: KB5003435 installs on CU19 and CU20. The better target is CU23 plus the latest SU available to you.
• Exchange 2013: KB5003435 installs on CU23 only. Exchange 2013 left extended support in April 2023; the last SU is March 2023 (15.0.1497.48).

Exchange 2016 and 2019 are out of support. Security updates from December 2025 onward go only to customers in Microsoft’s Extended Security Update program; everyone else should plan a move to Exchange Server SE or Exchange Online. If Exchange keeps drifting this far behind, fold it into a regular Patch Tuesday planning cycle instead of treating it as a special case.

Installing a security update (.msp)

Do not double-click the file. Both KB5001779 and KB5003435 warn that installing without elevation can leave files un-updated and break OWA and the Exchange Control Panel. Run it from an elevated command prompt:

C:Updates<downloaded SU file>.msp

Installing a cumulative update

Take a tested backup, put DAG members in maintenance mode, mount the CU ISO and run setup elevated (E: is the ISO):

E:Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF /Mode:Upgrade

Install the CU first, then the latest SU for that CU, and restart. Exchange 2013 CU23 predates this switch and uses /IAcceptExchangeServerLicenseTerms.

How to verify the fix and rescan

1. Re-run the ExSetup.exe version command and confirm the build is at or above the May 2021 SU for your CU.
2. Confirm all Exchange services are running, and that OWA and the Exchange admin center load.
3. Rescan twice: uncredentialed from the position that raised 152458, and credentialed so 148476 can read the build.
4. Repeat the web shell and mailbox export checks. The update does not remove what an attacker left behind.

What can break and how to roll back

• OWA or ECP errors: usually a non-elevated SU install. Reinstall the .msp elevated.
• Exchange services left disabled: a KB5003435 known issue. Set them back to Automatic in Services and start them.
• Management Shell errors: KB5001779 lists cmdlets failing with “The syntax is not supported by this runspace” and admin accounts ending in “$” failing to connect.
• Cross-forest free/busy: both KBs list “(400) Bad Request” failures in some cross-forest setups.
• Lost customizations: a CU overwrites customized web.config and other Exchange configuration files, so record them first.

An SU can be uninstalled. A CU cannot be rolled back in place, because uninstalling it removes Exchange from the server; your rollback for a CU is the backup.

Common false positive reasons

• Load balancer in front. 152458 is attached to the scanned IP. If that is a virtual IP, check the build on every pool member.
• Stale results. The server was patched after the scan. Rescan before escalating.
• Blocked, not fixed. A firewall rule stops 152458 from reaching OWA but does not change the build, so 148476 keeps reporting. That is correct.
• “Installed” but not really. An SU applied without elevation can leave old files in place, so a remote check may still succeed.

The reverse also happens: 152458 needs OWA, so its silence on a host where OWA is disabled or unreachable proves nothing about the build.

FAQ

Is ProxyShell the same as ProxyLogon?

No. ProxyLogon (CVE-2021-26855 and related bugs) was fixed in March 2021. ProxyShell is a different chain fixed in April and May 2021, so the March update alone does not cover it.

We installed the April 2021 update. Are we done?

Not quite. It fixes CVE-2021-34473 and CVE-2021-34523 and clears both plugins, but CVE-2021-31207 needs the May 2021 update or later.

Does ProxyShell affect Exchange Online?

No. The fixes apply to on-premises Exchange Server 2013, 2016 and 2019, including hybrid servers.

Is patching enough if the server was exposed for months?

No. Run the compromise checks above, and if you find a web shell or unexplained export, follow your incident response plan, including a review of Active Directory.

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 152458 and 148476 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 152458, Microsoft Exchange Server RCE (ProxyShell)
• Tenable: ProxyShell, attackers actively scanning for vulnerable Exchange servers
• Microsoft KB5003435: Security update for Exchange Server 2019, 2016 and 2013, May 11, 2021
• Microsoft Learn: Exchange Server build numbers and release dates
• Mandiant: PST, Want a Shell? ProxyShell exploiting Microsoft Exchange servers