El fallo de RDS figura como «mitigado». La mitigación es apagar y encender la máquina

En el tablero de estado de Windows, el fallo de los Servicios de Escritorio remoto de este mes aparece con la etiqueta «Mitigated». Uno lee esa palabra y respira. Luego abre la ficha y encuentra la mitigación entera, que cabe en una línea: «si una máquina virtual queda inaccesible por RDP, es posible que los clientes puedan restaurar temporalmente la conectividad parando (desasignando) y reiniciando la máquina virtual afectada». Eso no es una mitigación. Es una reanimación.

Las fechas, que son la mitad de la historia

El 8 de septiembre salió la tanda mensual de actualizaciones de Microsoft. Para Windows Server 2022 es KB5122882, compilación 20348.5622; en Server 2019 es KB5122876 y en Server 2025, KB5122871. Los servidores de sesiones no se cayeron esa tarde: los administradores que lo contaron coinciden en que el equipo funciona con normalidad varias horas y la cosa empieza a torcerse después del primer cierre de sesión. Uno de ellos lo resumió en BleepingComputer así: «todos los servidores de terminales de nuestro entorno están fallando —sesiones que se caen, imposible abrir conexiones nuevas, la única solución es un reinicio forzado— en menos de un día».

Microsoft abrió la incidencia en su tablero de estado el 11 de septiembre a las 11:19 (hora del Pacífico). La última actualización de esa misma ficha es del 11 a las 19:20, y es la que cambia el estado a «Mitigated». Ocho horas entre abrir el caso y declararlo mitigado, y en medio no hay parche: la propia ficha dice «estamos trabajando para publicar una resolución en una futura actualización de Windows». En el vocabulario de ese tablero, «mitigado» describe una manera de que el servicio vuelva, no una manera de que no se vaya. La palabra se lee igual y las dos cosas no se parecen en nada.

La lista de afectados es más larga que el titular

Casi toda la cobertura habla de Windows Server 2019, 2022 y 2025. Es lo que se ve en los foros, porque son las versiones donde más granjas de sesiones hay montadas. Pero la ficha oficial lleva su apartado de plataformas afectadas, y ahí la lista es otra:

• Servidor: Windows Server 2025, 2022, 2019, 2016, 2012 R2 y 2012.
• Cliente: Windows 11 en 26H1, 25H2, 24H2 y 23H2; Windows 10 en 22H2 y 21H2, más Enterprise LTSC 2019 y LTSC 2016.

Seis versiones de servidor y ocho de cliente. Conviene decir de qué está hecha esa lista antes de apoyarse en ella: no es un inventario probado. En la misma página, la incidencia de los avisos falsos de Defender —que no tiene nada que ver con ésta— lleva exactamente las mismas catorce entradas, palabra por palabra. Es la plantilla de «todo lo que sigue en soporte», no el resultado de reproducir el fallo en cada versión. Sirve igual para lo que nos importa, porque es el alcance que el fabricante declara, y no se parece al que tiene la gente en la cabeza.

Y hay una consecuencia que nos parece la parte incómoda, marcada como lectura nuestra. La máquina que se va a quedar colgada sin que nadie lo relacione con esto es el 2012 R2 del rincón: el que sigue encendido porque dentro vive una aplicación que nadie se atreve a mover, al que se entra por RDP dos veces al mes y sobre el que no escribe artículos nadie. Con un matiz que hay que poner, porque cambia el sentido de la frase: 2012 y 2012 R2 salieron de soporte extendido el 11 de octubre de 2023, así que sólo recibieron este paquete si alguien los tiene inscritos en el año 3 de actualizaciones de seguridad extendidas, que corre hasta el 14 de octubre de 2026. O sea que las dos respuestas son malas: si el servidor se actualizó, está en la lista que nadie ha leído; si no se actualizó, lleva casi tres años sin parches y esto es el menor de sus problemas.

Lo que Microsoft dice haber mejorado

Fuimos a la página de la propia actualización, la de KB5122882, a leer qué cambió. En el apartado de mejoras hay cinco entradas: compatibilidad de aplicaciones durante actualizaciones de autoridades de certificación, el huso horario de Marruecos, un error de parada 0x139 en un número limitado de máquinas virtuales de Windows Server 2022, una mejora de la conmutación de red al desconectar un adaptador… y ésta, literal: «[Escritorio remoto] esta actualización mejora la redirección de audio de Escritorio remoto, ayudando a que el audio de las sesiones remotas suene correctamente en el dispositivo local».

Hay quien ha ido más allá y ha puesto un depurador. La hipótesis que circula viene de un administrador en Reddit, recogida después por BleepingComputer: «el servicio se cuelga en RDPSERVERBASE!WDLIB_Close, parece que aquí no hay ningún tiempo de espera configurado. Esto provoca un bloqueo mutuo entre RDP y LSM» —el Administrador de sesiones local—. No está confirmado: Microsoft no ha publicado causa raíz y nosotros no lo hemos reproducido. Lo que sí es comprobable es que la receta que circula para devolver la vida a los servidores consiste, según quien la publica, en revertir precisamente la mejora de redirección de audio de esta actualización. Nuestra conclusión, con esa cautela puesta, es que lo que ha dejado sin trabajar a plantillas enteras parece ser la pieza que hace que el sonido se oiga en el portátil de casa. Ningún registro de riesgos del mundo tiene una línea que diga «redirección de audio».

