The September cumulative updates (KB5122871 on Server 2025, KB5122882 on 2022, KB5122876 on 2019) are quietly taking down Remote Desktop Services, and the part that makes it dangerous is when it happens. The servers patch clean, boot clean, and serve RDP sessions like nothing is wrong for a few hours. Then the failures start: inbound connections hang at the 'Connecting' screen, existing users find they can't log off, and the only reliable way back is a hard reset. Admins who rolled the updates back got their session hosts working again, sure, but rolling back a cumulative update is also how you undo the security fixes you just spent a Patch Tuesday cycle pushing. On a month where Microsoft shipped a record ~966 fixes and two actively exploited zero-days, that's a real bind, not a footnote.

The mechanism is what separates this from your usual patch-day gremlin, and it's ugly. Practitioners who actually went after the hang found it in the RDP server base library: when a session tears down, a code path calls RtlWaitOnAddress with no timeout, so the thread just waits. Because Local Session Manager funnels all session state changes through a single serialization point, that one stuck thread wedges every later logoff, session query, and broker connection behind it. The giveaway in the logs is a TerminalServices RemoteConnectionManager timeout (Event 20498) and a TermService sitting in STOP_PENDING instead of a clean crash. In other words, it's not a display driver melting or a broken service stopping; it's a synchronization defect in the teardown path that only reveals itself under the specific load of real people logging out. The failure being deferred by hours is why it stings: you've already cleared your patch window and declared the environment stable before it wakes up. And because the trigger is ordinary logoff churn rather than a spike you'd have on your radar, a quiet afternoon of users signing off can be exactly when your session fleet starts locking up, with no anomaly in your metrics to explain it.

Source article image
Source image 1

So the practical question for anyone running RDS session-host collections is what you do about a deferred, load-triggered regression with no clean in-place fix. You can hold the bad build and eat the downtime risk on your most critical servers, or you can roll back and accept a temporary security exposure on exactly the patch that was this month's big story. Neither option is comfortable, and the clock on the exposure is whatever it takes Microsoft to acknowledge a bug it hasn't publicly confirmed yet. If you run RDS and you're still patching this cycle's update, I'd stage one session host, watch it through a real logoff cycle, and have the DISM rollback path rehearsed before the fleet's on it. Where would you put the tradeoff if your RDP farm is the load-bearing piece of a 24/7 operation, and the fix for the bug is the thing that un-patches you?

Sources

Comments

Post a Comment

Popular posts from this blog

AI Is Starting to Feel Less Like a Gadget and More Like Infrastructure

Image
Modern AI doesn't replace infrastructure — it runs on top of it. (Photo: Unsplash) For a while, AI coverage had the energy of a mall demo kiosk: very shiny, slightly chaotic, and usually one prompt away from embarrassment. Lately, though, the more interesting story is less about flashy demos and more about infrastructure. A useful CNBC piece argued that AI is not simply going to vaporize enterprise software overnight, and that sounds about right. In real companies, software does not disappear just because a model can summarize a meeting or write a decent SQL query. What actually happens is messier and more practical: AI starts sneaking into the plumbing. It shows up in search, support workflows, procurement tools, analytics dashboards, and data pipelines. The real winners may not be the loudest chatbot wrappers, but the vendors that make enterprise systems easier to operate, easier to query, and slightly less soul-crushing for the humans trapped inside them. That is less cinematic ...
Read more

When Two AI Bots Finally Learned to Talk in Discord

I spent part of the day doing something that sounds like the setup for a bad joke: getting two local AI assistants to talk to each other in the same Discord channel. Not through a web UI. Not by bouncing prompts manually between windows like a human message queue. In the actual shared channel, where both could see the conversation and react to each other. The funny part is that the problem was not intelligence. It was manners. Both bots were defensive by default around bot-authored messages, which is the sensible setting if you do not want your infrastructure turning into a recursive support group. The downside is obvious: if both assistants treat other bots as suspicious background noise, they will never coordinate on anything more useful than silence. The fix was to make both sides accept bot-authored messages only when they were explicitly mentioned. That detail matters more than it sounds. Blanket bot acceptance is how you end up with two enthusiastic systems discovering each oth...
Read more

A CISA Contractor's GitHub Repo Held 844 MB of Secrets — and No One Closed the Door

Image
There is something almost poetic about the US government's premier cybersecurity agency — the one whose job is literally to plug holes in critical infrastructure — getting outsmarted by a contractor who treated a public GitHub repository like a digital junk drawer. The "Private-CISA" repo, created November 13, 2025, sat publicly for six months containing 844 megabytes of plaintext passwords, AWS GovCloud administrative credentials, Kubernetes manifests, ArgoCD application files, Terraform infrastructure code, CI/CD build logs, and internal deployment documentation. Guillaume Valadon at GitGuardian flagged it on May 14 after his automated scanning picked up the exposure. The commit history told the whole story in plain sight: the account owner had explicitly disabled GitHub's default secret-scanning protections, pushed plaintext credentials stored in CSV files, committed full backup archives into git history, and used easily guessed passwords like "platform-name-2...
Read more