Microsoft Patches the RDS Flaw, Then Breaks RDS
The September 2026 Patch Tuesday had a genuinely useful thing to say: Windows closed out roughly 966 vulnerabilities, including a no-auth remote code execution flaw in Remote Desktop Services itself. Then, within a few hours of installing the cumulative updates, RDS started misbehaving on exactly the fleets that care about it. On Windows Server 2019, 2022, and 2025 (2012 and later, plus Windows 10 and 11 per Microsoft's release-health dashboard), RDP sessions would die after a few minutes, signs would hang at ‘Please wait for the Remote Desktop Configuration,’ and in the worse cases servers just stopped accepting connections until someone did a hard reset. Microsoft confirmed it Friday, and then spent the next day shipping emergency out-of-band updates to walk it back. The irony is hard to miss: the update that was supposed to make your remote desktop stack safer is the one that made your remote desktop stop working.
That's the uncomfortable part for anyone running production. This isn't an exploitable bug or a missed CVE — it's a patch regression, the kind where the thing you deploy on schedule actively degrades the thing you depend on for recovery. And you don't get a clean undo, because rolling the update back also pulls the month's security fixes with it, including two zero-days that were being actively exploited in the wild. So your decision tree collapses into a genuine bind: keep the fix and lose the ability to administer your fleet remotely, or roll back and sit in the open to exactly the class of RDS exploit the update was there to close. Security Arsenal frames it well — the worst outcome isn't the outage, it's the reflex response of disabling patching entirely or bolting on a flat, NLA-less remote-access workaround that lingers long after the real fix lands. That's how an availability incident quietly turns into a security gap.
The emergency out-of-band updates (KB5129195 for Windows 11 25H2, and companion KBs for 21H2/22H2 and 24H2/25H2) have landed as of this morning, and Microsoft has marked the issue mitigated — there's even a Known Issue Rollback via Group Policy if you need the escape hatch before the build ships. But the operational lesson outlives the specific KB: when your recovery path is the same channel your patching runs through, a bad patch is no longer just an incident, it's a lockout. The registry-flag workarounds folks tried first are proving unreliable anyway, so don't build your recovery plan on a one-off flag. If RDP is your lifeline, what does your out-of-band access actually look like when the thing you patch to stay safe is exactly the thing that takes it down? I'd like to hear how you've kept remote admin alive through a bad patch window — console serial, a jump host you don't patch on the same cadence, something else entirely?

Sources
Comments
Post a Comment