The Exchange you left running: 21,899 unpatched servers, and yours could be one

On 31 August 2026, the Shadowserver Foundation's daily scans counted 21,899 IP addresses running an Exchange Server without the patch for CVE-2026-62911, released twenty days earlier. It is easy to assume those are companies that never moved to the cloud. Of the ones we run into, a good share are the opposite: organisations that have already migrated and that keep an Exchange running because someone said, years ago, that it was needed to manage users.

That server has an awkward quality: it never comes up in meetings. It hosts no mailboxes, has no users complaining, raises no tickets. It just sits there, published on the internet, with the same attack surface it had the day it was installed. And since 14 October 2025 it receives no security updates either, unless somebody paid for them.

What CVE-2026-62911 is, and what it is not

Microsoft published it on 11 August 2026 and describes it as an elevation of privilege: an attacker able to capture and replay authentication material can reuse it to gain elevated access. It is classified as CWE-294 —authentication bypass by capture-replay— with a CVSS score of 8.0. It affects Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM.

Here we have to stop at something almost no coverage mentions: the sources do not tell the same story. The vector Microsoft publishes requires low prior privileges and user interaction. Germany's Federal Office for Information Security, by contrast, describes a proof of concept that allows systems to be taken over from the internet without prior authentication, and third-party analyses point the same way. One of the two is qualifying too much. We are not going to settle that discrepancy from the outside, but we are not going to hide it either: if you are setting your patching urgency from the 8.0 score and Microsoft's vector, you are deciding on the more benign of the two readings.

What is confirmed by a national authority: the Netherlands' NCSC warned that a working exploit is circulating. From there, the window between "this is theoretical" and "this is an incident" is set by the attacker, not by you.

The detail that makes this one different

If the public reading is right, the way in is the endpoint used to move mailboxes between your Exchange and Exchange Online. Read that again: the door is the one you opened in order to migrate to the cloud. The tidier your migration was —a properly built hybrid, a published migration endpoint, a valid certificate— the likelier it is that the door is still exactly where you left it, four years after the last mailbox crossed.

The per-country numbers back this up. The United States leads with 6,200 unpatched servers, Germany follows with 5,100. But the figure that really explains the phenomenon was published by the German authority in late August, and it is hard to beat for dryness: they were aware of just nine Exchange 2016 or 2019 servers in the whole of Germany with the Extended Security Updates patches installed. Nine. The same note estimated that around 85% of the German on-premises Exchange servers they can see were still vulnerable; the denominator of that percentage is not specified, so we take it as an order of magnitude, not a census.

"But I need it to manage users"

That sentence was true for years, and it even has a name in Microsoft's documentation: the last Exchange Server problem. With directory synchronisation, a user's mail attributes are edited in the on-premises Active Directory and flow to the cloud; and the only supported commands for editing them are the on-premises Exchange ones. Not ADUC, not ADSI Edit, not third-party utilities. That is why thousands of migrations ended with the same refrain: "we'll keep one for management."

It stopped being mandatory in April 2022. From that month's Exchange 2019 cumulative update onwards —CU12 and later— the management tools can be installed on their own, on any domain-joined machine, and manage recipients from PowerShell with no Exchange running at all. These are the conditions Microsoft sets, and all of them have to hold:

It is worth not stopping in 2022, because Microsoft has moved its recommendation. In its May 2026 article on retiring the last Exchange, it calls the management-tools route a "temporary workaround": it lets you shut the server down, but not uninstall it, and above all it leaves authority over the attributes anchored in your Active Directory. The last-server problem stays open, just with the lights off.

Switching it off and removing it are not the same decision

The route Microsoft describes today for finishing the job is to transfer attribute authority to the cloud —marking each synchronised mailbox as cloud-managed, or moving the whole object to the cloud— and then uninstalling the server with Setup /m:Uninstall. That is the difference between a powered-off server that is still in Active Directory and an organisation with no on-premises Exchange left to maintain.

