El 7 de abril, Anthropic anunció que su modelo Claude Mythos Preview había identificado de forma autónoma miles de vulnerabilidades zero-day de gravedad alta y crítica en todos los principales sistemas operativos y navegadores web. Más del 99 % de ellas seguían sin parchear el día de su divulgación.

Dos semanas después, el 21 de abril, Mozilla afirmó que había utilizado el mismo modelo para encontrar y parchear 271 vulnerabilidades en la versión más reciente de Firefox. La propia evaluación de Mozilla: «Hasta ahora no hemos encontrado ninguna categoría ni complejidad de vulnerabilidad que los humanos puedan encontrar y este modelo no».

271 es la primera oleada. Chrome, Edge, Windows, macOS, Linux, FreeBSD: el fallo de ejecución remota de código de 17 años de antigüedad en FreeBSD que divulgó el equipo rojo de Anthropic (CVE-2026-4747) es un ejemplo temprano de lo que está por venir. Todos los proveedores bajo el paraguas del Project Glasswing de Anthropic están en disposición de publicar correcciones a un ritmo que el sector no había visto antes. Todas esas correcciones se convierten en CVE públicas con parches disponibles, que acaban en el mismo lugar: su entorno.

La historia de la contención también presenta una grieta. El 21 de abril, Bloomberg informó de que un grupo vinculado a Discord obtuvo acceso no autorizado a Mythos a través del entorno de un proveedor externo. Anthropic afirma que la actividad no fue más allá de ese proveedor. Independientemente de que una capacidad similar esté ya en manos de atacantes o no, el margen defensivo es más corto de lo que sugería el anuncio del 7 de abril.

Mythos llegó a un mundo que ya avanzaba en esa dirección. El informe Global Threat Report 2026 de CrowdStrike documentó un aumento interanual del 89 % en los ataques habilitados por IA en 2025. Esa tendencia es anterior a Mythos.

Llamémoslo apocalipsis de los parches. Un apocalipsis operativo en sentido estricto, en el que el volumen y la cadencia de CVE públicas con parches disponibles están a punto de superar la forma en que trabajan actualmente la mayoría de los equipos de TI y seguridad.

NIST ya está notando los efectos del apocalipsis de los parches. En abril, la agencia anunció un cambio importante en las operaciones de la National Vulnerability Database (NVD) en respuesta a un aumento del 263 % en las solicitudes. NIST dejará de proporcionar enriquecimiento detallado para todas las vulnerabilidades enviadas y, en su lugar, solo lo hará para las vulnerabilidades que cumplan criterios de alto riesgo, como las incluidas en el catálogo Known Exploited Vulnerabilities de CISA o las que afecten a software gubernamental crítico. NIST se apoyará en las CVE Numbering Authorities (CNA), como Ivanti, en lugar de realizar su propia evaluación independiente.

Desde el anuncio, he escuchado tres versiones de la misma respuesta por parte de clientes y colegas. Las tres son variaciones de un programa diseñado para un mundo que avanzaba más despacio.

«Tenemos un escáner de vulnerabilidades»

Qualys, Rapid7 y Tenable realizan bien el descubrimiento de vulnerabilidades. Los escáneres encuentran, señalan, puntúan y enumeran. El despliegue, la verificación, la gestión de reinicios y la reversión quedan fuera de su alcance. Ese trabajo sigue teniendo que realizarse en algún lugar. En la mayoría de los programas, se lleva a cabo en una herramienta distinta, con un equipo distinto y a una cadencia distinta.

Con la ventana de explotación reducida ahora a horas y la cola de Glasswing a punto de duplicar el backlog, un escáner que genera 587 vulnerabilidades críticas y entrega la lista a un equipo humano es un lastre. La medida práctica es conectar el escáner que ya tiene a un motor de remediación que pueda actuar automáticamente sobre sus hallazgos. Una plataforma de gestión autónoma de endpoints (AEM), con despliegue por anillos y reversión, e inteligencia de vulnerabilidades para aportar contexto basado en el riesgo a decisiones de remediación eficientes, de modo que la lista se reduzca sin que una persona tenga que tomar cada decisión.

«Gestionamos las aprobaciones a través de nuestro sistema de tickets»

Hablando de personas que tienen que tomar decisiones… Los procesos de aprobación largos y lineales van a ralentizar considerablemente el proceso de remediación. ¿Cuándo fue la última vez que tuvo que decidir si iba a desplegar la última actualización del sistema operativo o del navegador?

Las organizaciones ya saben que van a desplegar estas actualizaciones. A menudo, el proceso de aprobación se debe a políticas internas complejas y a una falta de alineación en torno a los resultados de seguridad. ¿El resultado? Un proceso muy lineal que requiere el escáner de vulnerabilidades mencionado anteriormente, un analista que apruebe lo que ya se sabe que debe hacerse, tickets enviados a los responsables de negocio para su aprobación y acumulados en bandejas de entrada a la espera de aprobación y, en última instancia, tiempo valioso desperdiciado en una decisión que, en esencia, ya estaba bien entendida y no era necesario tomar.

