Los mismos modelos que descubren vulnerabilidades de día cero ya sirven para atacar y para defender

Entre el 1 y el 4 de septiembre de 2026, Anthropic, Google y OpenAI lanzaron, en menos de 72 horas, tres modelos de IA capaces de encontrar vulnerabilidades de software por su cuenta y, en algunos casos, convertirlas en exploits funcionales. Uno de ellos, GPT-6 Astra, sacó 100% en ExploitBench, el benchmark que mide si un modelo puede transformar una falla conocida en un ataque que funciona, y cruzó el umbral que la propia OpenAI llama "Critical" en su marco de seguridad. Para quien administra TI o seguridad en una empresa mediana, esto no es una noticia de laboratorio: acorta el tiempo que pasa entre que una vulnerabilidad existe y que alguien la explota, y esa misma capacidad la tienen tanto los equipos de defensa como quien quiera atacar.

Qué se anunció, modelo por modelo

Anthropic publicó el 1 de septiembre dos versiones del mismo modelo con distintos niveles de resguardo: Claude Fable 5.1, de acceso público, que puede identificar vulnerabilidades de software pero no desarrollar exploits, y Claude Mythos 5.1, limitado a organizaciones de Estados Unidos inscritas en programas de acceso confiable, con capacidades más amplias de investigación de amenazas y red teaming. Anthropic reporta que Claude Code, con las nuevas salvaguardas, genera alrededor de 60% menos falsos positivos de ciberseguridad, según la página oficial de Fable 5.1 y Mythos 5.1.

Google lanzó el 2 de septiembre Gemini 3.8 Flash Cyber, restringido a un programa llamado Fairwind. Según el anuncio oficial de Fairwind, el programa ya reúne a más de 650 organizaciones en todo el mundo, entre ellas CrowdStrike, Datadog, Menlo Security, Palo Alto Networks y Snowflake, y da prioridad a gobiernos, operadores de infraestructura crítica y mantenedores de software ampliamente usado. En CyberGym, el benchmark de referencia para descubrimiento autónomo de vulnerabilidades, el modelo obtuvo 86.2% frente a 77.5% de su predecesor. Google lo combina con CodeMender, su agente de remediación automática de código.

OpenAI cerró la semana con GPT-6 Astra el 3 y 4 de septiembre. Es el primer modelo comercial que cruza el umbral "Critical" de riesgo cibernético definido en su Preparedness Framework, la clasificación que la compañía reserva para sistemas capaces de detectar y explotar fallas de día cero sin guía humana paso a paso. La versión pública queda limitada a revisión y parcheo de código seguro, y rechaza generar exploits de prueba de concepto; OpenAI anunció que irá relajando esa restricción para defensores verificados a través de un programa llamado Daybreak, con un compromiso de mil millones de dólares para infraestructura crítica: sistemas de agua, electricidad, gobiernos estatales y locales, bancos, organizaciones sin fines de lucro y mantenedores de código abierto, con un piloto junto al Multi-State Information Sharing and Analysis Center de Estados Unidos. Los detalles completos están en la cobertura de The Hacker News sobre los tres lanzamientos y en el reporte específico sobre Astra y ExploitBench.

Los números que importan

Modelo	Benchmark clave	Resultado	Referencia previa
GPT-6 Astra	ExploitBench	100%	78.5% (GPT-5.6 Sol)
GPT-6 Astra	Rechazo de jailbreak	91.5%	59% (GPT-5.6 Sol)
Gemini 3.8 Flash Cyber	CyberGym	86.2%	77.5% (Gemini 3.5 Flash Cyber)
Gemini 3.8 Flash Cyber	Parches correctos en Chrome Security	2.6x más que modelos comerciales grandes	No aplica

Estas cifras dicen dos cosas a la vez. La primera: encontrar y explotar fallas conocidas pasó de ser un proceso que tomaba semanas de trabajo especializado a algo que un modelo hace en minutos con una tasa de acierto casi perfecta. La segunda, menos citada: los tres laboratorios reconocen que esa misma capacidad, sin control de acceso, es un arma. Por eso los tres restringieron el acceso a las versiones más potentes en vez de liberarlas por API abierta.

Por qué esto le pega a México ahora

El acortamiento de la ventana entre descubrimiento y explotación no es un problema abstracto en la región. Según reportes disponibles, México registró ataques de ransomware significativos en el primer semestre de 2026 con una posición destacada en la región. Sin embargo, al momento de publicar, la fuente citada no está disponible para verificación (Error 403), y las estadísticas específicas (casi 80 ataques, 17.93% de incidentes regionales) no pudieron ser confirmadas en fuentes públicas consolidadas mexicanas. A nivel global se reportaron múltiples ataques de ransomware en el primer semestre de 2026. Sin embargo, la cifra específica de 4,699 ataques y el incremento del 16.5% no pudieron ser verificados en las fuentes de seguridad disponibles.

