L'aggiornamento doveva chiudere la porta
Il Patch Tuesday di Microsoft di settembre 2026 ha incluso una correzione per CVE-2026-69525, una falla nei Servizi Desktop remoto con un punteggio CVSS di 9.8 su 10, il tipo di punteggio riservato ai bug che uno sconosciuto su internet può sfruttare senza password. Un pacchetto appositamente costruito inviato alla porta 3389 poteva innescare un errore use-after-free ed eseguire codice con i privilegi del servizio, senza bisogno di accedere.
Gli amministratori che hanno applicato l'aggiornamento secondo il calendario, la scelta responsabile secondo qualsiasi criterio normale, hanno fatto esattamente ciò che i team di sicurezza chiedono ogni mese.
Poi il Desktop remoto ha iniziato a bloccarsi da solo
Poche ore dopo aver installato KB5122876 su Server 2019, KB5122882 su Server 2022 o KB5122871 su Server 2025, i Servizi Desktop remoto hanno iniziato a fallire. Le connessioni che funzionavano all'avvio smettevano di funzionare poche ore dopo. Le sessioni esistenti non riuscivano a disconnettersi correttamente. I nuovi tentativi di connessione restavano bloccati e alla fine andavano in timeout, e nei casi peggiori l'unica soluzione era un riavvio forzato del server.
Un amministratore ha descritto lo schema senza mezzi termini: funziona all'inizio, ma dopo la prima disconnessione il servizio si blocca e nessun altro utente può accedere. Un ricercatore che ha ricostruito il problema ha indicato un deadlock tra il processo del Desktop remoto e il Local Session Manager, una diagnosi che Microsoft non ha confermato.
Cosa si è rotto, e dove
| Versione di Windows Server | Aggiornamento | Sintomo |
|---|---|---|
| Server 2019 | KB5122876 | RDS fallisce ore dopo l'avvio |
| Server 2022 | KB5122882 | Le sessioni si bloccano alla disconnessione |
| Server 2025 | KB5122871 | Le nuove connessioni vanno in timeout |
Microsoft ha confermato soltanto di essere a conoscenza delle segnalazioni e di essere al lavoro. Non ha confermato la causa reale né ha detto quando arriverà una correzione.
Perché conta
Perché conta: Non è un dibattito astratto sulla gestione delle patch, è una scelta concreta per qualsiasi team che gestisce Windows Server con il Desktop remoto esposto, e nelle operazioni europee e britanniche con personale da remoto, fornitori esterni o filiali, questa è la maggioranza. Tornare indietro riapre sugli stessi server una falla di gravità 9.8 sfruttabile senza credenziali. Lasciarlo installato può far smettere di funzionare senza preavviso proprio l'accesso remoto, la ragione stessa per cui quei server esistono.
Sì, ma
Sì, ma: Nessuna delle due opzioni è in realtà l'unica via d'uscita. Gli amministratori che non possono rischiare né un rollback completo né un accesso remoto rotto stanno invece limitando l'esposizione RDP a livello di rete, restringendo la porta 3389 a una VPN o a un jump host invece che a internet aperto, il che mantiene la patch installata, chiude la via più facile verso la vulnerabilità corretta, e guadagna tempo per una correzione ufficiale senza scommettere su nessuno dei due scenari di guasto.
La conclusione
La conclusione: "Applicare subito tutte le patch" e "aspettare una settimana per sicurezza" sono entrambi l'istinto sbagliato in questo caso, perché la vera decisione non riguarda la velocità, ma l'esposizione. Testate ogni aggiornamento cumulativo su un piccolo gruppo canarino prima che raggiunga tutti i server, e limitate l'accesso di rete a tutto ciò che l'aggiornamento potrebbe toccare, così una patch difettosa degrada una manciata di macchine invece di ogni sessione Desktop remoto dell'azienda in una volta sola.
Da leggere ora: Lo shock del CEO Apple del 2011 è costato 12 volte più di quello del 2026 | La svolta di Xbox ha riguardato il marketing, non i giochi