El cambio del mercado hacia la gestión de la exposición aborda este proceso de forma muy distinta, centrándose en definir el apetito de riesgo de una organización y supervisar su postura de riesgo. La próxima vez que se publique una actualización del sistema operativo Windows, ya sabrá que la desplegará, el calendario en que lo hará y los SLA y métricas de cumplimiento con los que medirá el éxito. Lo que realmente quiere saber es:

1. ¿Debemos avanzar más rápido porque la actualización incluye vulnerabilidades explotadas conocidas?

O

2. ¿La actualización está afectando a las operaciones y debemos ralentizar el ritmo (afortunadamente, la plataforma de gestión autónoma de endpoints incluye despliegue por anillos con reversión)?

«Tenemos Intune»

Microsoft Intune tiene dos límites de alcance que importan en este contexto.

En primer lugar, solo gestiona los dispositivos inscritos en él. Los endpoints no inscritos y no gestionados —servidores, portátiles de contratistas, TI en la sombra, dispositivos perimetrales desatendidos— quedan completamente fuera de su visibilidad. Durante periodos de mayor volumen de vulnerabilidades, esos puntos ciegos se multiplican más rápido de lo que los equipos pueden gestionar manualmente.

En segundo lugar, aunque Intune simplifica el despliegue y las actualizaciones de aplicaciones, su cobertura de aplicaciones de terceros y su profundidad de priorización son más limitadas de lo que la mayoría de los administradores cree. Intune puede indicarle qué está desactualizado, pero no qué aumenta realmente su exposición––lo que obliga a los equipos a parchearlo todo de forma reactiva o a basarse en conjeturas cuando el tiempo escasea.

La mayoría de los entornos empresariales no son exclusivamente Windows, no están plenamente inscritos ni ejecutan una pila de aplicaciones pequeña y homogénea. Cuando se disparan las divulgaciones de vulnerabilidades, canalizar así la aplicación de parches deja brechas y se convierte en un riesgo sistémico.

Mantenga Intune. Combínelo con una capa de descubrimiento y remediación que encuentre los activos que Intune no puede ver, priorice las vulnerabilidades más importantes y aplique parches con confianza en las aplicaciones que Intune no cubre.

Qué hacer al respecto

La automatización es el modelo operativo. Debe estar integrada en el flujo de trabajo.

Los profesionales conocen el principio desde hace tiempo. Se manifiesta en tres ámbitos:

  • Triaje continuo. Las vulnerabilidades explotadas conocidas pueden seguir una vía de respuesta a zero-days, especialmente en las partes menos seguras de la organización, como los sistemas de usuario final. Además, establezca y defina aplicaciones concretas, como navegadores y aplicaciones de telecomunicaciones, para que se actualicen por una vía prioritaria que se revise semanalmente o incluso a diario. Todo lo demás puede esperar a la ventana de mantenimiento habitual.
  • Despliegue por anillos con reversión automatizada. Anillo de pruebas, anillo de primeros usuarios, producción amplia, misión crítica. La secuencia es poco llamativa, pero funciona para la mayoría de las tareas de mantenimiento. Lo que ha cambiado es que determinadas actualizaciones tendrán que comprimirse para ajustarse a la ventana de explotación, en lugar de esperar al mantenimiento mensual. El anillo de pruebas debe estar automatizado e instrumentado; una lista de comprobación manual no puede moverse a esa velocidad.
  • Verificación de ciclo cerrado. El parche no se considera desplegado hasta que se verifica su instalación en el endpoint, y la CVE no se cierra hasta que un nuevo análisis lo confirma. La mayoría de los equipos se saltan ese paso, por eso las evidencias de cumplimiento se convierten en una urgencia la semana anterior a la auditoría. Por eso esta semana hemos lanzado el cumplimiento continuo en nuestra plataforma: para que las evidencias de cumplimiento se generen de forma continua y automática a medida que se despliegan los parches, con la automatización encargándose de las decisiones de priorización para las que la mayoría de los equipos no tiene capacidad.

Las 271 vulnerabilidades de Firefox de Mozilla son un anticipo. Todos los grandes proveedores de software bajo Glasswing están a punto de empezar a corregir más vulnerabilidades y a un ritmo acelerado, y los atacantes con la misma clase de capacidad buscarán exactamente esas brechas siempre que obtengan acceso a un modelo similar. La carrera armamentística de IA resultante tendrá un efecto directo en el número y la frecuencia de las actualizaciones que las organizaciones tendrán que remediar, y a un ritmo acelerado. La automatización es lo que permite sostener un programa. A los equipos que todavía se limitan a aplicar parches mensualmente les espera una etapa complicada.

Si dirige un programa de TI o seguridad, merece la pena realizar la autoevaluación ahora. Tome el último parche crítico que desplegó. Mejor aún: si se publicara un zero-day un viernes, ¿podría remediarlo antes del lunes? Mida el tiempo desde la publicación de la CVE hasta la instalación verificada en el último endpoint. Si esa cifra se mide en semanas, el apocalipsis de los parches va a alcanzarle.