Exchange's deserialization problem didn't start in 2023. It still isn't fixed.

Storm-1175 does not need a zero-day to get into on-prem Exchange. They need a good authenticated RCE from 2023, because a meaningful number of Exchange servers are still running 2023-era cumulative updates. Or older. CVE-2023-21529, patched in February 2023, sat dormant for three years with no mass exploitation. Then a China-linked ransomware group picked it up, and their operational tempo from initial access to ransomware deployment is under 24 hours.

CISA added it to the KEV catalog on April 13, 2026 with a 14-day remediation deadline. The bug is a CVSS 8.8 authenticated RCE in Exchange Server’s PowerShell remoting backend. The three-year gap between patch availability and active exploitation says less about the severity of the bug and more about the state of Exchange patching. That’s the story here.

The bug and the pattern behind it

CVE-2023-21529 is a deserialization bypass. The MultiValuedProperty class was on Exchange’s deserialization allow list. That class contained an internal deserialization mechanism that an attacker could use to bypass the allow list entirely, ultimately executing arbitrary code under the Exchange service account. The attack requires authentication, but any valid Exchange mailbox account is sufficient. Phished credentials work.

Microsoft’s fix added a deny-list check and removed the offending class from the allow list. The Zero Day Initiative later showed the deny-list was itself bypassable. So the fix for the deserialization bypass was itself bypassed. This is Exchange’s PowerShell remoting surface in miniature.

This is not an isolated finding. That same surface has produced high-severity RCEs on a roughly annual cadence since at least 2020: CVE-2020-0688 (hardcoded ViewState keys), ProxyLogon and ProxyShell in 2021 (ProxyLogon alone compromised an estimated 250,000 servers), ProxyNotShell in late 2022 (which hit Rackspace). Then came February 2023, which shipped not one Exchange RCE but four, all sharing ProxyNotShell’s PowerShell attack surface. If you run on-prem Exchange, this is a surface that generates new CVEs faster than most shops close the old ones, and your patching strategy needs to account for that reality rather than pretending each CVE is an isolated event.

Why it sat for three years

When CVE-2023-21529 was patched in February 2023, Shadowserver reported around 87,000 vulnerable Exchange instances. GreyNoise saw no exploitation activity. No mass exploitation followed. For most teams, the February 2023 SU deployed (or didn’t), and the ticket closed. The bug disappeared into the backlog of Exchange CVEs that didn’t demand emergency action.

Storm-1175, operating Medusa ransomware campaigns, eventually picked it up. Exchange is attractive to groups like this for a specific reason: the authentication bar is low (any mailbox credential works), the post-exploitation payoff is high (the Exchange service account typically has extensive AD rights), and the unpatched population is large enough that scanning at scale still finds targets three years later. CVE-2023-21529 was one of 16 or more CVEs across 10 products in their initial-access toolkit. Target sectors: healthcare, education, finance, professional services, concentrated in the US, UK, and Australia.

If you’re an attacker shopping for reliable initial access, you don’t need a fresh exploit. You need patience and a scanner.

The patching problem nobody wants to talk about

Exchange CU patching is not like installing a Windows cumulative update. A CU is a full product update. It typically takes 45 to 90 minutes per server. It requires elevated schema rights. In a Database Availability Group, you have to put each member into maintenance mode, patch it, bring it back, and move to the next. Rollback isn’t “uninstall the update.” Rollback is “restore from backup.”

This is why Exchange admins are perpetually one to two CUs behind. Not out of negligence, but because the patching process itself is expensive. The February 2023 SU that fixes CVE-2023-21529 required Exchange 2019 CU12 or CU11, Exchange 2016 CU23, or Exchange 2013 CU23. If you were behind on CUs when the patch shipped, you had to do a CU upgrade first, then apply the SU. That’s not a Tuesday afternoon. That’s a change board submission, a maintenance window, a rollback plan, and a prayer that EWS doesn’t break afterward.

And it did break. Microsoft acknowledged a post-patch regression where the EWS application pool could stop responding, later addressed in KB5024257. Every admin who’s been burned by an Exchange post-patch regression has a reason to wait for the next CU. Every CU they skip makes the next one harder. Microsoft has effectively built a patching system where caution and accumulating risk are the same behavior.

On top of all this, Exchange 2016 and 2019 reached end of support in October 2025. Exchange Server SE (Subscription Edition) is the successor. Organizations that haven’t migrated are running unsupported software. Those that have hybrid deployments still need at least one on-prem Exchange server for Active Directory recipient attribute management, which means the patching burden doesn’t fully disappear even after moving mailboxes to Exchange Online. Exchange Online itself is not affected by CVE-2023-21529.

As of late 2023, roughly 16% of Exchange mailboxes were still on-premises, concentrated in government, finance, healthcare, and mid-market organizations. Exactly the sectors Storm-1175 is targeting.

What to do this week

The CISA KEV deadline was April 27. If you’re reading this, that window has closed. Here’s what matters now.

Confirm your Exchange build number. Check every on-prem Exchange server. If you’re below Exchange 2019 CU12 SU6, CU11 SU10, Exchange 2016 CU23 SU6, or Exchange 2013 CU23 SU20, you are exposed to CVE-2023-21529 and the three companion RCEs from that same month. There is no workaround. The fix is KB5023038 or a later CU that includes it.

Check your IIS logs for anomalous POSTs to /PowerShell/. That endpoint is the attack surface for this class of Exchange deserialization bug. Look for unusual payload sizes or unexpected source IPs. Also watch Event ID 4688 for w3wp.exe spawning cmd.exe or powershell.exe, which indicates post-exploitation activity. New .aspx files written by w3wp.exe are a web shell indicator. If you run ExtraHop, they have a specific detection rule for Exchange deserialization exploit attempts covering this CVE family.

Restrict /PowerShell/ access. If you can limit the PowerShell virtual directory to admin-only IP ranges and enforce MFA on those connections, you reduce the exposure surface significantly. This isn’t a fix; it’s a compensating control. But it’s a real one.

Segment your Exchange servers. If your Exchange boxes sit flat on the same network segment as everything else, post-exploitation lateral movement is trivial. Storm-1175’s playbook includes unauthorized account creation, web shells, PowerShell-based lateral movement, PsExec, RDP, and Cloudflare Tunnels. Network segmentation raises the cost of every one of those steps.

Have the migration conversation. If you’re still running on-prem Exchange that’s now past end of support, the question isn’t whether to move. The question is how much longer you can justify the risk and the patching burden of infrastructure that generates a new authenticated RCE every six to twelve months. Every quarter you defer the migration, the CU gap widens, the catch-up cost grows, and the attack surface stays open.

The window

CVE-2023-21529 has an EPSS score in the 97th percentile, around 36-37%. That’s a statistical way of saying what the KEV listing already confirmed: this is being exploited in the real world, against real targets, right now.

The operational lesson is specific. Exchange on-premises has a patching problem that compounds over time. CUs are expensive to apply, regressions are common, and the platform’s deserialization attack surface keeps producing new entry points faster than most shops can close the old ones. Each quarter you defer, the gap between your build and the current SU grows, and the catch-up cost grows with it. The February 2023 SU was not optional. It was not one of those patches you could safely defer. Three years later, the bill came due.

PatchDay Alert tracks which KEV additions actually change the plan for your maintenance window, not just which CVEs shipped. If an Exchange deserialization bug from 2023 is showing up in ransomware campaigns in 2026, that’s the kind of signal that belongs in your Tuesday morning triage, not buried in an advisory you already closed three years ago.