La actualización debía cerrar la puerta
El Patch Tuesday de Microsoft de septiembre de 2026 incluyó una corrección para CVE-2026-69525, un fallo en los Servicios de Escritorio remoto con una puntuación CVSS de 9.8 sobre 10, la clase de puntuación reservada para fallos que un desconocido en internet puede explotar sin contraseña. Un paquete especialmente diseñado enviado al puerto 3389 podía desencadenar un error use-after-free y ejecutar código con privilegios de servicio, sin necesidad de iniciar sesión.
Los administradores que aplicaron la actualización según el calendario, la decisión responsable según cualquier criterio normal, hicieron exactamente lo que los equipos de seguridad piden cada mes.
Entonces Escritorio remoto empezó a fallar por si solo
Horas después de instalar KB5122876 en Server 2019, KB5122882 en Server 2022 o KB5122871 en Server 2025, los Servicios de Escritorio remoto empezaron a fallar. Conexiones que funcionaban al arrancar dejaban de hacerlo unas horas más tarde. Las sesiones existentes no podian cerrarse correctamente. Los nuevos intentos de conexion se quedaban colgados y acababan agotando el tiempo de espera, y en los peores casos la única solución era reiniciar el servidor a la fuerza.
Un administrador describio el patron sin rodeos: funciona al principio, pero tras el primer cierre de sesión, el servicio se cae y ningún otro usuario puede iniciar sesión. Un investigador que rastreo el fallo señaló un bloqueo mutuo entre el proceso de Escritorio remoto y el Local Session Manager, un diagnóstico que Microsoft no ha confirmado.
Qué falló y dónde
| Version de Windows Server | Actualización | Sintoma |
|---|---|---|
| Server 2019 | KB5122876 | RDS falla horas después de arrancar |
| Server 2022 | KB5122882 | Las sesiones se quedan colgadas al cerrar |
| Server 2025 | KB5122871 | Las conexiones nuevas agotan el tiempo de espera |
Microsoft solo ha confirmado que conoce los informes y que esta investigando. No ha confirmado la causa raiz ni ha dicho cuando llegara una solución.
Por qué importa
Por qué importa: Esto no es un debate abstracto sobre gestión de parches, es una decisión real para cualquier equipo que ejecute Windows Server con Escritorio remoto expuesto, y en operaciones europeas y británicas con personal remoto, contratistas o sucursales, eso es la mayoría. Revertir la actualización vuelve a abrir en los mismos servidores un fallo de gravedad 9.8 explotable sin credenciales. Dejarla instalada puede hacer que el acceso remoto en si, la razón de ser de esos servidores, deje de funcionar sin aviso.
Sí, pero
Sí, pero: Ninguna de las dos opciones es en realidad la única salida. Los administradores que no pueden arriesgarse ni a una reversión completa ni a un acceso remoto roto están restringiendo en su lugar la exposición de RDP a nivel de red, limitando el puerto 3389 a una VPN o un jump host en vez de al internet abierto, lo que mantiene el parche instalado, cierra el camino más fácil hacia la vulnerabilidad que corrige, y da tiempo para una solución oficial sin apostar por ninguno de los dos escenarios de fallo.
La conclusión
La conclusión: "Parchear todo de inmediato" y "esperar una semana por seguridad" son ambos el instinto equivocado aquí, porque la decisión real no trata de velocidad, sino de exposición. Pruebe cada actualización acumulativa en un pequeño grupo canario antes de que llegue a todos los servidores, y restrinja el acceso de red a cualquier cosa que la actualización pueda afectar, para que un parche defectuoso degrade un puñado de maquinas en vez de todas las sesiones de Escritorio remoto de la empresa a la vez.
Leer a continuación: El susto por el CEO de Apple en 2011 costó 12 veces más que el de 2026 | El giro de Xbox fue en el marketing, no en los juegos
