Claude Mythos expuso una dura verdad: el proceso de parcheo de su empresa es demasiado lento

En 2024, investigadores de la Universidad de Illinois descubrió que GPT-4, cuando se le proporciona una descripción de vulnerabilidades y exposiciones comunes (CVE), podría explotar de forma autónoma el 87% de un conjunto de datos de un día curado de 15 vulnerabilidades. Sin la descripción, sólo podría explotar el 7%. Esto proporcionó un “margen de seguridad” para la industria porque, si bien la IA podía explotar vulnerabilidades conocidas, no podía descubrirlas.

Sin embargo, el 7 de abril Antrópico anunciado que Claude Mythos Preview había cerrado ese margen, con el modelo descubriendo de forma autónoma miles de vulnerabilidades de día cero en los principales sistemas operativos y navegadores. Por otra parte, Mythos obtuvo una puntuación del 83,1 % en el punto de referencia de reproducción de vulnerabilidades de CyberGym. En una campaña dirigida a OpenBSD en 1.000 ejecuciones de scaffolding, el costo total de computación fue inferior a 20.000 dólares.

Los plazos de explotación se están derrumbando. El CVE-2026-33017 (CVSS 9.8) de Langflow fue explotado 20 horas después de la divulgación sin prueba pública de concepto. El CVE-2026-39987 (CVSS 9.3) de Marimo fue Golpe en 9 horas y 41 minutos..

La infraestructura defensiva en la que confían la mayoría de las organizaciones no fue diseñada para esto. Informe sobre el panorama de amenazas de Rapid7 para 2026 afirma que el tiempo medio desde la publicación de CVE hasta el listado de vulnerabilidades explotadas conocidas (KEV) de CISA es de cinco días. M-Trends de Google 2026 El informe encontró que la explotación ocurre incluso antes de que se lance un parche. Cuando se publicó el aviso de Langflow, el primer exploit llegó en 20 horas. Cuando se publicó el aviso de Marimo, tomó menos de 10 horas.

La suposición de que su ventana de parche es segura porque la explotación lleva tiempo ya no es cierta. Aquí están sus componentes básicos.

Reemplace la priorización solo CVSS con un filtro de tres capas

La mayoría de los programas de gestión de vulnerabilidades todavía priorizan únicamente según la puntuación CVSS. CVSS cuantifica la gravedad «teórica» ​​de una vulnerabilidad sin considerar si una vulnerabilidad está siendo explotada en la naturaleza o qué tan rápido alguien podría convertirla en un arma. Una vulnerabilidad CVSS 8.8 con un historial de explotación activa (como Docker’s CVE-2026-34040) tiene menor prioridad que una vulnerabilidad CVSS 9.8 que quizás nunca se explote en la naturaleza.

A estudio reciente validado contra 28,377 vulnerabilidades del mundo real ofrece un reemplazo concreto: un árbol de decisión de tres capas que incorpora el estado CISA KEV, puntuaciones del sistema de puntuación de predicción de exploits (EPSS) y CVSS, formando así un filtro de priorización singular.

Filtro de priorización de vulnerabilidades de tres capas

Resultado validado: aumento de eficiencia 18 veces mayor, cobertura del 85,6 % de las vulnerabilidades explotadas, reducción de ~95 % en la carga de trabajo de remediación urgente. Las tres fuentes de datos son abiertas y gratuitas.

La integración descrita es completamente automatizable. Es posible crear un script para consultar la API CISA KEV, la API EPSS de FIRST.org y la NVDy haga que ese script se ejecute en su inventario de activos para cada CVE publicado. El ser humano en este proceso debe permanecer informado como aprobador, pero no como desencadenante.

Cerrar la brecha de autorización de agentes

La creación rápida de exploits no solo cambia la forma en que se priorizan los parches, sino también la forma en que se configuran los controles para todos los sistemas controlados por agentes que ahora poseen credenciales privilegiadas. Sus políticas de autorización no se han evaluado con respecto al comportamiento de los agentes de IA, y ese es ahora un riesgo mensurable. CVE-2026-34040 mostró que la arquitectura del complemento de autorización de Docker omite silenciosamente todos los complementos cuando el cuerpo de la solicitud supera 1 MB. Los complementos comunes de AuthZ (OPA, Casbin, Prisma Cloud) desconocen este tipo de omisión, que ocurre en el middleware de Docker antes de que la solicitud llegue al complemento.

Cuando Cyera demostró esta vulnerabilidaddemostraron que una infraestructura de depuración de un agente de IA podía inferir la ruta de derivación mientras completaba una tarea legítima, sin ninguna instrucción para explotar nada.

El Grupo de Trabajo de Ingeniería de Internet (IETF) está trabajando en modelos de autorización para agentes. el documento borrador-klrc-aiagent-auth-01publicado en marzo por participantes de AWS, Zscaler, Ping Identity y OpenAI, propone el uso del actual Secure Production Identity Framework for Everyone (SPIFFE) y OAuth 2.0 para que los agentes de IA obtengan credenciales de corta duración y aprovisionadas dinámicamente.

Por otra parte, el IETF Borrador del protocolo de identidad del agente (draft-prakash-aip-00) informa que de aproximadamente 2000 servidores de protocolo de contexto modelo (MCP) encuestados, ninguno tenía autenticación.

Pero faltan meses o años para que estas normas se implementen. Por ahora, los equipos de seguridad deben incorporar de manera proactiva escenarios de prueba a nivel de agente para todos los límites de autorización, como solicitudes de gran tamaño, frecuencia de ráfagas y escalamiento de solicitudes privilegiadas en varios pasos.

