Rolling back the update that broke RDS also removes September's 9.8-rated RDS fix

Uninstalling a cumulative update does not remove one fix. It moves the host's build number back below the line where that fix landed. For Server 2019 the line is 17763.9245, for Server 2022 it is 20348.5622, and for Server 2025 it is 26100.33438 ^[12]. Those builds carry the patch for CVE-2026-69525, a use-after-free remote code execution bug in Windows RDS scored 9.8, unauthenticated and needing no user interaction ^[10]. Pull KB5122876, KB5122882 or KB5122871 to get Remote Desktop working again, and the fix goes with the package ^[13].

The other documented path leaves the patch installed. Microsoft's release-health entry for Server 2025 lists stopping and restarting the affected VM as the workaround, and marks the issue Mitigated as of September 11 ^[5]. The same entry says Microsoft is "working to release a resolution in a future Windows update" ^[6]. Three days after the updates shipped, the public record offered a reboot ^[18]. Per the dev.to write-up, the failure typically fires on the first wave of user logouts ^[3].

That restart is the better of the two recovery paths because it keeps the host above the patched build ^[20], and by Microsoft's own wording it is not a fix ^[6].

A third path is reported to exist. A Known Issue Rollback is available through Group Policy, documented only inside Microsoft's M365-admin-only Message Center, and the dev.to post reports it with that provenance attached ^[8]. Microsoft's public release-health page did not document a Group Policy object or a KIR package ^[7]. The post's reading is that an administrator with M365 admin-center access and one without it are looking at different mitigation options for the same RDS failure while carrying the same exposure ^[9]. It puts the Entra ID exploitation-status reversal alongside it as the same asymmetry running the other way, a status field changing under an admin with no independent way to check which version is current ^[19].

The post argues that the subject is what happens when recovery and remediation compete for one decision, and who is positioned to make that call ^[16]. On this evidence the competition is real for these three KBs: the CVE's affected range runs from Server 2012 through Server 2025 plus several client versions ^[11], and unauthenticated with no user interaction means the remaining precondition during a rollback window is whether anything can reach the RDS listener ^[10]. The post does not present data on how many organisations have assigned that decision to a named owner. The authority gap is its argument.

Microsoft's documentation establishes the failure and the current mitigation, and does not say why RDS fails ^[14]. The theory in circulation comes from one administrator's kernel-level debugging, reported on Reddit and covered by BleepingComputer, and Microsoft has not confirmed it as root cause ^[15]. The post says its architectural argument does not depend on that theory holding ^[17]. For the restart-or-rollback decision it does not need to hold, because the build numbers determine what the host is exposed to ^[12].