Si la explotación de vulnerabilidades conocidas se automatiza y se acelera del lado ofensivo, la ventana que un equipo de TI tiene entre que un fabricante publica un parche y que alguien lo explota se reduce. Eso ya venía siendo un problema antes de estos lanzamientos: hace poco cubrimos una falla crítica en SAP con CVSS 10.0 que obligó a revisar el parche de emergencia en cuestión de días y el Patch Tuesday de Microsoft que coincidió con ataques activos a la cadena de suministro de npm. Con modelos que automatizan la parte de encontrar y armar el exploit, el margen para reaccionar con procesos trimestrales de gestión de vulnerabilidades desaparece.

Qué revisar en tu operación, en orden

1. Confirma cómo priorizas hoy. Si tu equipo revisa vulnerabilidades por lote o por ciclo trimestral, ese ritmo ya no corresponde a una amenaza que se mueve en horas. Pregunta a tu proveedor de seguridad o a tu equipo interno cuánto tiempo pasa, en promedio, entre que un CVE se publica y que alguien lo revisa en tu inventario.
2. Pide el inventario de activos expuestos, no solo el reporte de escaneo. Un escaneo mensual no sirve si no sabes qué sistemas están expuestos a internet ahora mismo. Sin inventario actualizado, cualquier alerta de vulnerabilidad crítica llega sin contexto de a qué te pega.
3. Pregunta qué modelo o herramienta usa tu proveedor y bajo qué acceso. Los tres programas mencionados aquí (Fairwind de Google, los programas de acceso confiable de Anthropic, Daybreak de OpenAI) son de acceso restringido. Si un proveedor te dice que ya tiene acceso a capacidades de nivel "Critical", pide evidencia de en qué programa está inscrito y qué controles aplica.
4. Separa detección de remediación. Detectar una vulnerabilidad con IA es la parte fácil; automatizar el parcheo o la mitigación sin romper el sistema es la parte que decide si la ventana de exposición se cierra en horas o en semanas.
5. Revisa el gasto, no solo el modelo. Meter IA a un pipeline de escaneo tiene un costo recurrente de cómputo que crece con el volumen de código y activos que se revisan; conviene presupuestarlo como línea operativa, no como gasto único. Si estás calculando el presupuesto de un proyecto así, ya cubrimos cómo presupuestar un proyecto agéntico en 2026.

Dónde esto no aplica

Si tu empresa no expone software propio a internet, sino que opera sobre plataformas de terceros ya parchadas por su proveedor (un ERP en la nube, un CRM de suscripción), el riesgo directo de descubrimiento de día cero en tu código es bajo: tu exposición está más en la configuración y en los accesos que en el código fuente. Ahí el problema no se resuelve con un modelo de detección de vulnerabilidades, sino con gestión de identidades y permisos.

Tampoco tiene sentido contratar acceso a estos modelos si no existe ya un proceso de gestión de vulnerabilidades funcionando: ningún modelo de descubrimiento automático sirve si nadie revisa las alertas que genera ni hay quien las traduzca en parches aplicados. Comprar la herramienta antes de tener el proceso es gastar en algo que nadie va a operar. Y ninguno de estos tres modelos, por sí solo, certifica que una empresa cumple con un marco regulatorio o contractual de seguridad; eso sigue dependiendo de auditoría, documentación y evidencia operativa, no de qué motor de IA corre por debajo.

La respuesta operativa a este cambio no es instalar un modelo de IA y darlo por resuelto: es gestión continua, con escaneo automatizado, priorización clara y un proceso de remediación que efectivamente corre. En hivek construimos ese tipo de pipeline para una empresa de ciberseguridad que necesitaba llevar su producto de la idea a la operación, con escaneo automatizado de vulnerabilidades e IA que orquesta las pruebas y propone remediaciones a la medida; si tu proceso de gestión de vulnerabilidades todavía depende de revisiones manuales o de reportes que llegan tarde, aplicamos IA a ese proceso de detección y remediación.

La pregunta que le queda a cada director de TI no es si estos modelos existen, ya existen y están en producción. Es si su propio proceso de gestión de vulnerabilidades puede moverse a la misma velocidad que la herramienta que los va a probar, la use un atacante o su propio equipo.

Fuentes

• Google, Anthropic, and OpenAI Unveil Cyber AI Models, Safeguards, and Access Programs, The Hacker News
• GPT-6 Astra Scores 100% on ExploitBench as OpenAI Blocks PoC Exploit Requests, The Hacker News
• Fairwind Program: Cyber defense tools for trusted partners, Google
• Introducing Claude Fable 5.1 and Claude Mythos 5.1, Anthropic
• Ransomware en México: el segundo país más atacado por ransomware, Ransomware Help