September 2026 Patch Tuesday: the RDS/RDP regression and the case for N-1 patching

1. What the September CU fixed

This round was, by a margin, the largest Patch Tuesday to date. The exact count depends on whether you count only Microsoft's own CVEs or also the third-party ones that ride along in the Microsoft catalogue, but the most commonly cited figure lands around 974 Microsoft CVEs in a single round.

Two of them were already being actively exploited at the moment of patching: CVE-2026-81963 in the Windows Update stack itself, and CVE-2026-85880 in Windows ALPC. For anyone running Remote Desktop Services on Failover Clusters, there was also a critical remote-code-execution vulnerability, CVE-2026-69525, with a CVSS score of 9.8, in exactly the component that would cause the regression a few days later.

That is not a coincidence. It is exactly why a patch round is never only about whether you install the newest cumulative update, but also about which component that update touches and how critical that component is in your environment.

2. The RDS/RDP regression: what broke and why

Within nine days of Patch Tuesday, a confirmed, large regression showed up in three cumulative updates: KB5122876 (Server 2019), KB5122882 (Server 2022) and KB5122871 (Server 2025). RDS session hosts lock up a few hours after a reboot. RDP connections hang on "Connecting…" without ever building a session. And it does not stop at RDP: MMC, File Explorer, the RDS Licensing Diagnoser and even the Windows Update page itself hang along with it.

The cause sits in a change to RDP's audio-redirection code path, the part that forwards sound from the session host to the client. A change there, most likely made to support one of the security fixes in this round, blocks the rest of the session under the right conditions. For Failover Cluster nodes carrying RDS roles, or simply managed over RDP, that is immediately operational: a session host that locks up a few hours after boot is not something you notice during the patch round itself, but exactly when the operations team is in the middle of it.

A smaller change in the same round is worth calling out separately: WSUS has temporarily stopped showing synchronisation error detail. That is not a bug, but a deliberate measure tied to CVE-2025-59287. It feels the same as a regression because it removes diagnostic information right when you need it most, but the behaviour is intentional.

3. How Microsoft responded: a Known Issue Rollback, then a real fix

Microsoft's response came in two steps. First a Known Issue Rollback: a group policy that reverts only the behaviour of the regression, not the underlying security fix. The cumulative update stays installed, every CVE in this round stays patched, and only the changed piece of audio-redirection code gets switched off through policy. The rollback IDs are 260911_18471 for Server 2022 and 260911_18474 for Server 2019.

On 14 September, nine days after Patch Tuesday, a real out-of-band fix followed: KB5129237, for now Server 2022 only. For 2019 and 2025, the Known Issue Rollback remains the way to go until Microsoft ships a specific hotfix for those too.

4. Why N-1 dodged this regression automatically

This is precisely the scenario an N-1 patch policy exists for. An environment that deliberately installed the August CU on 6 September, instead of jumping straight to the newest September round, automatically ends up outside the reach of this RDS regression. The nodes were not specifically protected against this one bug; they were protected against any regression that surfaces in the first weeks after a Patch Tuesday, and that happens more than once a year.

That is not luck, it is exactly the point of the design. One month of grace between a cumulative update shipping and that update landing on production nodes is, in our own convention, not a deviation. Two months is: at that point you fall so far behind that you become a risk yourself instead of avoiding one.

5. Caveat 1: N-1 also costs you the zero-day window

N-1 as a blind rule has a price, and that price is visible in this exact round: the same CU that carried the RDS regression also patched two vulnerabilities that were already being actively exploited at the moment of patching. A month of delay on everything is not free security. It trades a visible, measurable regression for an invisibly extended window in which an actively exploited vulnerability stays open on production nodes.

That is why we keep N-1 as the default, but with an explicit exception: the moment Microsoft or your national CERT marks a CVE as actively exploited, we pull the fix for that specific vulnerability forward, outside the monthly cycle, through the standalone security-only update or a KB-specific action, rather than waiting blindly for the next round.

6. Caveat 2: a KIR is faster than waiting a full month

A Known Issue Rollback is usually available within about nine days of Patch Tuesday, well before the next monthly round comes into view. Once that KIR is published, you can still apply the current month's CU, with the KIR group policy alongside it. You get the security fixes without the regression, without the full month of N-1 delay.

That deserves a fixed spot in the patch-round procedure, as the first check before deciding "we wait until next month." Has a Known Issue Rollback already been published for a known problem in the previous round? If so, applying it with the KIR is usually the better choice over waiting an entire extra month.

7. The patch-round procedure I would keep

Summed up, that comes down to three rules that complement each other, rather than one rule that makes the other two redundant.

1. N-1 as the default. New cumulative updates go to a non-production environment or a canary node first, for a month, before they reach the rest of the cluster. That catches most regressions before they hit production.
2. An escape hatch for actively exploited CVEs. The moment Microsoft or your national CERT marks a vulnerability as actively exploited, that specific fix gets pulled forward, outside the monthly cycle. N-1 applies to the regular round, not to a vulnerability already being used today.
3. A KIR check before accepting the wait. Before accepting a full month of delay because of a known regression, check whether Microsoft has already published a Known Issue Rollback. If so, patch the current round anyway, with the KIR in place, instead of waiting the whole month.

None of these three rules is new on its own. The combination is what turns a patch round from "install and hope" into a procedure that holds up, even when the largest Patch Tuesday to date also happens to be the messiest.