If your business runs a Windows server that staff log into remotely — a practice management system, a line-of-business app, a shared drive accessed from home or a second site — this month's Windows update needs a second look, not just a tick. Microsoft's 8 September security update fixed a critical, unauthenticated flaw in Remote Desktop Services (RDS). It also broke RDS on the same servers it was protecting, and the fix for that breakage is a separate update that shipped six days later. Businesses that installed only the first patch got the security fix but may now have staff locked out of remote access; businesses that rolled the whole update back to "fix" that reopened the critical flaw. The safe state needs both pieces installed, and it's worth fifteen minutes confirming that's actually the case on your server.
Why the original flaw matters
The vulnerability is CVE-2026-69525, a Remote Desktop Services remote code execution bug rated 9.8 out of 10 — about as serious as CVSS scoring gets. It's a use-after-free flaw an attacker can trigger over the network with no valid login and no user having to click anything. Successful exploitation hands the attacker code execution on the server itself, not just on one workstation.
That severity matters more for RDS specifically than for most other Windows components, because RDS exists to be reachable. It's the technology behind Remote Desktop and Windows Server terminal services — the thing a bookkeeper, a tradie's office manager or a healthcare practice's admin staff use to log into "the server" from home, from a second location, or from a laptop on the road. A flaw that needs no credentials in a service that's deliberately exposed to remote connections is exactly the combination that turns into a fast-moving incident if it isn't patched.
Then the fix broke the thing it secured
Within days of the 8 September update landing, reports started coming in of RDS failing on patched servers — not immediately, but a few hours after the update installed. Sessions that were already connected became unable to disconnect or log off cleanly. New connection attempts hung for an extended period before timing out. In the worst cases, administrators had to force a hard reboot to restore any remote access at all.
The affected updates were the standard September cumulative updates for Windows Server 2019, Server 2022 and Server 2025 (plus a related issue on Windows 11 24H2/25H2). If your business runs an on-premises server for staff to remote into, and you patched it in the days after 8 September, this is worth checking even if nothing has visibly broken yet — the failures didn't always show up straight away.
Microsoft's second update, and what a "known issue rollback" actually means
Microsoft shipped out-of-band updates on 14 September to correct the regression on Server 2022 and Server 2025, plus a separate fix for Windows 11 24H2/25H2. Alongside those, Microsoft also issued what's called a Known Issue Rollback (KIR) for the same bug.
A KIR isn't the same as uninstalling the update, and that distinction matters:
- Uninstalling the September update removes the RDS breakage — but it also removes the fix for CVE-2026-69525, leaving the server open to that unauthenticated RCE flaw again.
- A Known Issue Rollback reverts only the specific non-security behaviour change that caused RDS to fail, while leaving every security fix from the same update intact.
In plain terms: uninstalling trades one problem for a worse one. The out-of-band update or the KIR gets you both — the critical flaw stays patched, and RDS keeps working.
What to check this week
- Confirm which update is actually installed. Check Windows Update history (or ask whoever manages your server) for the out-of-band fix that followed the 8 September patch — not just the original one.
- Don't assume "no visible problem" means it's fine. The RDS failures in some reported cases only appeared several hours after a reboot, so a server that looked healthy on patch day can still be running the vulnerable, unpatched-for-the-regression combination.
- Never uninstall the whole update as a fix for RDS hanging. It removes protection against a 9.8-severity, no-login-required flaw. Apply the follow-up fix or KIR instead.
- If staff use RDS to work remotely, test an actual login, not just that the server is powered on. A hung or slow-to-connect session is the symptom to watch for.
- Put this on a recurring check, not a one-off. Out-of-band fixes for a regression this size aren't rare, and the businesses that get caught out are usually the ones with no process for confirming a patch actually landed cleanly.
The pattern behind the incident
None of this makes patching optional — the alternative to "occasionally a fix needs a follow-up fix" is running a server with a publicly known, unauthenticated remote code execution hole in it, which is a materially worse position. The lesson is that "we installed the update" and "we confirmed the update did what it was meant to, on every server, including the follow-up" are two different things, and only the second one is actually secure. For a business running its own server rather than a fully cloud-hosted setup, that confirmation step is exactly the kind of ongoing work managed IT services and on-premises server management are meant to catch before it becomes a Monday-morning "nobody can log in" phone call.
If you're not sure whether your server has both pieces of September's update installed, or you want a second set of eyes on your IT security more generally, we're a Perth-based team that's been doing this since 1997 — get in touch and we'll check it for you.
