September 2026 Windows updates: three confirmed known issues, none of them fixed yet

Compiled 2026-09-11 · source: Microsoft Windows release health, read 2026-09-11 18:42 UTC

The September 2026 Windows security updates fix three actively exploited vulnerabilities. They also introduce two confirmed regressions that Microsoft has no fix for, one of which can take down Remote Desktop Services across effectively the entire supported Windows estate. Both of those sentences are true at once, which is why "hold the update" is the wrong reflex and "push it everywhere tonight" is the wrong reflex. This page is the second half of the picture our monthly patch brief gives you: that one says what to patch, this one says what to watch when you do.

---

🔴 Confirmed, no fix: Remote Desktop Services can stop responding

Microsoft opened this one on 2026-09-11 at 11:19 PT and marked it Confirmed the same hour.

What happens. After installing the September 2026 security update, Microsoft says some organisations "might experience issues with Remote Desktop Services (RDS)." In affected environments RDS becomes unstable, with:

• RDP connections failing after several minutes
• sign-in issues
• servers hanging at "Please wait for the Remote Desktop Configuration"
• Microsoft Management Console (MMC), the RDS Licensing Diagnoser and File Explorer also becoming unresponsive
• the Windows Update page itself hanging on a permanent loading indicator

That last symptom deserves its own line. If the Windows Update page will not load, the first tool an administrator reaches for to check what was installed is the tool that stops working — so the update state can be hard to confirm on exactly the hosts where you most need to confirm it.

Who is affected. This is not a narrow list. Microsoft names 13 platforms:

Fix status: none. There is no resolved KB on any of those 13 rows. Microsoft states it is "working to release a resolution in a future Windows update." The only interim path the company offers is to contact Microsoft Support for Business for a workaround — which is, in practice, Microsoft saying there is no published workaround.

---

🔴 Confirmed, no fix: host folder shares break in Hyper-V Linux VMs (this breaks WSL)

Opened 2026-09-11 at 02:22 PT, also Confirmed, also no fix.

After installing KB5124008, applications using HCS-managed virtual machines can fail when sharing host folders with Linux guests over Plan9. The virtual machines start normally — which is what makes this one slippery — but folders shared from the Windows host do not appear, or cannot be accessed, inside the guest. Affected applications may report that no Plan9 drive shares were mounted.

Microsoft explicitly names Windows Subsystem for Linux (WSL) as an affected application. Standard Hyper-V virtual machines that do not use the Plan9 feature are unaffected.

Affected: Windows 11 26H1, 25H2, 24H2 and 23H2. No server platforms. Fix status: none — Microsoft says it is "working on a resolution."

Why this one gets misdiagnosed. The failure presents as "my tooling can't see my files", not as a patch problem. A developer workstation that installed KB5124008 overnight looks healthy: the VM boots, the terminal opens, and only the shared path is missing. Expect this to arrive at your service desk as a broken dev environment, and expect nobody to connect it to Tuesday's update unless somebody tells them to.

---

🟡 Still open from August: false "Defender is turned off" notifications

Not a September-update issue, but still Confirmed and still unresolved, so it is worth knowing about before you chase it.

After recent Microsoft Defender Antivirus updates, devices may show notifications claiming "Microsoft Defender Antivirus is turned off" while Defender is in fact running normally and all settings show it as active. The notifications can appear at start-up and intermittently afterwards, and persist even when notification settings are turned off. Microsoft has no originating KB for this one — it tracks to Defender platform updates rather than a Windows cumulative update — and says a resolution will come in a future Defender Antivirus update.

Affected across the full client and server range. If your monitoring alerts on Defender state from notification text rather than from Defender's own reported status, this will generate false alarms.

---

✅ What the September update fixed — the case against blanket deferral

It is easy to read the above and conclude the September update should be held estate-wide. Two things argue against that.

First, the September updates close three actively exploited vulnerabilities — see the monthly brief. Deferral is not a neutral act; it is a decision to stay exposed to bugs that are being used right now.

Second, KB5124008 is itself the fix for three August regressions:

• Microsoft Teams and new Outlook failing to launch on ARM devices (from the August update KB5121003) — resolved by KB5124008
• Mouse customisation reset on non-English Windows (from KB5120998) — resolved by KB5124008
• Desktop background settings lost or reverting to solid black (from KB5120998) — resolved by KB5124008

Holding September to avoid the RDS issue keeps those three in place on machines that have them.

---

🔍 What is not on Microsoft's known-issues list — and why that may not mean what it looks like

There has been public discussion — including a detailed Microsoft Q&A thread opened 2026-09-09 — reporting that KB5124008 breaks the machine secure channel / domain trust relationship on Windows 11 25H2 (build 26200.9445) against Windows Server 2019 domain controllers.

We checked Microsoft's list, and as of 2026-09-11 18:42 UTC there is no such entry. No secure-channel, Netlogon, domain-trust or domain-logon issue appears on the Windows 11 25H2 known-issues page — not as Confirmed, not as Investigating. So claims that "Microsoft has acknowledged this and a fix is in progress" are not supported by Microsoft's own record.

But absence from a known-issues list is not the same as "not real", and here there is a second explanation worth taking seriously: this may be documented behaviour rather than an unacknowledged bug.

The reported symptoms map closely onto Microsoft's own documentation for Credential Guard protected machine accounts / machine identity isolation, controlled by HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation and by the Group Policy setting Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security → Machine Identity Isolation Configuration. Its states are:

Three things in Microsoft's documentation line up with what is being reported:

