Microsoft has confirmed that its September 2026 security updates are causing Remote Desktop Services (RDS) failures on Windows Server systems. Administrators who deployed this month's cumulative updates are reporting broken RDP sessions, failed connections to session hosts, and in some environments complete loss of remote administrative access to affected servers. For organizations that depend on RDS for remote administration, virtual desktop delivery, or application publishing, this is an availability incident with real operational and security consequences — stranded admins, interrupted helpdesk workflows, and pressure to bypass normal patch controls.
This is not an exploitable vulnerability — it is a patch regression. But from a defender's perspective, the response discipline is the same: you need to know which servers are affected, detect the failure mode at scale, restore service safely, and avoid creating a security gap while you do it. The worst outcome here is not the outage itself — it is an organization reacting by disabling security updates entirely, leaving servers exposed to whatever the September update was patching, or standing up insecure workarounds (flat RDP exposure without NLA, third-party remote access tools deployed ad hoc) that persist long after the fix ships.
This guide covers how to identify affected systems, detect the failure pattern in your telemetry, restore RDS functionality, and remediate without trading availability for security.
Technical Analysis
What Happened
According to Microsoft's confirmation reported by BleepingComputer, systems that installed the September 2026 security updates for Windows Server began experiencing Remote Desktop Services failures shortly after deployment. The failure manifests as an inability to establish RDP sessions to affected servers — connections may be refused, hang at the authentication or session negotiation stage, or the underlying Remote Desktop Services components may fail to service incoming connections.
Affected Products and Platforms
- Windows Server systems that received the September 2026 cumulative security updates (exact KB numbers per supported Server version are listed in Microsoft's Windows release health dashboard — verify against your installed build rather than assuming)
- Both traditional Remote Desktop Services role deployments (Session Host, Connection Broker, RD Gateway) and servers simply using RDP for remote administration are potentially impacted
- Virtual desktop infrastructure (VDI) and published-application environments built on RDS are at highest operational risk due to session density
Failure Mechanics (Defender's View)
Patch regressions in the RDS stack typically surface in one of three observable ways:
- Service-level failure — the Remote Desktop Services service (TermService) or its dependencies fail to start, crash, or terminate unexpectedly after the update and a reboot. This leaves the RDP listener (TCP 3389) down entirely.
- Listener/protocol failure — the service runs but the RDP listener fails to bind or negotiate, often logged in the TerminalServices-RemoteConnectionManager and TerminalServices-LocalSessionManager operational logs.
- Authentication/session negotiation failure — connections reach the server but fail during credential validation or session setup, producing a surge of logon failures (Logon Type 10) or client-side protocol errors.
Exploitation Status
There is no CVE and no exploitation vector associated with this issue — it is a defective update, not a security flaw. No CISA KEV entry applies. The security risk is second-order: organizations that respond by pausing all updates indefinitely, exposing RDP to the internet as a fallback access path, or weakening NLA/firewall controls during firefighting create genuine attack surface.
Detection & Response
The detection goal here is not catching an attacker — it is rapidly scoping the blast radius of the regression and confirming recovery. The following detections identify the failure signatures: RDS service crashes, RDP logon failure surges post-patch, and recently installed September 2026 updates.
---
title: Remote Desktop Services Unexpected Termination
description: Detects the Remote Desktop Services (TermService) service terminating unexpectedly, a hallmark of the September 2026 Windows Server update regression. Correlates with Service Control Manager crash events in the System log.
references:
- https://www.bleepingcomputer.com/news/microsoft/microsoft-september-updates-cause-rds-failures-on-windows-server/
author: Security Arsenal
date: 2026/09/12
status: experimental
tags:
- attack.impact
logsource:
product: windows
service: system
detection:
selection:
Provider_Name: 'Service Control Manager'
Message|contains:
- 'Remote Desktop Services'
- 'terminated unexpectedly'
falsepositives:
- Occasional service crashes unrelated to patching; investigate when clustered post-update
level: high
---
title: Surge of Failed Remote Interactive Logons Post-Patch
description: Detects failed remote interactive (RDP) logons, which spike when the September 2026 update breaks session negotiation. Deploy as a baseline-deviation alert rather than a raw threshold.
references:
- https://www.bleepingcomputer.com/news/microsoft/microsoft-september-updates-cause-rds-failures-on-windows-server/
author: Security Arsenal
date: 2026/09/12
status: experimental
tags:
- attack.impact
logsource:
product: windows
service: security
detection:
selection:
LogonType: 10
Keywords|contains: 'Audit Failure'
falsepositives:
- Brute-force attempts and password-spray activity also produce this signature; correlate with recent patch installation before attributing to the regression
level: medium
// Scope: Identify servers with a post-patch surge in failed RDP logons (LogonType 10)
// Compare failure counts in the 24h after patch installation vs. the prior 7-day baseline
let patchWindow = 1d;
let baselineWindow = 7d;
let patchedHosts =
DeviceEvents
| where TimeGenerated > ago(patchWindow + baselineWindow)
| where ActionType == "WindowsUpdateInstalled" or AdditionalFields has "KB"
| summarize LastPatchTime = max(TimeGenerated) by DeviceName;
let failures =
SecurityEvent
| where TimeGenerated > ago(patchWindow + baselineWindow)
| where EventID == 4625 and LogonType == 10
| summarize FailedLogons = count(), FirstFailure = min(TimeGenerated), LastFailure = max(TimeGenerated) by Computer;
patchedHosts
| join kind=inner failures on $left.DeviceName == $right.Computer
| where LastFailure > LastPatchTime
| project DeviceName, LastPatchTime, FailedLogons, FirstFailure, LastFailure
| order by FailedLogons desc;
// Scope: Find September 2026 cumulative updates installed across the fleet via Defender TVM inventory
DeviceTvmSoftwareInventory
| where TimeGenerated > ago(2d)
| where SoftwareName has "Windows Server"
| summarize by DeviceName, SoftwareName, SoftwareVersion
| order by DeviceName asc;
-- Artifact: Hunt for September 2026 updates and RDS service health across Windows Server endpoints
-- Identifies recently installed hotfixes (candidate regression) and the current state of TermService
-- Installed hotfixes with install dates in September 2026
SELECT HotFixID, Description, InstalledOn, InstalledBy
FROM wmi(query="SELECT HotFixID, Description, InstalledOn, InstalledBy FROM Win32_QuickFixEngineering",
namespace="ROOT\\CIMV2")
WHERE InstalledOn =~ "2026-09" OR InstalledOn =~ "9/.*2026"
-- Current state and start mode of the Remote Desktop Services service
SELECT Name, DisplayName, State, StartMode, ProcessId, PathName
FROM wmi(query="SELECT Name, DisplayName, State, StartMode, ProcessId, PathName FROM Win32_Service WHERE Name = 'TermService'",
namespace="ROOT\\CIMV2")
-- Confirm whether the RDP listener is actually bound on TCP 3389
SELECT Pid, Name, Family, Type, Status, Laddr, Lport
FROM netstat()
WHERE Lport = 3389
#Requires -RunAsAdministrator
# Security Arsenal — September 2026 RDS Regression Triage & Recovery Script
# 1) Identify recently installed September 2026 updates
# 2) Verify TermService health and RDP listener state
# 3) Optionally uninstall the suspect KB (requires -RemoveKB with explicit KB number from Microsoft's advisory)
param(
[string]$RemoveKB = "",
[switch]$RestartRDSService
)
Write-Host "=== Step 1: September 2026 installed updates ===" -ForegroundColor Cyan
$recentUpdates = Get-HotFix | Where-Object { $_.InstalledOn -ge (Get-Date "2026-09-01") } | Sort-Object InstalledOn -Descending
$recentUpdates | Format-Table HotFixID, Description, InstalledOn, InstalledBy -AutoSize
if (-not $recentUpdates) { Write-Host "No September 2026 updates found via Get-HotFix. Check Win32_QuickFixEngineering or DISM for servicing stack items." }
Write-Host "`n=== Step 2: RDS service and listener health ===" -ForegroundColor Cyan
$termService = Get-Service -Name TermService -ErrorAction SilentlyContinue
$termService | Format-List Name, Status, StartType
$listener = Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue
if ($listener) {
Write-Host "RDP listener is UP on TCP 3389 (PID $($listener[0].OwningProcess))" -ForegroundColor Green
} else {
Write-Host "RDP listener is DOWN — consistent with the September 2026 RDS regression" -ForegroundColor Red
}
# Recent RDS crash events from the System log
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddDays(-3)} -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'Remote Desktop Services' } |
Select-Object TimeCreated, Id, Message -First 10 | Format-List
if ($RestartRDSService) {
Write-Host "`n=== Step 3: Restarting dependent RDS services ===" -ForegroundColor Cyan
Restart-Service -Name UmRdpService -Force -ErrorAction SilentlyContinue
Restart-Service -Name TermService -Force -ErrorAction SilentlyContinue
Start-Sleep -Seconds 5
Get-Service TermService | Format-List Name, Status
}
if ($RemoveKB -ne "") {
Write-Host "`n=== Step 4: Removing update $RemoveKB (confirm this KB against Microsoft's advisory first) ===" -ForegroundColor Yellow
$kbId = $RemoveKB -replace 'KB',''
Start-Process wusa.exe -ArgumentList "/uninstall /kb:$kbId /norestart" -Wait -NoNewWindow
Write-Host "Removal initiated. A reboot is required. Schedule it during a maintenance window — do NOT leave the server unpatched longer than necessary."
}
Write-Host "`n=== Next steps ===" -ForegroundColor Cyan
Write-Host "1. Cross-check installed KBs against https://learn.microsoft.com/windows/release-health/ for the confirmed known issue and any Known Issue Rollback (KIR)."
Write-Host "2. If Microsoft published a KIR, deploy it via Group Policy or the KIR MSI rather than uninstalling the security update."
Write-Host "3. Re-apply the corrected update as soon as Microsoft releases it — do not pause security updates indefinitely."
Remediation
-
Confirm scope before acting. Inventory which Windows Server systems installed the September 2026 cumulative updates (use the script above, your RMM, or WSUS/Intune reporting). Do not assume your entire fleet is affected — the regression may depend on RDS role configuration, servicing stack state, or specific Server versions.
-
Check Microsoft's official guidance first. Monitor the Windows release health dashboard (https://learn.microsoft.com/windows/release-health/) and the BleepingComputer coverage for Microsoft's confirmed known-issue entry. Microsoft frequently resolves update regressions via Known Issue Rollback (KIR), which neutralizes the offending change while keeping the rest of the security fixes in place. KIR deployment (via Group Policy for domain-joined machines or the KIR MSI) is strongly preferred over full update removal.
-
If KIR is unavailable and service restoration is urgent, uninstall the specific problematic KB identified in Microsoft's advisory using
wusa /uninstall /kb:<number> /norestart, then reboot during a controlled window. Understand the tradeoff: this removes the entire cumulative update, including all security fixes it contains. Compensating controls are mandatory in the interim — restrict RDP to management networks/jump hosts via host firewall and NSGs, enforce NLA, and ensure the server is not reachable on TCP 3389 from untrusted networks. -
Restore the service where possible without rollback. Some environments recover by restarting
TermServiceandUmRdpServiceor re-registering the RDP listener. Test this on a non-production server first — it is faster and safer than uninstalling a security update if it works. -
Re-patch on the corrected release. Track Microsoft's out-of-band (OOB) fix or the next cumulative update and deploy it through your normal test ring within days of release. Set a hard internal deadline: no server should remain on the rolled-back (unpatched) state longer than one patch cycle.
-
Harden your patch process against recurrence. This incident is the case study for phased deployment rings: pilot group (24-72h soak) → broad production → RDS-critical/VDI infrastructure last. Ensure you have out-of-band management access (iDRAC/iLO, hypervisor console, Azure Serial Console) to RDS hosts so a broken RDP stack never means a stranded server.
-
Do not weaken remote access security during the outage. Prohibit internet-exposed RDP as an emergency workaround, prohibit disabling NLA, and log/approve any temporary remote access tooling. Regression firefighting is exactly when attackers catch environments with their guard down.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.