domingo 1 de noviembre, 2026
Vulnerabilidades

KB5122876: la actualización que tumbó Remote Desktop Services, vista desde dos farms VMware

La actualización acumulativa de septiembre de 2026 dejó inestable Remote Desktop Services en servidores Windows de todo el mundo. Lo vivimos en dos farms independientes sobre VMware, con efectos más severos de los documentados oficialmente — y esto es lo que hicimos para recuperarlas.

El 8 de septiembre de 2026, Microsoft publicó su ciclo mensual de actualizaciones acumulativas de seguridad. Entre ellas, KB5122876 para Windows Server 2019 y KB5122882 para Windows Server 2022. Cinco días después de instalarla en dos farms de Remote Desktop Services que administro —sobre infraestructuras distintas, ambas con VMware como hipervisor—, las dos quedaron completamente fuera de servicio el mismo día.

No fue un caso aislado. Microsoft confirmó oficialmente el problema el 14 de septiembre: las actualizaciones de ese ciclo dejaban inestable RDS en Windows Server 2012 y versiones posteriores, además de Windows 10 y 11, con conexiones RDP que fallaban a los pocos minutos, sesiones que no cerraban correctamente y servidores que quedaban colgados en «Please wait for the Remote Desktop Configuration». Herramientas como la consola MMC, el diagnosticador de licencias RDS y hasta el Explorador de archivos dejaban de responder en los equipos afectados (BleepingComputer).

Lo que vivimos en nuestras dos farms fue, en algunos casos, más severo de lo que describe el aviso oficial: varios servidores entraron en ciclos de reparación/restauración del sistema, y uno de ellos perdió por completo la configuración de su adaptador de red tras el reinicio — tuvimos que entrar por consola del hipervisor y reinstalar el driver de red manualmente para recuperarlo. Que el problema se manifestara con esta severidad en dos entornos de proveedores distintos, con el único punto en común de ser VMware, sugiere una interacción específica entre la actualización y el stack de red virtualizado (probablemente el driver vmxnet3) que no vimos documentada en ningún aviso público.

La actualización prometía corregir vulnerabilidades. En la práctica, durante casi una semana, el problema no fue la seguridad: fue que nadie podía trabajar.

Cómo lo resolvimos

La respuesta varió según la versión de cada farm:

  • Windows Server 2019: optamos por el rollback completo de la actualización. Microsoft no publicó una actualización fuera de banda específica para esta versión en el momento en que tuvimos que decidir, y con RDS completamente caído no era una opción esperar.
  • Windows Server 2022: instalamos la hotfix fuera de banda KB5129237, publicada por Microsoft el 14 de septiembre específicamente para corregir este problema. Resolvió la inestabilidad de RDS sin necesidad de retirar el parche de seguridad completo.
  • El servidor con el adaptador de red perdido: no respondió a ninguna de las dos soluciones anteriores porque el problema ya no era RDS sino el propio adaptador. Hubo que entrar por la consola del hipervisor (fuera de la red, ya que el servidor no tenía conectividad) y reinstalar el driver de red manualmente antes de poder aplicar cualquier otra corrección.

Lo que nos deja esta experiencia

Ya hablamos en este portal de por qué actualizar el software sigue siendo la defensa más simple frente a vulnerabilidades conocidas. Este incidente no contradice esa recomendación, pero sí la matiza con algo que toda esa guía asumía: que el parche en sí mismo no va a romper nada. No siempre es así.

Algunas conclusiones prácticas para cualquiera que administre farms RDS sobre VMware:

  • Nunca apliques el ciclo mensual completo a producción el mismo día que sale, ni siquiera en servidores «no críticos» — dales al menos unos días de margen en un entorno de prueba antes de generalizar.
  • Ten listo un plan de rollback probado, no solo documentado. En nuestro caso, poder revertir rápido en los servidores 2019 fue lo que nos permitió recuperar el servicio mientras esperábamos una corrección mejor.
  • Snapshot antes de parchear, siempre, en entornos virtualizados — nos habría ahorrado la recuperación manual del adaptador de red en el servidor más afectado.
  • Sigue los avisos de Known Issue Rollback (KIR) de Microsoft: son la vía más rápida para mitigar sin perder las correcciones de seguridad del mes, aunque en este caso su efectividad fue desigual según el sistema.

Si administras infraestructura RDS sobre VMware y viviste algo similar en septiembre, nos interesa tu experiencia — puedes escribirnos en la página de Contacto.