21,899 Exchange Servers Are Still Unpatched. Is One of Them Yours?

Microsoft shipped the fix for CVE-2026-62911 in the August 2026 Patch Tuesday release. The vulnerability affects Exchange Server 2016 and Exchange Server Subscription Edition (SE), and it is not a minor one: according to Bleeping Computer, it can be exploited by attackers to gain full access to affected systems. Weeks later, The Shadowserver Foundation still counts 21,899 unpatched Exchange servers exposed online, with the highest concentrations in the US and Germany. The Netherlands NCSC and other agencies have told admins, publicly and plainly: install the latest patches now.

Here is the uncomfortable part. Most of the teams behind those 21,899 servers are not lazy or careless. They have RMM platforms. They have WSUS. Many have a spreadsheet that says August patches — deployed. The pipeline broke somewhere between approval and application, and none of their tools noticed. This post is about why that happens, and what it takes to make "we patched" actually mean "we are patched."

Why "We Have Patch Management" Isn't the Same as "We're Patched"

The reboot gap. A patch being installed and a patch being applied are two different events. Between them sits a pending reboot, and a huge share of servers live in that limbo permanently. A server can report a KB as installed while the vulnerable binary is still loaded in memory. Your dashboard shows green; the exposure persists until a reboot nobody has scheduled — because the box is production, reboots need a change request, change requests need an owner, and the owner is buried in tickets.

WSUS decay. Anyone who has run WSUS for more than a year knows the pattern: clients stuck evaluating updates for 40 minutes, sync errors like 0x80244022, product categories unchecked after a database migration, superseded update chains nobody ever cleaned up. WSUS does not fail loudly. It fails quietly, and you find out during the audit — or during the incident.

Approval queue purgatory. In plenty of RMM setups, patch approvals pile up in a queue nobody owns. The approval request for the CVE coverage went to a tech who left in March. The auto-approve rule for "security updates" excludes the exact KB you need because it was misclassified. Meanwhile the internet-facing Exchange box keeps answering SMTP like nothing happened.

Patch archaeology. The moment a CVE like this hits the news, leadership asks one question: "Are we affected?" If the honest answer requires an RMM export, a spreadsheet, three RDP sessions into Exchange servers to eyeball build numbers, and two days of chasing stragglers, you do not have patch management. You have patch archaeology, performed under time pressure, producing reports nobody fully trusts.

Exchange-specific scar tissue. On-prem Exchange admins have been burned before: security updates that broke transport, .NET version roulette before SUs, a post-install permission fix that had to be applied manually or mail flow died. So teams wait a week. Then a month. Then the wait quietly becomes never — which is exactly how a server becomes one of the 21,899.

What this actually costs

• When the vulnerability becomes an incident, the cost flips from a scheduled 30-minute maintenance window to weeks of forensics, mailbox audits, credential resets, and a very unpleasant call to leadership.
• Ticket volume spikes only after something breaks. Nobody files a ticket about an unpatched CVE — until webmail stops working. Then it is a hundred tickets about the outage, not the root cause.
• SLA and compliance reporting collapses into hand-built spreadsheets, because patch data lives in one tool, uptime in another, and tickets in a third. The IT manager presenting "99.9% compliance" to the board is often guessing.
• Technician morale erodes quietly. Someone on your team knew the second Exchange box was behind on builds. They never had time to verify it. When the incident happens, they remember that.

How AlertMonitor Closes the Gap

The root problem in every failure mode above is the same: patching runs as a separate workflow from monitoring and alerting, so nothing verifies that the patch actually landed and the server stayed healthy afterward. AlertMonitor treats patch management as part of one platform, and it shows.

Real-time patch state per device — three states, not one checkmark. AlertMonitor tracks the patch status of every managed Windows device in real time and distinguishes between updates that are missing, patches that failed to install, and patches that are installed but pending a reboot. That third state is exactly where thousands of Exchange servers are sitting right now, invisible in most other dashboards.

Staged deployments that match your change process. Patch deployments can be scheduled and staged by department or device group: pilot ring first, then production rings during approved maintenance windows, with the reboot scheduled as part of the job instead of left as a loose end. If a patch causes trouble, it can be rolled back — not turned into a 2am emergency.

Patch status integrated with monitoring. This is the part that changes your mornings. When a device reboots unexpectedly at 2am after an update, AlertMonitor fires an alert with full context — the device, the patch job, the expected post-reboot state — instead of a mystery outage discovered by users at 8am. Post-patch checks confirm services are running and the compliance state has flipped. The loop closes itself.

One view across every client. For MSPs: when the next CVE drops, you do not open fifty client dashboards. You filter all managed servers across the entire client base by product and missing KB, get an exposure report in minutes, stage the deployment, let the rings run, and watch compliance climb on one screen.

The workflow, then and now:

Old way: Slack message about the CVE → export from the RMM → cross-check the inventory spreadsheet → RDP into each Exchange server to read build numbers → book maintenance windows → deploy → hope someone notices if the reboot goes sideways.

AlertMonitor way: filter devices by role → exposure report in minutes → stage deployment to a pilot group → push remaining rings in scheduled windows with reboots included → automated post-checks → compliance report generated from the same live data leadership asks about.

What You Can Do Today

1. Establish ground truth on every Exchange server. The exact build number is the only trustworthy answer to "are we patched?":

# Run on the Exchange server, or wrap in Invoke-Command for remote execution
(Get-Command "$env:ExchangeInstallPath\Bin\ExSetup.exe").FileVersionInfo.ProductVersion

Across the whole estate:

$exchServers = "EXCH01","EXCH02","EXCH03"
Invoke-Command -ComputerName $exchServers -ScriptBlock {
    [PSCustomObject]@{
        Server = $env:COMPUTERNAME
        Build  = (Get-Command "$env:ExchangeInstallPath\Bin\ExSetup.exe").FileVersionInfo.ProductVersion
    }
} | Format-Table -AutoSize

Compare the build against Microsoft's advisory for CVE-2026-62911. Anything older than the August 2026 Patch Tuesday build is exposed.

2. Find the servers stuck in reboot limbo. These are the machines that "got patched" but are still running vulnerable binaries:

$servers = "EXCH01","EXCH02","EXCH03"
Invoke-Command -ComputerName $servers -ScriptBlock {
    $cbs = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
    $wu  = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
    [PSCustomObject]@{
        Server        = $env:COMPUTERNAME
        PendingReboot = ($cbs -or $wu)
    }
} | Format-Table -AutoSize

3. Confirm recent updates actually installed. A quick spot-check for anything installed this month:

Get-HotFix -ComputerName EXCH01 |
    Where-Object { $_.InstalledOn -gt (Get-Date '2026-08-01') } |
    Sort-Object InstalledOn -Descending |
    Select-Object HotFixID, Description, InstalledOn

4. Verify services came back healthy after the reboot. Transport and RPC are where past Exchange updates have historically bitten people:

Get-Service -ComputerName EXCH01 -Name MSExchangeTransport, MSExchangeRPC, W3SVC |
    Select-Object Name, DisplayName, Status

One honest caveat: these scripts answer today's question. They do not run continuously, they do not alert when a new device falls out of compliance, they do not catch a 2am reboot that hangs, and they do not produce a board-ready compliance report. That is exactly the job AlertMonitor's patch management module does — continuously, on every Windows device you manage, integrated with monitoring and alerting so nothing lands in the "nobody knew" pile.

If you are responsible for even one internet-facing Exchange server, treat this as your trigger: verify the build, close the reboot gap, and put patch compliance somewhere you can actually see it — before the next CVE does the inventory for you.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources