The RDS failure is listed as "mitigated". The mitigation is turning the machine off and on

On the Windows release health board, this month's Remote Desktop Services failure carries the label "Mitigated". You read that word and breathe out. Then you open the entry and find the whole mitigation, which fits in one line: "If a virtual machine becomes inaccessible through RDP, customers may be able to temporarily restore connectivity by stopping (deallocating) and restarting the affected virtual machine". That is not a mitigation. It is resuscitation.

The dates, which are half the story

The monthly Microsoft update wave shipped on 8 September. For Windows Server 2022 it is KB5122882, build 20348.5622; on Server 2019 it is KB5122876 and on Server 2025, KB5122871. The session hosts did not fall over that afternoon: the administrators who described it agree that the machine behaves normally for several hours, and things start going wrong after the first sign-out. One of them put it to BleepingComputer like this: "all terminal servers in our environment are failing (sessions dropping, no new connections possible, only solution is a hard reset) within a day".

Microsoft opened the issue on its release health board on 11 September at 11:19 Pacific time. The last update to that same entry is from the 11th at 19:20, and that is the one flipping the status to "Mitigated". Eight hours between opening the case and declaring it mitigated, and there is no patch in between: the entry itself says "we are working to release a resolution in a future Windows update". In that board's vocabulary, "mitigated" describes a way of getting the service back, not a way of keeping it from going. The word reads the same and the two things are nothing alike.

The affected list is longer than the headline

Almost all the coverage talks about Windows Server 2019, 2022 and 2025. That is what shows up in the forums, because those are the versions with the most session farms on them. But the official entry carries its own affected-platforms section, and there the list is a different one:

• Server: Windows Server 2025, 2022, 2019, 2016, 2012 R2 and 2012.
• Client: Windows 11 on 26H1, 25H2, 24H2 and 23H2; Windows 10 on 22H2 and 21H2, plus Enterprise LTSC 2019 and LTSC 2016.

Six server versions and eight client ones. It is worth saying what that list is made of before leaning on it: it is not a tested inventory. On the same page, the unrelated false-Defender-notification issue carries exactly the same fourteen entries, word for word. It is the "everything still in support" boilerplate, not the result of reproducing the failure on each version. It still serves the point that matters, because it is the scope the vendor declares, and it looks nothing like the one people carry in their heads.

And there is a consequence that strikes us as the uncomfortable part, flagged as our reading. The machine that will hang without anybody connecting it to this is the 2012 R2 in the corner: still powered on because an application nobody dares move lives inside it, reached over RDP twice a month, and written about by nobody. With a caveat that has to go in, because it changes the sentence: 2012 and 2012 R2 left extended support on 11 October 2023, so they only received this package if somebody has them enrolled in year three of Extended Security Updates, which runs to 14 October 2026. Which means both answers are bad: if the server did update, it is on the list nobody has read; if it did not, it has gone almost three years without patches and this is the least of its problems.

What Microsoft says it improved

We went to the update's own page, the one for KB5122882, to read what changed. The improvements section has five entries: application compatibility during certificate-authority updates, Morocco's time zone, a 0x139 stop error on a limited number of Windows Server 2022 virtual machines, faster network failover when an adapter is disconnected… and this one, verbatim: "[Remote desktop] this update improves Remote Desktop audio redirection, helping audio from remote sessions play correctly on the local device".

Some have gone further and attached a debugger. The hypothesis going around comes from an administrator on Reddit, picked up afterwards 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" — the Local Session Manager. It is unconfirmed: Microsoft has published no root cause and we have not reproduced it. What is checkable is that the recipe going around for bringing the servers back consists, according to whoever publishes it, in reverting precisely this update's audio redirection improvement. Our conclusion, with that caution attached, is that whatever stopped entire workforces appears to be the component that makes sound come out of the laptop at home. No risk register anywhere has a line that reads "audio redirection".

Why "uninstall the patch" is the worse of the two pieces of advice

It is the advice that turns up the moment you open any thread: pull the update and the sessions come back. It is true that it works. And it is, in this particular case, the worst decision available, for a reason almost nobody is placing next to it. The same cumulative package that took your session host down is the one closing CVE-2026-69525: a use-after-free (CWE-416) in Windows Remote Desktop Services, described as "allows an unauthorized attacker to execute code over a network", scored 9.8 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. No credentials. Nobody clicking anything. Microsoft itself puts it at "Exploitation More Likely" on its exploitability index, and Tenable counts four remote code execution flaws in Remote Desktop Services this month alone.

And it does not travel alone. The same wave carries two flaws that, per Tenable's count, were already being exploited when the patch shipped: CVE-2026-81963, in the Windows Update stack, elevating to SYSTEM through link following, and CVE-2026-85880, in ALPC, reaching SYSTEM by bypassing authentication. That is 964 identifiers in total that day, 104 of them critical, by the same count. So the real decision is not "availability versus security" in the abstract: it is stripping from a session host the fix for an unauthenticated remote code execution in the session service itself, and leaving it that way for however many days Microsoft takes to publish the resolution. If on top of that the server has 3389 hanging out on the internet "just for the salesperson who travels" — and they exist, we still see them — the arithmetic stops being arguable.

What we would do, and what we would not

There is no official remedy. All Microsoft offers today is rebooting the machine and a resolution with no date. What follows are risk decisions, not vendor instructions.