Mapee el radio de explosión de su credencial

en un encuesta realizada por CSA/Zenity y publicado el 16 de abril, el 53% de las organizaciones dijeron que ya habían visto casos en los que los agentes de IA excedieron los permisos previstos y el 47% experimentó un incidente de seguridad que involucró a un agente.

Cuando las herramientas de creación de IA, como fluir (CVE-2025-59528, CVSS 10.0), Langflow o n8n se ven comprometidos, el radio de la explosión se extiende mucho más allá del host. Estas herramientas contienen claves API para modelos fronterizos, credenciales de bases de datos, tokens de almacenamiento de vectores y tokens OAuth para sistemas empresariales. Un host de un generador de IA comprometido no es solo una infracción de un solo sistema. Es una recolección de credenciales que desbloquea el acceso autenticado a cada servicio conectado.

Sin mapas de dependencia de credenciales para cada host de herramientas de IA, la respuesta a incidentes que comprometan a los agentes es una conjetura. Para cada caso, documente cada credencial, el alcance de su acceso y el proceso de rotación de credenciales relevante. También comience a migrar claves API estáticas a tokens de corta duración cuando los servicios posteriores lo permitan.

Cinco acciones para este trimestre

1. Implemente el filtro KEV-EPSS-CVSS de tres capas

Sustituya la priorización solo CVSS según la tabla anterior. Automatice la recopilación de datos de las tres API como parte de un script programado en su inventario de activos. Resultado deseado: 18 veces más eficiente, 85,6 % de cobertura de vulnerabilidades explotadas, 95 % de reducción en la carga de trabajo de remediación urgente.

2. Implementar parches basados ​​en eventos para los servicios de Nivel 0.

Determine qué servicios se incluyen en el nivel de exposición crítica: servicios expuestos directamente a los usuarios de Internet, hosts de creación de IA y plano de control de orquestación de contenedores. Active la aplicación de parches basados ​​en eventos en una publicación CVE en lugar de esperar a la siguiente ventana de mantenimiento para este nivel.

Objetivo: implementar el parche en canary dentro de las cuatro horas posteriores a la declaración crítica de un CVE. Utilice los feeds CISA KEV y EPSS para activar parches basados ​​en eventos. En situaciones en las que es imposible cumplir el objetivo de aplicar parches de cuatro horas debido a dependencias heredadas, ventanas de congelación de cambios o riesgo de reversión, aplique inmediatamente controles de compensación, como eliminar la exposición de Internet al servicio vulnerable, rotar las credenciales para el servicio vulnerable, deshabilitar la funcionalidad afectada del servicio (si corresponde) e identificar un propietario de excepción para la exposición hasta que se pueda implementar un parche.

No es aceptable permitir exposiciones ilimitadas durante períodos prolongados mientras se espera una ventana de mantenimiento.

3. Probar los límites de autorización a escala de agente.

Cree casos de prueba para cada API con la que los agentes de IA puedan comunicarse a través de políticas de AuthZ. Específicamente, incluya casos de prueba para solicitudes que superen los tamaños de cuerpo de 1 MB, 5 MB y 10 MB. Esto incluye casos de prueba para velocidades de ráfaga > 100 solicitudes por segundo y casos de prueba para combinaciones de parámetros inusuales (indicadores privilegiados, montajes de host, adiciones de capacidad). Además, parche para Docker Engine 29.3.1 para arreglar CVE-2026-34040.

4. Mapeo del radio de explosión de credenciales para todos los hosts del constructor de IA.

Documente cada credencial para cada instancia de canalización de IA personalizada y Langflow, Flowise, n8n. Clasifique cada credencial según su vida útil (clave estática frente a token de corta duración). Identifique a qué puede acceder cada credencial. Configure alertas de IP o identidad anómala para cualquier acceso a credenciales.

5. Escaneo de descubrimiento de Shadow AI para esta semana.

Según los datos de CSA, existe una probabilidad superior al 50% de que sus agentes hayan excedido sus límites esperados. Verifique su información de seguridad y administración de eventos (SIEM) y sus herramientas de monitoreo de red para ver las comunicaciones con los puertos predeterminados del generador de IA: Langflow 7860, Flowise 3000 y n8n 5678. Cualquier instancia no autorizada es una superficie de ataque no monitoreada.

la comida para llevar

Los agentes de IA están surgiendo y tLos organismos de normalización están respondiendo. El IETF tiene múltiples borradores relacionados con la autenticación y autorización de agentes. El Coalición para una IA segura ha publicado su Taxonomía de seguridad de MCP y Principios de seguridad por diseño.

Pero estos estándares se mueven a la velocidad del cuerpo estándar, y la ventana de explotación ahora se mide en horas. Las organizaciones que implementen el filtro de tres capas y los parches basados ​​en eventos este trimestre tendrán una reducción mensurable en la exposición. Aquellos que esperen ejecutarán ciclos de parches basados ​​en calendarios contra un adversario que opera en menos de 20 horas.

Nik Kale es un ingeniero principal especializado en seguridad y plataformas de inteligencia artificial empresarial.

¡Bienvenido a la comunidad VentureBeat!

Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten conocimientos y brindan análisis profundos neutrales y no adquiridos sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que dan forma al futuro de las empresas.

Leer más de nuestro programa de publicaciones de invitados y consulte nuestro pautas ¡Si estás interesado en contribuir con un artículo propio!