Patch Rollback Risk: When Recovery Reintroduces the Exposure You Just Closed

Patch rollback risk is the operational reality sitting underneath Microsoft’s September 2026 Remote Desktop Services failure: the fastest way to restore a broken service can be the exact action that reopens a vulnerability the patch was written to close.

The September 8 cumulative updates — KB5122876 for Windows Server 2019, KB5122882 for Windows Server 2022, KB5122871 for Windows Server 2025 — appeared to install normally on affected hosts. Then, in reported cases, RDS began failing after users logged out: existing sessions stopped disconnecting cleanly, new connection attempts hung, and some administrators reported needing a hard reset. Microsoft subsequently documented stopping and restarting an affected VM as a temporary workaround.

The obvious fix — pull the update, restore RDS — is also the fix that undoes the security work that update shipped to do. That’s not a footnote to this story. It’s the actual subject. Not “was this patch buggy” (yes), and not “should you have staged it” (also yes, and beside the point). The subject is what happens architecturally the moment recovery and remediation start competing for the same decision — and who is actually positioned to make that call when they do.

What Microsoft Has Confirmed

Microsoft’s public documentation establishes the failure and the current mitigation. It does not establish the underlying mechanism. That distinction matters.

All three builds show the same pattern: RDS works normally for a window of hours after install, then destabilizes — typically triggered by the first wave of user logouts. Existing sessions stop disconnecting cleanly. New connections hang. Related tooling (MMC, RDS Licensing Diagnoser, File Explorer) can become unresponsive alongside it.

That status column needs to be read precisely, because “Mitigated” is doing less work than it sounds like. Microsoft’s own Windows Server 2025 release-health entry lists the issue as Mitigated as of September 11, with exactly one publicly documented workaround: stop and restart the affected VM. The same entry states Microsoft is “working to release a resolution in a future Windows update” — meaning the permanent fix, as of publication, has not shipped publicly. There is no Group Policy object or Known Issue Rollback package listed on that page.

Separately, several practitioner sources report that a Known Issue Rollback via Group Policy exists and is documented — but only inside Microsoft’s M365-admin-only Message Center, a channel most Windows Server shops without an M365 tenant relationship never see. We’re reporting that KIR’s existence here with that provenance attached, not folding it into “what Microsoft has confirmed publicly.” An administrator without M365 admin-center access and one with it may therefore be looking at different mitigation options for the same RDS failure, even though both are managing the same underlying security exposure — a preview of the authority problem this post is actually about, and one we’ll come back to directly in the decision surface below.

That gap also isn’t the only place information asymmetry showed up this quarter — Microsoft’s Entra ID exploitation-status reversal made the same point from the opposite direction: a status field changing underneath an admin who has no way to independently verify which version is current.

The trade-off that actually matters for modern infrastructure architecture isn’t RDS uptime versus a checkbox. It’s this: the same September cumulative cycle also shipped the fix for CVE-2026-69525, a CVSS 9.8 use-after-free remote code execution vulnerability in Windows RDS — unauthenticated, no user interaction required, published the same day as the cumulative update, and affecting Windows Server versions from 2012 through 2025 (plus several Windows client versions). It is not a Server-2025-specific fix: the confirmed affected-build ranges line up with the September patched builds across all three server versions this post covers — 17763.9245 for Server 2019 (KB5122876), 20348.5622 for Server 2022 (KB5122882), and 26100.33438 for Server 2025 (KB5122871). Roll any of the three cumulative updates back to restore RDS, and that fix goes with it.

What’s Still Just a Theory

Here’s what’s circulating as the working theory, and why it deserves exactly the weight “theory” implies. An administrator investigating a Server 2022 host reported debugging results on Reddit, quoted by BleepingComputer: “The service hangs at RDPSERVERBASE!WDLIB_Close, there seems to be no timeout set here. This results in a deadlock between RDP and LSM.” Microsoft has not confirmed this as the cause of the failures.