1. Turn off audio redirection through the documented route, on a small ring. A group policy called "Allow audio and video playback redirection" has existed for over a decade, under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection. Disabled, redirection is not used even if the client asks for it. It is the supported lever touching exactly what the update says it changed. Microsoft has not published it as a mitigation for this issue and we are not claiming it resolves it: it is a reasonable hypothesis to try on two hosts and watch for 48 hours, not something you push to the whole domain on a Friday.
2. Do not touch the feature-flag override going around the forums. There is a published recipe that creates a key under HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides to disable a specific feature by its numeric identifier. It may well work. We are not going to recommend it: it is an undocumented switch, tied to one particular build, and the day Microsoft ships the resolution that key will still be there, on a hundred servers, with nobody remembering what it turns off. You swap a known problem for one nobody will know how to diagnose in six months.
3. Get 3389 off the internet, today. Not because of this failure, but because of the other one: if you do end up uninstalling, what you leave open is the unauthenticated 9.8. With a Remote Desktop Gateway or a VPN in front, uninstalling goes from reckless to arguable. Without them, it does not.
4. If you have already uninstalled, put a return date on it and write it down. The risk of a pulled patch is not the day you pull it, it is month fourteen, when nobody remembers that server is still on the August rollup. It is exactly the hole we described a few days ago when explaining why a machine can report itself up to date while running the vulnerable build.

The question that is not about Microsoft

How many people in your company stopped working this week? If the answer is "everyone", the problem was not the update. A session farm concentrates the entire workforce's desktop into one service on one server, and it has been doing so for so long that it has stopped looking like a decision. It is one. It is the same question we asked a few days ago about who powers off the virtual desktops when the layer orchestrating them stops talking to the one underneath: the remote desktop is wonderfully convenient right up to the moment it is not there.

The detail that proves it with a clock is this: the failure takes hours to show up. The machine boots, people sign in, everything is fine, and it starts breaking after the first sign-out. The usual check — apply, reboot, open a test session, it works, move on to the next — would have gone green on all hundred servers. Against a failure that takes half a working day to surface, no amount of diligence helps; only time does. A canary ring of two session hosts patched on Tuesday and the rest on Friday is what separated, this week, whoever lost two servers from whoever lost all of them.

A calendar note from the same page, worth writing down even though it has nothing to do with the failure: Windows Server 2022 reaches end of mainstream support on 13 October 2026, and October's security update will be the last of that phase. After that it moves to extended support, with monthly security updates at no extra cost through 14 October 2031. It changes nothing about this week. It changes a fair bit for anyone with their session farm sitting there who was planning to leave it as is for another two years. And if the way back is neither written down nor rehearsed, there is no plan: we covered that when we wrote about the continuity plan nobody has rehearsed.

Note on sources

Primary sources we read ourselves. The Microsoft Learn status page "Windows Server 2022 known issues and notifications": source of the "Mitigated" status, the timestamps (opened 11 Sep 2026 at 11:19 PT, last updated the same day at 19:20 PT), the verbatim workaround — "If a virtual machine becomes inaccessible through RDP, customers may be able to temporarily restore connectivity by stopping (deallocating) and restarting the affected virtual machine" —, the sentence about a future resolution, the affected-platform list, and the Windows Server 2022 dates (end of mainstream support 13 Oct 2026, October's being the last update of that phase, extended support through 14 Oct 2031). That the platform list matches, word for word, the one on the unrelated Microsoft Defender Antivirus issue on the same page is something we checked ourselves. The support page for KB5122882 (8 Sep 2026, build 20348.5622) supplies the full improvements section, including the quote "[Remote desktop] This update improves Remote Desktop audio redirection, helping audio from remote sessions play correctly on the local device"; as of today its known-issues section lists only the WSUS item. The Windows Server 2012 R2 support dates — end of extended support 11 Oct 2023 and Extended Security Updates year three from 15 Oct 2025 to 14 Oct 2026 — come from Microsoft's lifecycle page.

Vulnerabilities. For CVE-2026-69525 we take from the public CVE record the description ("use after free in Windows Remote Desktop Services allows an unauthorized attacker to execute code over a network"), the 9.8, the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-416 and the publication date. The "Exploitation More Likely" rating comes from Microsoft's exploitability index, and we know it through Tenable's analysis of 8 September 2026, which also supplies the 964 identifiers with 104 critical, the four Remote Desktop Services remote code execution flaws that month, and the two already-exploited bugs: CVE-2026-81963 (Windows Update stack, link following, elevation to SYSTEM) and CVE-2026-85880 (ALPC, authentication bypass, SYSTEM). Other counts published the same day give slightly different totals depending on what they include.

Symptoms and third parties. The timeline, the symptoms and the KBs for Server 2019 (KB5122876) and Server 2025 (KB5122871) come from BleepingComputer, IT-Connect and LazyAdmin. Both administrator quotes come from there: the hard reset within a day, and the hang at RDPSERVERBASE!WDLIB_Close, which is a Reddit post picked up afterwards by BleepingComputer, unconfirmed by Microsoft and not reproduced by us. That the feature-flag recipe under HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides reverts the audio redirection improvement is stated by LazyAdmin, which is the site publishing it; we cite it to advise against it. The "Allow audio and video playback redirection" group policy and its path have been documented by Microsoft since Windows Server 2008 R2, but it is not a published mitigation for this issue.

What is our reading and not the sources': that "mitigated" describes a way of recovering the service rather than a way of keeping it up; that the platform list is boilerplate and still counts as declared scope; the reasoning about the 2012 R2 and its two bad answers; that the cause appears to sit in audio redirection, which is our inference from the order of events and from what the circulating recipe reverts, not a published root cause; that uninstalling is the worse of the two options because it removes the fix for a remote code execution in the very same service; and that a failure window measured in hours invalidates the post-patch check.

Cover photograph: "Computer Laboratory", by Kiruthikapalani, published on Wikimedia Commons under a Creative Commons CC BY-SA 4.0 licence. We cropped it and overlaid our brand text; this version is distributed under the same CC BY-SA 4.0 licence. Everything was checked on 12 September 2026.