9Contexto: qué falló en el proceso de Microsoft y otros casos recientes con el mismo patrón
El origen está en cómo Microsoft gestionó su propio ciclo de parches. El Patch Tuesday de septiembre de 2026 fue el mayor de su historia: en torno a 970 vulnerabilidades corregidas, algo más de un centenar de ellas críticas, con dos cero-días ya explotados en la naturaleza (CVE-2026-81963, en Windows Update Stack, y CVE-2026-85880, en el componente ALPC). En medio de ese volumen, la corrección de CVE-2026-62721, una escalada de privilegios en el servicio User-Mode Power Service, no cerró del todo la brecha. La compañía tuvo que reconocerlo, revisar su aviso de seguridad y publicar el 14 de septiembre un parche fuera de ciclo (KB5129195, que lleva Windows 11 24H2 y 25H2 a los builds 26100.9457 y 26200.9457, y KB5129194 para la versión 26H1). Ese arreglo de emergencia llegó apenas seis días después del boletín original, en el que Microsoft ya había pedido a los administradores no retrasar los parches de seguridad más de un par de días.
El patrón se repite. Un día después del boletín, el investigador Nightmare Eclipse hizo público ShieldCrash, un cero-día de Microsoft Defender que aprovechaba una ruta de código que la corrección anterior (ShieldBreak, CVE-2026-69414) había dejado sin cubrir, con lectura arbitraria de archivos con privilegios SYSTEM confirmada en todas las versiones compatibles de Windows. Era su undécimo cero-día desde abril de 2026. Algo similar ocurrió con CVE-2025-60710 (Windows Task Host): parcheada en noviembre de 2025, CISA no la incorporó a su catálogo de vulnerabilidades explotadas hasta abril de 2026 y no confirmó su uso en campañas de ransomware hasta agosto, sin que por entonces el aviso de Microsoft reflejara esa explotación. A ello se suman los daños colaterales del propio paquete de septiembre —cortes en escritorio remoto, fallos de audio por USB, cuelgues del Explorador y problemas con controladores AMD—, que la actualización de emergencia solo resolvió en parte.