The theory is that a teardown routine in the RDP server base library blocks indefinitely instead of completing when a session disconnects, leaving dependent session operations unable to progress. Some later practitioner write-ups have gone further, tying the hang to a specific internal feature flag gating the code path. That’s Tier-2 evidence layered on Tier-2 evidence, and it stays labeled that way here.

This distinction matters for one practical reason: if you build your incident response, your monitoring, or your internal postmortem language around “it’s an LSM deadlock” and Microsoft’s eventual RCA names something else entirely, you’ve built process on a guess that happened to be plausible. The architectural point in the next section doesn’t require the mechanism to be right. It requires only that a patch broke availability and that the fix for the availability break also reverses a security fix. Both of those are confirmed regardless of what the eventual RCA says about WDLIB_Close.

The Actual Architecture Problem: When Remediation and Recovery Compete

This is where patch rollback risk stops being a Microsoft incident story and becomes an architecture problem every enterprise running Windows Server RDS has to answer for itself. Once a remediation and the recovery from that remediation’s failure mode start competing for the same decision, there is no automatically “safe” state to fall back to — because the state that restores availability is, by construction, the state that removes the fix.

No row in that table is a resting state you can walk away from. Patched-but-failing is a genuine outage. Rolled-back-but-available carries a genuine 9.8 RCE vulnerability on infrastructure that may be network-reachable over RDP — a real exposure, though vulnerability, confirmed exploitation, and actual internet exposure are three different things worth keeping separate. Security and reliability aren’t actually two separate checkboxes here — they’re the same lever, and this incident is what happens when you’re forced to pull it in one direction with full knowledge of what you’re giving up in the other.

This is also exactly the boundary where this post stops and Patch Visibility Debt picks up, and it’s worth being precise about the difference, because the two failure modes get conflated constantly. Patch Visibility Debt is about whether remediation actually propagated — whether the patch you believe is deployed is the patch that’s actually running. This post assumes propagation succeeded. KB5122871 installed exactly as intended on the host in question. The failure here isn’t a visibility gap; it’s that the remediation itself created an operational failure, and recovering from that failure requires deliberately reversing the remediation. Those are two different architectural problems that happen to rhyme, and treating them as the same one will produce the wrong runbook for both.

The Decision Surface: Who Has Authority to Reverse a Remediation {#the-decision-surface}

The question this incident actually forces isn’t “can we roll back.” Any admin with local access can uninstall a cumulative update. The question is who is authorized to decide that restoring service justifies restoring a CVSS 9.8 exposure, on what evidence, and for how long — and, as the status-channel gap above makes concrete, whether that person even has access to the same information another equally credentialed admin does.

That fourth point isn’t cosmetic. Windows 10 ESU procurement decisions run into the same structural problem from a different angle — the license or channel an organization happens to hold determines which options are even visible to the person making the call, before the technical merits enter the conversation at all. Rollback authority modeled only around “does this person have the right title” without accounting for “does this person have the right access” will produce confident, well-documented decisions made on an incomplete picture of what’s actually available. Verify what the decision-maker can see before verifying what they’re authorized to decide.

The Runbook Payoff: Operationalizing the Patch Rollback Risk Decision

None of the above is useful if it doesn’t operationalize into something a team can actually execute at 2 a.m. The authority model from the decision surface above translates directly into a runbook chain — this is deliberately not a generic “have a rollback plan” checklist, because generic rollback plans are exactly what produce 2 a.m. improvisation when remediation and availability collide.

vSphere lifecycle management runs into the identical structural failure from the hypervisor side: the actual problem was never the patching mechanics, it was the absence of a governance model deciding who owns the exception once one gets made. This runbook chain is that governance model applied to the RDS rollback case specifically — and it’s the difference between a rollback that’s a documented, time-boxed exception and one that quietly becomes the new normal because nobody owned closing it out.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →