Updates de Setembro de 2026 no Windows Server: falhas no RDS e correcções

Os updates de segurança de 8 de Setembro de 2026 (KB5122871 no Server 2025, KB5122882 no Server 2022, KB5122876 no Server 2019 e KB5123099 no Server 2016) introduziram um defeito grave no Remote Desktop Services: horas depois do arranque, os anfitriões RDS bloqueiam durante os logoffs, novas ligações ficam presas no ecrã “Please wait for the Remote Desktop Configuration” e só um hard reset recupera a máquina. O rollback do update é tentado por muitos, mas é uma má ideia neste caso: os CUs de Setembro incluem a correcção do CVE-2026-69525, uma falha de execução remota de código nos RDS com CVSS 9.8, além de duas vulnerabilidades de dia zero já exploradas activamente.

Este artigo percorre o diagnóstico nas máquinas afectadas, as duas resoluções oficiais por ordem de preferência (update fora de banda e rollback de known issue por GPO) e a recuperação por DISM quando o anfitrião já está bloqueado.

Neste artigo

  1. Sintomas e diagnóstico
  2. O que causou o problema
  3. Correcção permanente: update fora de banda
  4. Fallback: Known Issue Rollback por GPO
  5. Recuperar um anfitrião já bloqueado
  6. Prevenção: anéis de distribuição de updates

1. Sintomas e diagnóstico

O padrão de falha é consistente em toda a parte. Os anfitriões RDS funcionam normalmente após o reboot, quebram horas mais tarde quando os utilizadores começam a fazer logoff. Novas ligações RDP ficam presas em “Connecting…” e nunca chegam ao logon, sessões existentes não conseguem terminar de forma limpa, e ferramentas que tocam no estado de sessão deixam de responder: Task Manager, MMC, RDS Licensing Diagnoser, File Explorer e a própria página do Windows Update. A máquina só recupera com reset físico.

Três verificações confirmam se o caso é este defeito e não outra coisa:

Build afectada — no PowerShell:


$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Os builds afectados são 26100.33438 no Server 2025, 20348.5622 no Server 2022 e 17763.9245 no Server 2019.

Eventos no log — o timeout de ligação RDP aparece no canal Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin como Evento 20498:


Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'; Id=20498} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap

O segundo sintoma é o Evento 6005 no log System do Winlogon:


Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Winlogon'; Id=6005} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap

Estado do TermService — o serviço fica em stop pending:


Get-Service TermService | Select-Object Name, Status

2. O que causou o problema

A primeira análise séria veio da comunidade: o utilizador u/lesiromanu no reddit r/sysadmin fez debugging a nível de kernel num anfitrião Server 2022 e identificou a rotina RDPSERVERBASE!WDLIB_Close, invocada durante o teardown de sessão RDP. Com uma feature flag interna (3802373433) activa, a rotina chama RtlWaitOnAddress sem timeout, o thread fica bloqueado indefinidamente e o Local Session Manager, que serializa mudanças de estado de sessão numa única critical section, bloqueia tudo atrás dele: novas ligações, logoffs e pedidos do broker. A Citrix confirmou de forma independente o mesmo comportamento no artigo CTX697101. A Microsoft corrigiu o defeito a 14 de Setembro com o update fora de banda e mantém a issue como resolved nas páginas de release health.

Como funciona o Known Issue Rollback

A feature flag 3802373433 é um “feature on/off” que a Microsoft distribui controlado via registry. Um Known Issue Rollback (KIR) não desinstala o update: cria um override que desliga a flag problemática sem remover o CU. É por isto que o fix oficial existe em dois formatos — update fora de banda para quem pode instalar, e KIR para quem não pode.

3. Correcção permanente: update fora de banda

A Microsoft publicou a 14 de Setembro os updates fora de banda KB5129235 (Server 2025), KB5129237 (Server 2022, build 20348.5631) e KB5129238 (Server 2019) que corrigem o deadlock. As versões mais antigas receberam OOB dedicado no catálogo: KB5129239 (Server 2016, confirmado no Microsoft Update Catalog com data 14/09) e KB5129243 (Server 2012 R2, monthly rollup). O Windows Server 2012 R2 está no último ano do programa ESU, que termina a 13 de Outubro de 2026 — para estes anfitriões instalar o OOB é ainda mais urgente, porque as janelas de correcção acabam aí.

Não estão no Windows Update nem no WSUS, são descarregados do Microsoft Update Catalog e instalados manualmente (ou importados para o WSUS como .msu). Cada versão do Server usa o seu pacote: KB5129238 (2019), KB5129237 (2022) e KB5129235 (2025).

O comando abaixo usa o Server 2022 como exemplo — substitui pelo nome do ficheiro descarregado da tua versão:

Nota: o caminho relativo (.\) só funciona se a consola de powershell estiver na pasta de destino do download do ficheiro.


