September 2026 Windows Server updates break RDS, and rollback reinstates a 9.8-severity flaw

What broke

According to a write-up on dev.to, the cumulative updates Microsoft shipped on September 8, 2026 — KB5122876 for Windows Server 2019, KB5122882 for Windows Server 2022 and KB5122871 for Windows Server 2025 — appear to install normally, and Remote Desktop Services behaves fine for a window of several hours. The failure then arrives with the first wave of user logouts: existing sessions stop terminating cleanly, new connection attempts hang, and related tooling such as MMC, the RDS Licensing Diagnoser and File Explorer can freeze alongside. Some administrators reported needing a hard reset to recover hosts.

Microsoft's public documentation acknowledges the failure and offers one workaround: stop and restart the affected virtual machine. The release-health entry for Windows Server 2025 marks the issue as mitigated as of September 11 and says a permanent resolution will come in a future Windows update. As of the dev.to post's publication, no Group Policy object or Known Issue Rollback package is listed on that public page.

The rollback trade-off

The same September cumulative cycle also delivered the fix for CVE-2026-69525, a use-after-free remote code execution vulnerability in Windows RDS rated CVSS 9.8. The dev.to post describes it as unauthenticated, requiring no user interaction, and affecting Windows Server versions from 2012 through 2025 plus several client editions. The affected builds reportedly line up with the September patched versions across all three server releases — 17763.9245 for Server 2019, 20348.5622 for Server 2022 and 26100.33438 for Server 2025.

That produces a three-way bind with no safe resting state. Keep the update installed and wait out an outage that can hang sessions indefinitely. Sit patched-but-failed, still protected against the CVE but with the service effectively down. Or uninstall the update to restore availability — and, by construction, return the host to the vulnerable state for a 9.8-severity flaw on infrastructure that may be reachable over RDP. The dev.to analysis stresses that vulnerability, confirmed exploitation and actual internet exposure are three separate things, but the rollback decision itself is unavoidable.

Root cause remains unconfirmed

Microsoft has confirmed the failure mode and the restart workaround, but not the underlying mechanism. The working theory in circulation comes from an administrator's kernel-level debugging of a Server 2022 host, posted on Reddit and reported by BleepingComputer: the service hangs inside RDPSERVERBASE!WDLIB_Close, apparently lacking a timeout, which deadlocks RDP against LSM (the Local Session Manager). Some later practitioner write-ups tie the hang to an internal feature flag gating that code path, though the dev.to post classifies that as weaker evidence stacked on already-unconfirmed evidence.

The practical warning: if incident response plans, monitoring thresholds or postmortem language get built around a deadlock theory and Microsoft's eventual root-cause analysis names something else, that process rests on a plausible guess. The architectural problem — a patch that broke availability, where recovery reverses a security fix — holds regardless of which mechanism the final RCA identifies.

There is also an information asymmetry worth flagging. The dev.to write-up reports practitioner claims that a Known Issue Rollback via Group Policy does exist, but is documented only inside Microsoft's M365-admin Message Center, a channel many Windows Server shops without an M365 tenant relationship never see. Two administrators managing the same failure and the same exposure may therefore be working from different mitigation menus.

Why it matters

This incident is a concrete example of patch rollback risk: when remediation and the recovery from that remediation's failure mode compete for the same decision, there is no automatically safe fallback. Teams whose reflex is to pull a bad update need a rollback policy that first checks which CVEs the removal reinstates and which compensating controls — network-level RDP access restrictions, session broker isolation — can stand in while the host is unprotected again. It also shows why vendor communication channels matter: with mitigation guidance split between a public release-health page and a gated admin center, the quality of an incident response can depend on which channel the responding admin happens to have. Until Microsoft ships the promised permanent fix, every affected organization is left making its own call between uptime and an unauthenticated RCE on its remote access infrastructure.