Las actualizaciones de seguridad de Windows publicadas en el tradicional Patch Tuesday de diciembre han desencadenado incidencias críticas en la infraestructura de Microsoft Message Queuing (MSMQ). En numerosos entornos corporativos se han observado fallos en colas de mensajes y en aplicaciones web sobre IIS, afectando directamente a la disponibilidad de servicios esenciales para el negocio.
Actualizaciones de seguridad de Windows que afectan a MSMQ
Según la información facilitada por Microsoft, el problema impacta a sistemas con Windows 10 22H2, Windows Server 2019 y Windows Server 2016 que han instalado los parches de seguridad KB5071546, KB5071544 y KB5071543, correspondientes al ciclo de actualizaciones de diciembre de 2025.
MSMQ es un componente opcional presente en todas las versiones soportadas de Windows, ampliamente utilizado en entornos empresariales para el intercambio asíncrono de información entre aplicaciones y servicios distribuidos. Por ello, cualquier interrupción en el servicio puede desencadenar una reacción en cadena en sistemas que dependen de las colas de mensajes para procesar pagos, órdenes, trabajos en segundo plano o integraciones entre microservicios.
Los administradores han reportado síntomas recurrentes tras instalar estas actualizaciones de seguridad:
– colas de MSMQ inactivas o inaccesibles;
– sitios y servicios en IIS que se detienen con errores de “recursos insuficientes”;
– aplicaciones incapaces de escribir mensajes en las colas;
– eventos de error indicando falta de memoria RAM o espacio en disco, aun cuando el servidor dispone de recursos suficientes.
Causa técnica del fallo en Microsoft Message Queuing
La investigación preliminar de Microsoft vincula el incidente con cambios en el modelo de seguridad de MSMQ y en los permisos NTFS de una carpeta crítica del sistema: C:\Windows\System32\MSMQ\storage. En este directorio se almacenan los ficheros necesarios para el funcionamiento interno de las colas.
Tras aplicar las actualizaciones de diciembre, los procesos asociados al servicio MSMQ requieren permisos de escritura en dicha carpeta. Históricamente, el acceso estaba más restringido y bajo control de cuentas con privilegios elevados. Como consecuencia, cualquier operación de escritura a través de la API de MSMQ puede fallar, generando errores que, a nivel de aplicación, se interpretan como problemas de recursos y no como incidencias de autorización.
El impacto se agrava en clústeres de MSMQ bajo alta carga, donde múltiples nodos intentan escribir simultáneamente en las colas. En estos escenarios, la combinación de alto volumen de mensajes y permisos inconsistentes incrementa la probabilidad de inestabilidad y fallos encadenados en varios nodos del clúster.
Impacto en continuidad de negocio y superficie de ataque
En muchas organizaciones, MSMQ actúa como “espina dorsal” de sistemas de pago internos, colas de trabajo, integraciones entre aplicaciones y buses de mensajería. Una degradación en el servicio puede provocar retrasos en la ejecución de transacciones, pérdida temporal de solicitudes de clientes, incumplimientos de SLA y costes operativos asociados a la recuperación manual de procesos.
Además, surge una disyuntiva delicada desde el punto de vista de la ciberseguridad: mantener los parches de seguridad y convivir con la disrupción en MSMQ o desinstalar las actualizaciones problemáticas para restaurar la operativa, asumiendo un incremento de la superficie de ataque. Revertir los parches puede resolver a corto plazo los fallos en MSMQ e IIS, pero reabre vulnerabilidades que las actualizaciones buscaban mitigar, en contra de las mejores prácticas recomendadas por marcos como NIST SP 800-40 para gestión de parches.
Gestión de parches: equilibrio entre seguridad y disponibilidad
En entornos empresariales maduros, la respuesta recomendada pasa por un análisis estructurado, evitando decisiones impulsivas. Para infraestructuras con MSMQ activado es aconsejable:
– inventariar rápidamente los servidores con MSMQ y los parches KB5071546, KB5071544 y KB5071543 instalados;
– evaluar la criticidad de los servicios afectados y el potencial impacto económico del tiempo de inactividad;
– revisar detalladamente los registros de eventos de Windows, MSMQ e IIS para confirmar que el fallo está relacionado con permisos en la carpeta storage, descartando otros factores;
– probar cualquier cambio (incluyendo un posible rollback de parches o modificaciones en las ACL de storage) en entornos aislados de preproducción antes de aplicarlos en servidores de producción.
Recomendaciones para administradores de Windows y MSMQ
Microsoft ha reconocido el problema y se encuentra analizando una solución definitiva, aunque todavía no se han comunicado plazos ni el formato del futuro parche (acumulativo o actualización independiente). Mientras tanto, en términos de gestión de riesgos, pueden adoptarse las siguientes medidas:
– Monitorizar los avisos oficiales de Microsoft, especialmente las secciones de Known Issues de cada KB y la documentación específica de MSMQ;
– evitar, en la medida de lo posible, un rollback masivo de las actualizaciones de seguridad: si no existe alternativa, reforzar controles compensatorios como segmentación de red, listas de control de acceso, monitorización de eventos de seguridad y endurecimiento de servicios expuestos;
– documentar exhaustivamente cualquier solución temporal o ajuste de permisos, para poder revertirlos de forma segura cuando se publique el parche oficial;
– utilizar grupos piloto de servidores y laboratorios de pruebas para validar futuras actualizaciones de Windows, con especial atención a componentes sensibles como MSMQ, IIS, clústeres de alta disponibilidad y plataformas de integración.
La situación generada por las actualizaciones de diciembre de Windows y el fallo en MSMQ subraya la necesidad de contar con procesos de gestión de parches y de continuidad de negocio bien definidos: pruebas sistemáticas previas al despliegue, planes de contingencia, procedimientos claros de rollback y una coordinación estrecha entre los equipos de infraestructura y seguridad. Fortalecer estos procesos reduce significativamente el riesgo de que un futuro “martes de parches” se convierta en el origen de una interrupción crítica, y permite a las organizaciones mantener un equilibrio saludable entre protección frente a amenazas y disponibilidad de sus servicios.
