Executive Summary
Microsoft’s September 2026 security updates – KB5124008, KB5124012, and KB5123099 have been linked to significant issues, underscoring the operational risks associated with security patching. Five known problems emerged after deployment: domain-joined devices losing their secure trust relationship with the domain, USB audio devices failing to start or producing no sound, host folder shares becoming unavailable in Hyper-V-based Linux VMs, Remote Desktop Services no longer responding, and File History ceasing to work. Additionally, the published .msu file for KB5123099 contained a corrupted binary whose hash did not match Microsoft’s documented catalog entry. The same download URL returned different files across attempts, DISM extraction failed, and Windows Update returned error 0x8007065E, so deployment would have failed. Qualys TruRisk Eliminate classified KB5124008, KB5124012, and KB5123099 as Low Reliability, signaling the need for additional validation before production deployment. Patch Reliability helps Remediation teams focus on deeper testing where needed, while allowing high-confidence patches to move faster. For low-reliability patches, organizations can use Qualys-curated mitigation or ring-based deployment to validate patches in test and staging environments before production.
Security teams deploy patches to reduce risk. But not every patch carries the same level of reliability.
A problematic update can introduce new risks, such as failed installations, rollbacks, system instability, service unavailability, or user disruption. This creates a challenging decision for IT and security teams because while it’s essential to remediate vulnerabilities quickly, deploying an unstable patch can lead to operational incidents.
Microsoft’s September 2026 updates, KB5124008, KB5124012, and KB5123099, demonstrate different ways that can happen. One update encountered problems before it could be successfully installed, while the others introduced problems after installation.
Understanding that distinction and identifying patches that require additional scrutiny before deploying in production are becoming increasingly important aspects of effective patch management.
What happened with KB5124008 and KB5124012?
On September 8, 2026, Microsoft released KB5124008 and KB5124012 as the monthly security update for Windows 11 versions 24H2 and 25H2. While the update installed without any issues, problems began to arise in production environments afterward.
Over the next two weeks, Microsoft identified five known issues: domain-joined devices losing their secure trust relationship with Active Directory, USB audio devices failing to start or producing no sound, host folder shares becoming unavailable in Hyper-V-based Linux VMs and WSL, Remote Desktop Services becoming unstable, and File History failing to create or update backups. These issues are largely unrelated to one another. Some issues were resolved within days, one took two weeks to fix, and others remain unresolved.
Domain-Joined Devices Losing Trust with Active Directory
After the recent update, some devices with Credential Guard-protected machine accounts experienced a loss of secure channel connectivity with on-premises Active Directory. As a result, users were unable to sign in with valid domain credentials. They received an error message indicating that the trust relationship between the workstation and the domain had failed. However, signing in with previously cached credentials continued to work without issues. Domain controllers, Active Directory services, and replication were not affected by this problem.
The root cause of the issue is a feature known as Machine Identity Isolation. While KB5124008 does not enable enforcement on its own, it prompts Windows to adhere to pre-existing enforcement settings, whether applied directly or through policy. This feature is only supported on domains operating at the Windows Server 2025 domain functional level or higher. Consequently, any device configured with enforcement that attempts to connect to older domain controllers will lose its trust relationship.
USB Audio Devices Failing to Start or Produce Sound
Microsoft has confirmed that USB audio devices may fail on some Windows systems after installing the September 2026 security updates KB5124008 and KB5124012. The issue affects USB Audio Class 1.0 devices and can cause them to fail to start or produce audio.
In a September 11 update to its release health dashboard, Microsoft stated that after installing the September 8, 2026, Windows security update, “some USB Audio Class 1.0 devices might fail to start or produce audio.”
Affected users have reported Code 10 errors in Device Manager, no audio output at all, and volume controls and sound settings that stop responding. Others have reported that their USB audio speakers fail only when multichannel features are enabled, such as 3D audio or 8-channel modes. Microsoft released out-of-band updates on September 14 that resolve the 8-channel and 3D audio issues; however, other symptoms, including Code 10 errors and no audio output, remain unresolved.
Host Folder Shares Missing in Hyper-V Linux VMs
Applications running Linux virtual machines through the Host Compute Service (HCS) experienced issues with accessing folders shared from the Windows host via the Plan9 protocol. Although the virtual machines started normally, the shared folders were either missing or inaccessible within the guest environment. Applications that rely on these shared folders reported that no Plan9 drive shares were mounted. Microsoft identified Windows Subsystem for Linux (WSL) and Claude Cowork as the affected applications. Standard Hyper-V virtual machines that do not use Plan9 were not impacted.
Remote Desktop Services Becoming Unresponsive
In certain environments, Remote Desktop Services experienced instability following the update. RDP connections would drop after a few minutes, users encountered difficulties signing in, and servers would stall on the message “Please wait for the Remote Desktop Configuration.” Additionally, related tools such as Microsoft Management Console, RDS Licensing Diagnoser, and File Explorer became unresponsive. The Windows Update settings page could also get stuck on a loading indicator. However, Windows 365 and Azure Virtual Desktop were not affected.
File History Backups Silently Failing
This problem is considered the most critical of the five identified issues because it can occur without any obvious warning. On devices impacted by this issue, File History, a built-in feature that creates versioned copies of user files on an external drive or a network location, stopped creating or updating backups.
Users may repeatedly receive prompts to reconnect a backup drive that is already connected and operational. The “Last Backup” timestamp fails to update, and files that should have been backed up show no previous versions available. Additionally, in some instances, the Event Viewer logs indicate crashes involving FileHistory.exe and KERNELBASE.dll. While the storage device remains intact, the backup process is not completing. Consequently, users might mistakenly believe their data is secure when, in reality, there have been no recent backups available.
What Happened with KB5123099?
Microsoft released KB5123099 on September 8, 2026, as a cumulative security update for Windows Server 2016 and Windows 10 version 1607. Soon after its release, administrators began reporting issues with downloads of the update package. Microsoft’s published .msu file contained a corrupted binary. The file hash did not match the documented catalog entry.
- Expected SHA1: 28560cfadc1030ab60e40ddadc3683165f40bc58
- Actual SHA1 received: 745eb9039f8a8cb857090ce23eadbb06bfc92c3d
- Expected SHA256: 90b81aeccbf44e626d57fe86446e68ecb8b1fc44b1bcce365e7b1ed26a050cea
- Actual SHA256 received: e4a9d660f56139ec89496cf68e710c2cc52293eb335a9dd6e74563f20650b6af
The same download URL returned different files across attempts and environments. The tools could not open the package. DISM extraction failed. Windows Update returned error 0x8007065E. Deployment would have failed.
Microsoft re-published a corrected version by September 10, 2026.
For an administrator preparing a broad rollout, the challenge is clear: how can you determine if a patch is ready for production?
What Do These Case Highlights Reveal?
Together, these cases underscore a significant challenge with patching: just because a patch has been successfully downloaded or installed does not guarantee that it is ready for widespread deployment in production environments.
For security and IT teams, these incidents illustrate a common issue with patching: while a security update may be needed to mitigate cyber risks, deploying it broadly without understanding its patch reliability can introduce new business risks.
This scenario is exactly why the AI-Powered Patch Reliability Scoring in Qualys TruRisk Eliminate is designed: helping teams make an informed decision before patch deployment, not after helpdesk tickets start piling up.
What Low Reliability Means for These Updates
Qualys AI-Powered Patch Reliability Scoring in TruRisk Eliminate™ helps teams assess patch reliability before deployment. It provides AI-driven insights into patch stability and known post-deployment issues, giving teams additional context for deciding whether a patch can move quickly into production or requires further validation.
And in the case of Microsoft’s September updates, that warning signal is already visible.
Qualys TruRisk Eliminate classified KB5124008, KB5124012, and KB5123099 as Low Reliability, providing teams with an early signal to exercise additional caution before deployment.
The significance is not that Patch Reliability predicted the specific USB audio failure. Rather, the Low Reliability classification indicates that these updates should not be deployed blindly, but should be tested further and deployed in phases using a ring-based approach.
How We Calculate Patch Reliability
Qualys AI-Powered Patch Reliability Scoring predicts whether a patch will deploy cleanly in your environment before you deploy it.
It combines two signals: global public sentiment, where LLMs continuously analyze large-scale feedback from across the internet, including technical discussions, release-related feedback, and other real-world indicators that emerge after a patch ships, and Qualys telemetry on patch rollback rates and vulnerability reopen rates. These two signals are combined into one reliability score.
Our Recommendation: For a Low Reliability Patch, Use Ring-Based Phased Deployment Strategy Or Mitigate It
For low-reliability patches such as KB5124008, KB5124012, and KB5123099 organizations should avoid deploying them directly without validation.
The Patch Management capability in TruRisk Eliminate supports ring-based deployment, allowing teams to progressively move validated patches through Test → Staging → Production environments.
For these updates, we recommend beginning with a low-risk environment and progressing to a critical environment based on criteria such as successful patch deployments, system health, and application behavior, and only then advancing the same patches to staging and ultimately to production.
For example, now teams can deploy high-reliability Microsoft security patches in production shortly after Patch Tuesday. For low-reliability patches, they can validate them through various stages, then use those same tested patches in subsequent staging and production jobs.
Check Out Patch Reliability And Its Evidence For KB5124008, KB5124012, KB5123099
You can assess patch reliability directly from the TruRisk Eliminate application. Navigate to Patches > Windows and use the following QQL query to filter the relevant Windows security updates:
For the security update you want to assess, click Patch Reliability: Low. This opens the Patch Reliability Assessment window, where the AI Assessment for a Low Reliability patch appears as Negative.
The assessment also shows the known issues reported for the patch. Click Detailed Report to review the key issues and the official sources evaluated by Qualys, along with links to relevant community discussions.
For more information on viewing Patch Reliability assessments, see the Qualys Patch Management documentation.
Conclusion
Patch management isn’t just about speed anymore. It’s about predictability. With the AI-powered Patch Reliability Scoring, Qualys helps customers anticipate patch instability before it becomes an outage, prioritize testing effort where it’s most needed, deploy faster when confidence is high, and stay protected using mitigations when patch risk is high.
As exploitation timelines continue to shrink, teams cannot afford to spend as much time validating every patch. By accelerating the deployment of high-reliability patches and focusing deeper testing on patches that need it, organizations can shorten remediation timelines and help reduce MTTR without compromising operational stability.
Less guessing. Fewer rollbacks. Better security outcomes.
Know which patches are ready to move and which need more validation. Explore Patch Reliability in Qualys TruRisk Eliminate.
Contributors
- Ambika Singh, Product Evangelist, Qualys