Por qué «desinstala el parche» es el peor de los dos consejos

Es el consejo que aparece en cuanto abres cualquier hilo: quita la actualización y las sesiones vuelven. Es verdad que funciona. Y es, en este caso concreto, la peor decisión disponible, por una razón que casi nadie está poniendo al lado. El mismo paquete acumulado que te tumbó el servidor de sesiones es el que cierra CVE-2026-69525: un uso de memoria después de liberarla (CWE-416) en los Servicios de Escritorio remoto de Windows, descrito como «permite a un atacante no autorizado ejecutar código a través de una red», con 9,8 y vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Sin credenciales. Sin que nadie pinche en nada. La propia Microsoft lo sitúa en «explotación más probable» en su índice de explotabilidad, y Tenable cuenta cuatro ejecuciones remotas en Escritorio remoto sólo este mes.

Y no viaja solo. En la misma tanda van dos fallos que, según el recuento de Tenable, ya se estaban explotando cuando salió el parche: CVE-2026-81963, en la pila de Windows Update, que por seguimiento de enlaces eleva a SYSTEM, y CVE-2026-85880, en ALPC, que llega a SYSTEM saltándose la autenticación. Son 964 identificadores en total ese día, 104 de ellos críticos, según ese mismo recuento. Así que la decisión real no es «disponibilidad contra seguridad» en abstracto: es quitar de un servidor de sesiones el arreglo de una ejecución remota sin autenticar en el servicio de sesiones, y dejarlo así los días que Microsoft tarde en publicar la resolución. Si además ese servidor tiene el 3389 asomado a internet «sólo para el comercial que viaja» —y los tiene, los seguimos viendo—, el cálculo deja de ser discutible.

Qué haríamos nosotros, y qué no

No hay un remedio oficial. Lo único que Microsoft ofrece hoy es reiniciar la máquina y una resolución sin fecha. Lo que viene son decisiones de riesgo, no instrucciones de fabricante.

1. Quitar la redirección de audio por la vía documentada, en un anillo pequeño. Existe desde hace más de una década una directiva de grupo llamada «Permitir la redirección de reproducción de audio y vídeo», en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio remoto > Redirección de dispositivos y recursos. Deshabilitada, la redirección no se usa aunque el cliente la pida. Es la palanca soportada que toca exactamente lo que la actualización dice haber cambiado. Microsoft no la ha publicado como mitigación de este fallo y nosotros no afirmamos que lo resuelva: es una hipótesis razonable que se prueba en dos hosts y se mira 48 horas, no algo que se empuja al dominio entero un viernes.
2. No tocar el interruptor de función que circula por los foros. Hay publicada una receta que crea una clave bajo HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides para anular una funcionalidad concreta por su identificador numérico. Puede que funcione. No la vamos a recomendar: es un interruptor sin documentar, atado a una compilación concreta, y el día que Microsoft publique la resolución esa clave seguirá ahí, en cien servidores, sin que nadie recuerde qué apaga. Se cambia un problema conocido por uno que dentro de seis meses nadie sabrá diagnosticar.
3. Sacar el 3389 de internet, hoy. No por este fallo, sino por el otro: si finalmente decides desinstalar, lo que dejas abierto es el 9,8 sin autenticar. Con una puerta de enlace de Escritorio remoto o una VPN delante, la desinstalación pasa de temeraria a discutible. Sin ellas, no.
4. Si ya has desinstalado, ponle fecha de vuelta y déjala escrita. El riesgo de un parche retirado no es el día que lo retiras, es el mes catorce, cuando ya nadie se acuerda de que ese servidor va con el rollup de agosto. Es exactamente el agujero del que hablamos hace unos días al contar por qué un equipo puede decir que está al día con la versión vulnerable puesta.

La pregunta que no va de Microsoft

¿Cuánta gente de tu empresa dejó de trabajar esta semana? Si la respuesta es «toda», el problema no fue la actualización. Una granja de sesiones concentra el puesto de trabajo de la plantilla entera en un servicio de un servidor, y lleva haciéndolo tanto tiempo que ha dejado de parecer una decisión. Lo es. Es la misma pregunta que nos hicimos hace unos días sobre quién apaga los escritorios virtuales cuando la capa que los orquesta deja de hablar con la de abajo: el escritorio remoto es comodísimo justo hasta el momento en que no está.

El detalle que lo demuestra con un reloj es éste: el fallo tarda horas en aparecer. El equipo arranca, la gente entra, todo va bien, y empieza a romperse después del primer cierre de sesión. La comprobación de siempre —aplicas, reinicias, abres una sesión de prueba, funciona, pasas al siguiente— habría dado verde en los cien servidores. Contra un fallo que tarda media jornada en asomar no hay diligencia que valga, sólo tiempo. Un anillo canario de dos hosts de sesión parcheados el martes y el resto el viernes es lo que esta semana separaba a quien perdió dos servidores de quien los perdió todos.