And here is the warning Microsoft writes in capitals and that gets mixed up constantly: if you are managing recipients with the management tools, DO NOT uninstall. The uninstaller removes the Exchange configuration containers and security groups from Active Directory, which are exactly what those tools depend on. In that scenario the server is shut down, cleaned up with the bundled script and wiped, but never run through the uninstaller. Both routes are legitimate; mixing them is what breaks things. A bonus warning that sits in the documentation and that almost nobody sees coming: if you already ran the cleanup and merely powered the server off, uninstalling it means powering it back on, and doing it as a domain admin, because the group that used to grant you permission is gone.

If you take the management-tools route, two operational details you want to know beforehand rather than afterwards. First: as soon as you power the server off, create and modify commands take around 40 seconds to respond, because the admin audit log initialiser tries to reach a machine that is no longer there; the delay goes away once you run the Active Directory cleanup script that ships with the tools. Second, and more serious: when the last Exchange goes down, RBAC stops working. Anyone who managed recipients by virtue of belonging to an Exchange group loses their permissions, and has to be granted access through the script that creates the corresponding security group. If that catches you on a Monday morning, it is not a security incident: it is an HR one.

When you should not switch it off

This post is not about switching servers off for sport. It is about every running server having a written reason to exist. There are cases where the right answer is to leave it where it is and treat it as what it is: a production system, with a patching window and an owner.

And if you stay, the calendar part needs saying. Exchange Server 2016 and 2019 went out of support on 14 October 2025. Extended Security Updates only reach organisations that enrolled, and they end on 31 October 2026. In other words: less than two months of safety net remain, and after that every new flaw stays unpatched forever. The supported way out is Exchange Server Subscription Edition, which for installation purposes is one more cumulative update from 2019 CU14 or CU15 —it shares its code with CU15— but that needs planning now, not on 30 October.

What we would do this week

None of this is a three-month project. It is half a morning of inventory and one decision.

It is the same mechanism we described when we looked at the EWS retirement and why the date that affected you was not the one in the headline, and the one that shows up every time a Microsoft 365 outage reveals that six separate services were really one dependency. The failure is almost never in the technology. It is that nobody had written down what depended on what.

A migration does not end when the last mailbox crosses

In the Microsoft 365 projects we run, the most underestimated part is not moving the mail: it is dismantling what was built in order to move it. The migration endpoint, the federation trust, the certificate, the send connector, the server. All of it goes up in a hurry because there is a cutover date, and stays forever because nobody is in a hurry to take it down.

That is why, when we come into an estate to do maintenance or review security, one of the first questions is the dullest one: what is running here that is no longer needed. It is not a cost question. A company's attack surface is not defined by the systems it uses, but by the systems it has. Behind those 21,899 IP addresses are plenty of organisations that do not even know they are on the list. That is precisely the problem: it is not that they weighed the risk and accepted it, it is that nobody put the question to them.

Sources: the count of 21,899 exposed IP addresses as of 31 August 2026 and the per-country breakdown (6,200 in the United States, 5,100 in Germany), Shadowserver Foundation daily scans as reported by Help Net Security and BleepingComputer; working exploit in circulation, NCSC-NL; the nine servers with ESU patches installed and the estimate that 85% of on-premises servers in Germany remained vulnerable, BSI statement from late August 2026 as reported by heise —the denominator of that percentage is not specified in the source—; description, CVSS 8.0, CWE-294 classification and affected versions, Microsoft's advisory of 11 August 2026 and public vulnerability databases. The hypothesis about the migration endpoint and Extended Protection for Authentication comes from technical analyses published by third parties; we have not verified it ourselves and present it as such. Management tools procedure, the do-not-uninstall warning, the 40-second delay and the loss of RBAC, and the authority-transfer route with subsequent uninstall (article updated May 2026): official Microsoft Learn documentation. End of extended support for Exchange 2016 and 2019 (14 October 2025) and the end of Extended Security Updates (31 October 2026): Microsoft announcements.