Gli aggiornamenti cumulativi di settembre 2026 per Windows Server hanno introdotto un problema serio su Remote Desktop Services: dopo l’installazione delle patch, le sessioni RDP su alcuni host iniziano a bloccarsi o a rifiutare nuove connessioni, spesso dopo diverse ore di funzionamento normale. Per chi gestisce collection RDS in produzione — RDSH multi-sessione, VDI o semplicemente jump server amministrativi — è un problema da conoscere prima di distribuire la patch su larga scala, perché tocca esattamente le macchine che gli amministratori usano per raggiungere il resto dell’infrastruttura.
Quali sistemi sono coinvolti
Il problema riguarda tre cumulative update distinti, uno per versione di sistema operativo:
- KB5122876 — Windows Server 2019
- KB5122882 — Windows Server 2022
- KB5122871 — Windows Server 2025
Le note di rilascio Microsoft segnalano separatamente anche problemi su Windows Server 2016, con la redirezione audio di Remote Desktop non funzionante dopo l’installazione. Va inoltre ricordato che il pacchetto di settembre non è “solo” quello che introduce il bug: nello stesso ciclo Microsoft ha corretto oltre 970 vulnerabilità, incluse due zero-day già sfruttate attivamente. Questo rende la scelta “disinstallo la patch” tutt’altro che indolore.
Sintomi osservati
Dalle segnalazioni raccolte dagli amministratori nei forum tecnici e da chi ha già debuggato il problema, il pattern tipico è il seguente:
- RDS funziona normalmente per diverse ore dopo il riavvio post-patch;
- le sessioni RDP esistenti smettono di disconnettersi o effettuare il logoff correttamente;
- i nuovi tentativi di connessione restano bloccati sulla schermata “Connecting…” fino a fallire;
- in alcuni casi il servizio va in crash dopo il primo logout utente, impedendo login successivi;
- Task Manager e le impostazioni di sistema diventano a loro volta non responsive sull’host colpito, rendendo necessario un hard reset.
Chi ha fatto debugging più approfondito ha individuato nei log un deadlock nella libreria server RDP durante la chiusura di sessione: l’evento si blocca nella routine RDPSERVERBASE!WDLIB_Close, apparentemente senza timeout configurato, generando uno stallo tra il processo RDP e LSM (Local Session Manager). Nei log di sistema il sintomo si traduce nell’evento 20498 nel canale Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin.
Come verificare se un host è colpito
Prima di intervenire, è utile raccogliere qualche riscontro diagnostico in sola lettura:
# Verifica eventi di timeout sulla connessione RDP
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
Id = 20498
} -MaxEvents 5 | Format-Table TimeCreated, Message -Wrap
# Controlla lo stato del servizio Terminal Services
Get-Service -Name TermService | Select-Object Name, StatusSe l'evento 20498 compare in concomitanza con logoff o riconnessioni di sessione, l'host è verosimilmente esposto al bug.
Le opzioni sul tavolo
Al momento della stesura di questo articolo Microsoft non ha ancora confermato pubblicamente la causa né rilasciato una patch out-of-band; l'azienda ha dichiarato di essere a conoscenza delle segnalazioni e di stare indagando. Questo lascia agli amministratori due strade principali, entrambe con compromessi da valutare con attenzione:
1. Rollback del pacchetto cumulativo
È l'opzione più testata e documentata. Rimuove il bug ma riporta l'host allo stato di vulnerabilità precedente, comprese le due zero-day corrette a settembre — accettabile solo come misura temporanea su host isolati o con mitigazioni compensative (segmentazione di rete, restrizioni di accesso RDP tramite VPN/Bastion) già in campo.
# Individua il pacchetto della cumulative update installata
dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"
# Rimuove il pacchetto (sostituire con il nome esatto restituito sopra)
dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestart
# Riavvio richiesto per applicare la modifica
Restart-Computer -ForceSu una collection RDS gestita, conviene prima spostare l'host fuori rotazione per evitare che riceva nuove connessioni durante l'intervento:
Import-Module RemoteDesktop
Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed No
# ... rollback e riavvio ...
Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed Yes2. Workaround alternativi circolati in community
Alcuni blog tecnici indipendenti propongono un override tramite feature flag in HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides, con l'obiettivo di disattivare selettivamente il componente incriminato senza rimuovere l'intera patch di sicurezza. Va detto con chiarezza: si tratta di un workaround non ufficiale, non validato da Microsoft, che tocca un'area del registro sensibile e non documentata pubblicamente per questo scopo. Non è consigliabile applicarlo direttamente in produzione: se lo si vuole testare, farlo solo su un host di laboratorio isolato, con backup del ramo di registro prima e dopo, e senza aspettarsi supporto ufficiale in caso di problemi.
Cosa fare adesso
Il consiglio più solido, in attesa di una risposta ufficiale Microsoft, resta quello suggerito dai team di sicurezza che seguono il caso: distribuire l'aggiornamento di settembre prima su un piccolo gruppo di host RDS non critici, monitorare l'evento 20498 e lo stato del servizio TermService per 24-48 ore, e mantenere pronto un piano di rollback per gli host di produzione più esposti. Vale anche la pena avvisare in anticipo chi gestisce l'help desk: sessioni RDP che si bloccano "a caso" dopo qualche ora sono un sintomo facile da scambiare per un problema di rete o di carico, mentre qui l'origine è chiaramente lato patch.
Fonte: 4sysops – September Windows Server updates break Remote Desktop Services (RDS); approfondimenti tecnici da BleepingComputer e Cyber Security News.