Un apunte de calendario que sale de la misma página y que conviene anotar aunque no tenga que ver con el fallo: Windows Server 2022 llega al final del soporte estándar el 13 de octubre de 2026, y la actualización de seguridad de octubre será la última de esa fase. Después pasa a soporte extendido, con actualizaciones de seguridad mensuales sin coste adicional hasta el 14 de octubre de 2031. No cambia nada de lo de esta semana. Cambia bastante del plan de quien tenga la granja de sesiones ahí montada y estuviera pensando en dejarla dos años más como está. Y si el plan de vuelta no está escrito ni ensayado, es que no hay plan: ya lo contamos al hablar del plan de continuidad que nadie ha ensayado.

Nota de fuentes

Fuentes primarias que hemos leído nosotros. La página de estado «Windows Server 2022 known issues and notifications» de Microsoft Learn: de ahí salen el estado «Mitigated», las horas (abierta el 11-sep-2026 a las 11:19 PT, última actualización el mismo 11 a las 19:20 PT), el texto literal de la solución alternativa —«If a virtual machine becomes inaccessible through RDP, customers may be able to temporarily restore connectivity by stopping (deallocating) and restarting the affected virtual machine»—, la frase sobre la resolución futura, la lista de plataformas afectadas y las fechas de Windows Server 2022 (fin de soporte estándar el 13-oct-2026, última actualización de esa fase la de octubre, soporte extendido hasta el 14-oct-2031). Que esa lista de plataformas coincida palabra por palabra con la de la incidencia no relacionada de Microsoft Defender Antivirus, en la misma página, lo hemos comprobado nosotros. La página de soporte de KB5122882 (8-sep-2026, compilación 20348.5622) aporta el apartado de mejoras completo, incluida la cita «[Remote desktop] This update improves Remote Desktop audio redirection, helping audio from remote sessions play correctly on the local device»; a fecha de hoy su apartado de problemas conocidos sólo recoge el de WSUS. Las fechas de soporte de Windows Server 2012 R2 —fin de soporte extendido el 11-oct-2023 y año 3 de actualizaciones de seguridad extendidas del 15-oct-2025 al 14-oct-2026— son de la ficha de ciclo de vida de Microsoft.

Vulnerabilidades. De CVE-2026-69525 tomamos del registro público del CVE la descripción («use after free in Windows Remote Desktop Services allows an unauthorized attacker to execute code over a network»), el 9,8, el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-416 y la fecha de publicación. La valoración «Exploitation More Likely» es del índice de explotabilidad de Microsoft, y la conocemos por el análisis de Tenable del 8 de septiembre de 2026, del que también salen los 964 identificadores con 104 críticos, las cuatro ejecuciones remotas en Escritorio remoto de ese mes y los dos fallos ya explotados: CVE-2026-81963 (pila de Windows Update, seguimiento de enlaces, elevación a SYSTEM) y CVE-2026-85880 (ALPC, salto de autenticación, SYSTEM). Otros recuentos del mismo día publican cifras algo distintas según qué incluyan.

Síntomas y terceros. La cronología, los síntomas y los KB de Server 2019 (KB5122876) y Server 2025 (KB5122871) proceden de BleepingComputer, IT-Connect y LazyAdmin. Las dos citas de administradores son de ahí: la del reinicio forzado en menos de un día, y la del bloqueo en RDPSERVERBASE!WDLIB_Close, que es un mensaje publicado en Reddit y recogido después por BleepingComputer, no confirmado por Microsoft ni reproducido por nosotros. Que la receta del interruptor bajo HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides revierta la mejora de redirección de audio lo dice LazyAdmin, que es quien la publica; la citamos para desaconsejarla. La directiva de grupo «Permitir la redirección de reproducción de audio y vídeo» y su ruta están documentadas por Microsoft desde Windows Server 2008 R2, pero no es una mitigación publicada para este fallo.

Lo que es lectura nuestra y no de las fuentes: que «mitigado» describa una manera de recuperar el servicio y no de evitar que se caiga; que la lista de plataformas sea una plantilla y aun así valga como alcance declarado; el razonamiento sobre el 2012 R2 y sus dos respuestas malas; que la causa parezca estar en la redirección de audio, que es una inferencia nuestra a partir del orden de los hechos y de lo que revierte la receta que circula, no una causa raíz publicada; que desinstalar sea la peor de las dos opciones por quitar el arreglo de una ejecución remota en el mismo servicio; y que una ventana de fallo de horas invalide la comprobación posterior al parche.

Fotografía de portada: «Computer Laboratory», de Kiruthikapalani, publicada en Wikimedia Commons bajo licencia Creative Commons CC BY-SA 4.0. La hemos recortado y le hemos superpuesto los textos de marca; esta versión se distribuye bajo la misma licencia CC BY-SA 4.0. Todo se ha contrastado el 12 de septiembre de 2026.