1. Cached credentials masking the failure. Microsoft: "If local cached logon is enabled when this setting is disabled, local logon will still work while the cache is fresh, but domain authentication will break." That is precisely the reported pattern — users keep working, machine authentication is already gone.
2. Repair cmdlets not being enough. Reports say Reset-ComputerMachinePassword and Test-ComputerSecureChannel -Repair do not fix it and a full domain leave/rejoin is required. Microsoft documents exactly that consequence for moving off enforcement mode: "the device must be unjoined and rejoined to the domain, as it's unable to authenticate otherwise."
3. A documented failure mode with the same outcome. Microsoft: "if Credential Guard fails to start after a device reboot, it results in the inability to complete domain authentication, potentially requiring intervention from a local administrator account to recover."

⚠️ What we have NOT verified, and will not assert: we have no evidence that KB5124008 enables, re-enables or changes the default of machine identity isolation. That is the obvious hypothesis given the timing, and it is only a hypothesis. Microsoft's documentation carries a standing note that the feature was temporarily disabled from the April security update (KB5055523) over a Kerberos machine-password-rotation problem and "remains disabled until a permanent fix is available." Whether that changed in September, and whether Server 2019 domain controllers are supported on this path at all, are open questions we cannot answer from published sources. Treat the mapping above as a strong lead for your own diagnosis, not as a root cause.

🔴 About the registry "workaround" circulating publicly

A mitigation being shared publicly sets MachineIdentityIsolation from 2 to 0 and then repairs the secure channel. Understand what that is before you run it: it turns off a security hardening control — it takes your machine account password back out of Credential Guard's protected execution environment and returns it to the registry, which is the exact exposure the feature exists to close (machine account secrets "can be easily extracted from the registry"). It is not a hotfix; it is a decision to stop using a protection.

It also has a documented cost that a one-line registry tip tends to omit: per Microsoft, moving from enforcement mode to Disabled leaves the device unable to authenticate until it is unjoined and rejoined to the domain, and only the local administrator account can perform that unjoin and rejoin. If you have no working local administrator credential on an affected machine, find that out before you change the value, not after.

We are not recommending that change. If machine identity isolation is in play in your environment, the lower-risk direction is audit mode (1), which Microsoft documents as falling back to the LSA copy when Credential Guard authentication fails — but that is still a hardening reduction, it still needs testing, and if the policy is currently in enforcement mode the unjoin/rejoin consequence may still apply. Check your own Group Policy state first: this setting may simply not be configured in your estate, in which case none of this is your problem.

What to actually do

If you run RDS, terminal servers or VDI: hold the September update on those roles specifically and stage it through a ring first. This is the one place the risk of patching outweighs the risk of waiting a short while, because there is no workaround and no fix date.

If you run developer workstations on WSL: expect host-folder sharing to break on Windows 11 after KB5124008. Either hold on those machines or warn the people using them, so a broken mount is not debugged as a WSL problem for a day and a half.

Everywhere else: patch on your normal cycle. Three exploited CVEs is the larger risk, and the September update also cleans up three August regressions.

If you are seeing domain logon failures: triage before you conclude anything.

1. Run Test-ComputerSecureChannel. If it returns True and your symptoms involve RDP or terminal servers, you are most likely looking at the confirmed RDS issue above, not a secure-channel problem — Microsoft's RDS entry explicitly lists "sign-in issues" among its symptoms, and conflating the two will send you down the wrong path.
2. If it returns False, corroborate with nltest /sc_query:<domain> and check the domain controller Security log for Event 4625 against the computer account (HOST$).
3. Then check whether machine identity isolation is configured in your estate — Group Policy under Device Guard, or the MachineIdentityIsolation value — before treating this as an unexplained patch bug. If it is set to enforcement mode, read the section above carefully, including the unjoin/rejoin consequence, before changing anything.
4. Do not expect a Microsoft fix ticket to follow. There is no known-issue entry, no incident ID and no published timeline. If this is affecting you, open a support case — that is the channel that exists, and it is also how an unacknowledged issue becomes an acknowledged one.

However you decide: decide per workload, not per estate. The pattern in every one of these issues is that they hit specific roles — RDS hosts, Plan9/WSL users — and leave the rest of the fleet alone.

---

Compiled from Microsoft's Windows release health documentation, read 2026-09-11 at 18:42 UTC. Known-issue status, affected platforms and fix availability change without notice — verify against Microsoft's current page before acting on anything here. Prepared for practitioners. Not affiliated with, or endorsed by, Microsoft.

Sources

All Microsoft documentation below was read directly on 2026-09-11.

• Windows 11, version 25H2 known issues and notifications — Microsoft. The primary source for every confirmed issue on this page, and for the verified absence of any secure-channel entry. Page last updated 2026-09-11 18:42 UTC. Per-platform records for other Windows versions are on their own release-health pages in the same section of Microsoft Learn.
• Credential Guard protected machine accounts in Windows Server 2025 — Microsoft. Source for the machine identity isolation states (Disabled / audit / enforcement), the Group Policy path, the cached-logon and unjoin-rejoin consequences quoted above, and the standing note that the feature was temporarily disabled from the April security update (KB5055523) pending a fix for a Kerberos machine-password-rotation issue.
• KB5124008 (26200.9445) breaks machine secure channel / domain trust — Microsoft Q&A — ⚠️ user-submitted community content, not a Microsoft advisory. Cited only as evidence that the reports exist and for the diagnostic commands practitioners are using. No Microsoft representative had responded on the thread at the time of writing. We have not independently reproduced any of it.

Compiled by patchtriage.com. We verify against vendor primary sources and say so when we cannot.