wusa.exe .\KB5129237.msu /quiet /norestart

O reboot desliga as sessões activas. Nota importante: o OOB é cumulativo e inclui todas as correcções de segurança do CU de Setembro — quem ainda não instalou o CU afectado pode aplicar directamente o OOB, sem os dois. Confirmar o build incrementado:


$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.CurrentBuild).$($cv.UBR)"

Para Server 2022, o build esperado é 20348.5631. Um GPO de KIR aplicado antes é suplantado — pode remover-se. Se alguma tentativa anterior aplicou um override manual de feature flag no registry (solução não oficial, ver nota na secção 4), limpe-o:


Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\3802373433" -Force

Nota: o OOB também corrige os problemas de áudio multicanal USB Audio Class 1.0 em modos 8 canais e 3D. A componente Code 10 e perda total de som nesses dispositivos fica por resolver, em trabalho pela Microsoft.

4. Fallback: Known Issue Rollback por GPO

Para quem não pode instalar o OOB (fazendas em produção com SLA janela de reboot, ou Server 2016 que não tem OOB), o KIR via GPO desliga a feature flag sem update. A Microsoft distribuiu os MSI que registam os templates ADMX para cada versão: KB5123065 (Server 2012), KB5123066 (2012 R2), KB5123099 (2016), KB5122876 (2019), KB5122882 (2022) e KB5122871 (2025).

O percurso é o seguinte. Instalar o MSI numa máquina com acesso às Group Policies (regista o template ADMX). Copiar os ficheiros ADMX/ADML para o central store \\domain\SYSVOL\domain\Policies\PolicyDefinitions\. Criar/editar um GPO ligado às máquinas RDS e, em Computer Configuration > Administrative Templates, definir a política de Known Issue Rollback para esse KB em Disabled (é assim que se “activa o rollback”). Aplicar o GPO e correr gpupdate /force nos anfitriões afectados. Sem restart do TermService: a flag é avaliada quando o serviço reavalia as features.

Monitorizar os eventos 20498 e 6005 durante 24-48 horas, em particular nos momentos de logoff. Se nenhum reaparecer e o TermService ficar Running, a correcção está segurada. Ressalva: há relatos de administradores em que o KIR não travou o deadlock em alguns anfitriões — nesse caso instalar o OOB da versão, que é a correcção definitiva.

A Microsoft não documenta qualquer override manual de registry para esta issue. Soluções da comunidade que manipulam a feature flag interna (chave FeatureManagement\Overrides\4\3802373433) circulam em fóruns, foram reportadas como pouco fiáveis — falharam em pelo menos um anfitrião Server 2022 21H2 — e podem ter efeitos não conhecidos noutras rotinas. Não as use: aplique o KIR oficial por GPO ou instale o update fora de banda.

5. Recuperar um anfitrião já bloqueado

Quando o anfitrião já está bloqueado (RDP inacessível), é preciso reset físico para recuperar o acesso. Depois, remover rapidamente o CU de Setembro antes que o bloqueio se repita: o wusa /uninstall /kb:5122882 falha porque os updates de Setembro vêm como pacote único com SSU+LCU e o instalador standalone rejeita o pacote completo. O DISM remove só o LCU:


dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"

Devolve algo como Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2:


dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.2 /NoRestart

Substituir o nome do pacote pelo exacto do output anterior. A parte do SSU fica instalada — é comportamento normal. Depois do reboot, bloquear o reinstalo do KB: no WSUS, declinar o KB, ou GPO de deferral no Windows Update. Aviso: o rollback do DISM remove todas as correcções de segurança do ciclo de Setembro, incluindo a do CVE-2026-69525 (CVSS 9.8) — é um último recurso apenas para anfitriões ainda bloqueados. Em máquinas a funcionar, o KIR oficial por GPO evita o rollback.

6. Prevenção: anéis de distribuição de updates

O incidente expõe o risco de distribuição instantânea: qualquer update de segurança em produção na totalidade do parque no primeiro dia pode causar esta situação. A prática recomendada é manter um anel piloto de 1-2 máquinas RDS menos críticas que recebem o update umas semanas antes dos restantes. Um anfitrião piloto devidamente monitorizado nos logs dá a informação suficiente para parar o rollout, ou para acelerar as correções.

Correcções em resumo

Situação Acção
Anfitrião a funcionar, com janela de reboot Descarregar e instalar OOB (KB5129235/5129237/5129238)
Anfitrião a funcionar, sem possibilidade de instalar o OOB (sem janela de reboot, Server 2016 quando o OOB não se aplica) KIR via GPO — os MSI dos templates ADMX são públicos, não exigem licença
Anfitrião já bloqueado Reset físico + rollback por DISM + bloquear KB
Server 2016 KIR via GPO (não tem OOB)
Server 2012 R2 OOB KB5129243 (ou KIR via GPO)

Fontes oficiais