September 2026’s patches closed a record 964 CVEs — and at the same time broke the very service half the Windows Server fleet exists for. If you run RDS hosts and after updating them they “worked fine for a couple hours, then stopped letting anyone in,” that’s not a coincidence and it’s not your configuration — it’s a known bug, and there’s a concrete fix.
What broke
September Patch Tuesday’s cumulative updates — KB5122876 (Server 2019), KB5122882 (Server 2022), and KB5122871 (Server 2025) — along with the fix for an RCE in Remote Desktop Services (CVE-2026-69525, CVSS 9.8), introduced a regression into the service itself. Several independent sources describe the exact same scenario: the server runs fine for a few hours after the patch and a reboot, and then — usually right as one of the users disconnects from their session — new RDP connections start hanging forever on the “Connecting…” screen. Logging out of an already-open session doesn’t work either. Only a hard reboot of the host fixes it.
Independent debugging on the admin side (Microsoft hasn’t officially confirmed the cause) points to a deadlock in RDPSERVERBASE!WDLIB_Close — the routine called when a session closes, with no timeout set. That explains the trigger: the bug doesn’t show up right after a reboot, it surfaces exactly at the moment someone’s RDP session ends normally.
Why you can’t just roll the patch back
The temptation is obvious: remove the update, and RDS works again. But this exact patch closes CVE-2026-69525 (an RCE in RDS, rated “Exploitation More Likely” by MSRC) and ships in the same cumulative package as fixes for two already-exploited 0-days this month. Rolling the update back across every RDS host trades “the service sometimes hangs” for “the service can run arbitrary remote code” — that is not an even trade.
How to fix it: three options, in priority order
- The out-of-band fix. Later in September, Microsoft shipped a separate update specifically fixing this deadlock, on top of the original KBs. Check the “Known issues” card for your original KB on Windows Release Health — if an OOB patch already exists for your Server version, install that instead of either workaround below.
- Known Issue Rollback (KIR) via Group Policy. While there’s no OOB patch yet for your version, Microsoft publishes a KIR — a signed package that, via GPO, rolls back specifically the broken part of the code without touching the rest of that KB’s fixes. Deploy it the standard way: the MSI package from the support site + an ADMX/ADML template in SYSVOL → your own GPO → apply with `gpupdate /force` and reboot the RDS hosts. Don’t manually copy “magic” registry values from random forum posts — different sources quote different numbers, and this is exactly the situation where you install the official package instead of eyeballing a registry edit.
- A stopgap, if neither of those can be deployed yet. Since the bug triggers hours after startup, specifically when a session ends, schedule a proactive restart of the RDS role (or the host) during your lowest-traffic window, before the deadlock has time to build up. This isn’t a fix — it’s a way to hold on until the patch lands without an unplanned outage in the middle of a workday.
To check exactly which cumulative build is on a host right now:
PowerShell
# Is one of the "guilty" September KBs installed
Get-HotFix | Where-Object { $_.HotFixID -in 'KB5122876','KB5122882','KB5122871' }
# The exact OS build — compare against the build number in your OOB patch
[System.Environment]::OSVersion.Version
# A quick list of RDS hosts that have the patch but not yet the OOB/KIR
# (cross-check the second column manually against the current build on Release Health)
Invoke-Command -ComputerName (Get-Content rds-hosts.txt) -ScriptBlock {
[PSCustomObject]@{
Host = $env:COMPUTERNAME
Build = [System.Environment]::OSVersion.Version.ToString()
}
}
How to spot the bug before users start calling
The tell isn’t “RDP doesn’t work at all” — it’s “RDP worked in the morning and stopped working after lunch.” If you monitor availability for your terminal farms, add a check that verifies not just “port 3389 is listening” but “a new connection actually reaches the login screen” — the TCP handshake still succeeds on a hung host, it’s specifically the RDP session on top of it that breaks. A simple synthetic check every 15-30 minutes catches the degradation hours before users start complaining, not after.
Checklist
- Check whether your RDS hosts have KB5122876 / KB5122882 / KB5122871 installed — using the command above.
- If they do, check Windows Release Health for whether an out-of-band fix has shipped for your Server version, and prioritize that.
- If there’s no fix yet, deploy the official KIR package via GPO — not a homegrown registry workaround from a forum.
- Don’t roll back the whole patch — doing so also rolls back the fix for CVE-2026-69525.
- Until the fix is installed, schedule proactive RDS restarts and run a synthetic check for “does RDP actually reach the login screen,” not just “is the port listening.”
Conclusion
This is exactly the case where “just roll it back” is the most obvious and most wrong answer. The regression is real and painful, but it’s fixable through the vendor’s own standard mechanisms — KIR and an out-of-band patch — without sacrificing the fix for an actively exploited vulnerability. In this situation, an architect doesn’t choose between “RDS works” and “the server is secure” — they install the correct official fix and add a schedule of proactive restarts for a couple of weeks until the patch fully rolls out.
Tags: #windows #windowsserver #rds #rdp #patchtuesday #sysadmin #kb5122882
Want to become tomorrow’s architect instead of just an admin? This article is only the tip of the iceberg. On our Telegram channel “Admin Future” we publish systems-thinking guides, ready-to-use scripts, AI tips, and checklists every day that you won’t find on Google. Subscribe and become the expert in the room: Admin Future
