How to Fix CVE-2022-41082: Deserialization of Untrusted Data

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

Patch immediately. CVE-2022-41082 was exploited as a zero-day and sits on CISA's Known Exploited Vulnerabilities catalog (added 2022-09-30, federal due date 2022-10-21). The fix is the November 2022 Security Update for your Exchange branch — not a Linux package update.

What is CVE-2022-41082?

CVE-2022-41082 is a remote code execution vulnerability in on-premises Microsoft Exchange Server. It is one of the two bugs that together make up the chain the security community named ProxyNotShell. The other bug, CVE-2022-41040, is a Server-Side Request Forgery flaw in the Autodiscover endpoint. An attacker who holds a valid mailbox credential uses the SSRF bug to reach an internal endpoint, then triggers CVE-2022-41082 to run arbitrary code as the Exchange process. That is why both CVEs were disclosed together on 30 September 2022 and why patching only one of them does not close the chain.

The underlying weakness is CWE-502, deserialization of untrusted data. Exchange exposes a PowerShell Remoting endpoint (the back-end remote PowerShell virtual directory). Once the attacker can reach it through the SSRF, they feed it a crafted serialized .NET object. When Exchange deserializes that object, the gadget chain inside it executes, and the result is code running in the context of the Exchange application pool — typically with high privilege on the server and a direct line into Active Directory. This is the same deserialization-in-remote-PowerShell pattern that produced the earlier ProxyShell family, which is exactly why the name ProxyNotShell stuck.

Why this CVE matters

Exchange Server sits at the centre of an organisation's identity and mail. Code execution on the box hands an attacker mailbox contents, the ability to plant a web shell in the Exchange virtual directories, and a foothold to escalate into the wider Active Directory forest. CVE-2022-41082 was caught as a live zero-day by an incident response team before Microsoft had a patch, and CISA added it to the KEV catalog the same day it was published. CISA's SSVC decision marks exploitation as active and the technical impact as total. If an affected, internet-facing Exchange server was unpatched at any point between late September and the November 2022 Security Update, you should hunt for compromise rather than assume you were missed.

The CVSS base score is 8.0 rather than the maximum because the vector carries PR:L — the attacker needs a valid mailbox login first. In practice that bar is low. Password spraying and phished credentials against Outlook on the web are everyday occurrences, and once one mailbox falls, the whole chain is reachable.

Am I affected?

This affects on-premises Microsoft Exchange Server only. Exchange Online (Microsoft 365 hosted mailboxes) is not affected, although a hybrid deployment still runs at least one on-prem Exchange server that is in scope. Check your installed build from the Exchange Management Shell:

# Run in the Exchange Management Shell on the server
Get-ExchangeServer | Format-Table Name, Edition, AdminDisplayVersion -AutoSize

# More precise build number, per server
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo.ProductVersion }

Compare the build to the affected ranges. You are vulnerable if you are below the fixed build for your cumulative update:

• Exchange 2013 CU23 — vulnerable below 15.00.1497.044
• Exchange 2016 CU22 — vulnerable below 15.01.2375.037
• Exchange 2016 CU23 — vulnerable below 15.01.2507.016
• Exchange 2019 CU11 — vulnerable below 15.02.0986.036
• Exchange 2019 CU12 — vulnerable below 15.02.1118.020

The fastest way to get an authoritative read across a multi-server deployment is the Microsoft Exchange Server Health Checker script, which reports each server's build and flags missing security updates against the known-vulnerable list.

How to fix CVE-2022-41082

The fix is the November 2022 (Nov 8, 2022) Security Update for Exchange Server. It must match your cumulative update level — an SU for CU23 will not install on CU22. Bring each branch to at least the fixed build listed above. Exchange security updates are installed from elevated rights; running the installer by double-click without “Run as administrator” is the classic cause of a broken install where services fail to start afterward.

Step 1: confirm your CU level and download the matching SU

You can only apply the latest SU for the CU you are on (or the one before it). If you are on an older CU than the supported ones above, update the cumulative update first, then apply the November 2022 SU. Download the correct package from the Microsoft Update Catalog or let Microsoft Update offer it.

Step 2: install the Security Update from an elevated prompt

# Open an ELEVATED PowerShell or cmd window (Run as administrator), then:
# Put the server into maintenance / drain connections first on a DAG member.
# Install the downloaded .msp (file name will match your CU, e.g. Exchange2019-KB5019758-x64-en.msp)

Start-Process msiexec.exe -Wait -ArgumentList '/update "C:\Patches\Exchange2019-KB5019758-x64-en.msp" /quiet /norestart'

# Reboot when the installer finishes so all Exchange services reload the patched binaries.
Restart-Computer

On a Database Availability Group, patch one node at a time: put the member into maintenance mode (the StartDagServerMaintenance.ps1 script that ships with Exchange), apply the SU, reboot, take it out of maintenance, then move to the next node. That keeps mail flowing during the rollout.

Step 3: alternative — Windows Update / WSUS

# If you manage patches centrally, the SU is offered through Windows Update / WSUS.
# Verify it installed and the build moved:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo.ProductVersion }

After the reboot, confirm the four core services are healthy — MSExchangeServiceHost, MSExchangeIS, W3SVC, and the transport services — and that Outlook on the web loads. A half-applied SU usually shows up as services stuck in “starting” or a 500 error on OWA, and the cure is to re-run the SU from an elevated prompt.

If you can't patch immediately

Microsoft published interim mitigations before the patch shipped. They are holding actions only. Early versions of the URL Rewrite rule were bypassed within days, so do not rely on a mitigation as a long-term fix — install the November 2022 SU.

Block remote PowerShell for non-admins

CVE-2022-41082 is reached through the PowerShell Remoting endpoint. Removing remote PowerShell access from standard users shrinks the attack surface for the RCE half of the chain.

# In the Exchange Management Shell. Audit who has remote PowerShell enabled first:
Get-User -ResultSize Unlimited | Where-Object { $_.RemotePowerShellEnabled -eq $true } |
    Select-Object Name, RemotePowerShellEnabled

# Disable it for a non-admin account that does not need it:
Set-User -Identity "" -RemotePowerShellEnabled $false

URL Rewrite rule on the Autodiscover path

The interim mitigation blocks the known attack pattern in the Autodiscover request that CVE-2022-41040 abuses to reach the RCE. The most reliable way to apply it is the Microsoft Exchange On-premises Mitigation Tool (EOMT.ps1), which installs IIS URL Rewrite if needed and adds the current rule automatically.

# Run from an elevated Exchange Management Shell. EOMT applies Microsoft's
# current recommended mitigation and can run health/IIS checks too.
.\EOMT.ps1

If you applied an early hand-built rewrite rule, re-run EOMT to pick up the corrected pattern — the first published rule was incomplete.

How to verify the fix worked

Confirm the build number moved to at or above the fixed build for your branch:

# Per-server build check after the SU + reboot
Get-ExchangeServer | Format-Table Name, AdminDisplayVersion -AutoSize
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo.ProductVersion }

Then re-run the Exchange Health Checker script and confirm it no longer flags CVE-2022-41082 / the November 2022 SU as missing. Because this was exploited as a zero-day, also hunt for prior compromise: inspect the Exchange virtual directory paths (aspnet_client, FrontEnd\HttpProxy\owa\auth, ecp\auth) for unfamiliar .aspx files dropped as web shells, and review IIS logs on the Autodiscover and PowerShell endpoints for the suspicious POST patterns Microsoft documented. Rotate the credentials of any account whose mailbox was reachable, and reset the Exchange machine and service accounts if you find evidence of code execution.

Frequently asked questions

Is CVE-2022-41082 the same thing as ProxyNotShell?

It is one half of it. ProxyNotShell is a chain of two bugs: CVE-2022-41040 (an Autodiscover SSRF) provides the reach, and CVE-2022-41082 (this one) is the deserialization-driven remote code execution. They were disclosed together on 30 September 2022 and you must patch both with the November 2022 Security Update.

Which Exchange build fixes CVE-2022-41082?

The November 2022 SU brings each branch to a fixed build: Exchange 2013 CU23 to 15.00.1497.044, 2016 CU22 to 15.01.2375.037, 2016 CU23 to 15.01.2507.016, 2019 CU11 to 15.02.0986.036, and 2019 CU12 to 15.02.1118.020. Confirm with Get-ExchangeServer | ft Name,AdminDisplayVersion or the Health Checker script.

Does CVE-2022-41082 require authentication?

Yes. The CVSS vector is PR:L, so the attacker needs a valid mailbox credential to begin the chain. That is why the score is 8.0 rather than 9-plus. It is not real protection though — credential theft and spraying against OWA are routine, and CISA confirmed active in-the-wild exploitation.

Is the URL Rewrite mitigation enough on its own?

No. Microsoft's interim URL Rewrite rule and the PowerShell Remoting block were stopgaps, and the early rewrite rule was bypassed within days. Treat mitigations as a holding action and install the November 2022 Security Update for the durable fix.

References

• Official vendor advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41082
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2022-41082
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-41082
• Additional reference: https://www.vicarius.io/vsociety/posts/cve-2022-41082-microsoft-exchange-server-remote-code-execution-vulnerability-detection-script
• Additional reference: https://www.vicarius.io/vsociety/posts/cve-2022-41082-microsoft-exchange-server-remote-code-execution-vulnerability-mitigation-script
• Additional reference: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41082
• Additional reference: https://www.kb.cert.org/vuls/id/915563

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Other defects in the same area that deserve attention during this patch cycle:

• How to Fix CVE-2022-37969: Out-of-bounds Write in Windows 10 Version 1809
• How to Fix CVE-2022-41040: Server-Side Request Forgery (SSRF)
• How to Fix CVE-2022-41080: Security Vulnerability in Microsoft Exchange Server 2016 Cumulative Update 23
• How to Fix CVE-2022-21971: Access of Uninitialized Pointer in Windows 10 Version 1809
• How to Fix CVE-2022-21999: Path Traversal in Microsoft Windows