FORGE: un pipeline multiagente que convierte CVE en exploits y detecciones

¿Qué es esto?

El 2 de junio de 2026, Farooq Shaikh, investigador de Dynatrace, publicó FORGE: Multi-Agent Graduated Exploitation and Detection Engineering (arXiv:2606.03453), aceptado en el taller AgentCy de la conferencia ARES 2026. El artículo aborda un problema de cadena de producción más que una vulnerabilidad aislada: el volumen de CVE divulgadas supera ya con creces la capacidad de evaluación de las organizaciones, mientras que las tres comunidades que deberían cooperar —generación de pruebas de concepto, priorización de vulnerabilidades e ingeniería de reglas de detección— trabajan en su mayoría en silos.

FORGE intenta conectar esas tres etapas en un único pipeline de agentes LLM. Lo interesante para los defensores no es que un agente sepa escribir un exploit; es que la misma ejecución produzca una regla de detección junto con un veredicto graduado y auditado sobre la profundidad real de la explotación. El código completo, los resultados por CVE y los veredictos de auditoría del oráculo se publican bajo licencia Apache 2.0 en github.com/dynatrace-oss/forge.

Cómo funciona

FORGE ejecuta cinco agentes especializados en un pipeline fijo, cada uno consumiendo la salida del anterior:

1. Intel — ingiere los metadatos de una CVE (texto del aviso, componentes afectados) y extrae los hechos estructurados que necesitan las etapas posteriores.
2. Generator — construye una aplicación vulnerable objetivo: una aplicación mínima y autónoma que reproduce el fallo, de modo que la explotación se ejecuta contra un objetivo de laboratorio dedicado y no contra el sistema de nadie en producción.
3. Planner — convierte la inteligencia en una estrategia de explotación.
4. Exploit — realiza un intento guiado y de varios turnos contra el objetivo generado.
5. Detector — elabora una regla de detección a partir de lo que produjo la explotación.

El elemento novedoso es lo que el artículo llama explotación graduada: en lugar de un binario «funcionó o no», un oráculo de predominio LLM puntúa cada intento sobre una taxonomía de cuatro niveles, desde L0 (sin evidencia de explotación) hasta L3 (compromiso total). Puntuar la profundidad del éxito, y no solo el éxito o el fracaso, es lo que permite al pipeline priorizar: una CVE que un agente puede llevar hasta L3 sobre una reproducción fiel constituye una señal operativa muy distinta de una que se estanca en L1. Como la explotación nunca se ejecuta más que contra el objetivo sintético del Generator, el bucle produce evidencias y detecciones sin tocar software en producción.

Por qué importa

FORGE se sitúa en la misma categoría emergente que los trabajos recientes sobre agentes que cazan o trian vulnerabilidades: benchmarks de caza de bugs de horizonte largo, detección de vulnerabilidades orientada a especificación y la sobria constatación de que los agentes genéricos siguen perdiendo frente a las herramientas SAST deterministas. Lo que FORGE añade es el puente entre una vulnerabilidad y una detección desplegable, acompañado de una señal de confianza graduada.

Ese puente funciona en ambos sentidos. Para un SOC, un camino automatizado entre «acaba de aparecer una CVE nueva» y «una regla de detección candidata más una reproducción contra la que probarla» es realmente útil, y comprimir la evaluación de explotabilidad de semanas a horas coincide con lo que reportan los trabajos de red teaming agéntico. Pero la misma arquitectura es una plantilla que los atacantes pueden copiar: un pipeline que lee un aviso y avanza hacia un exploit funcional es precisamente la industrialización de la ofensiva que anticipan los artículos de modelado de amenazas. La publicación open source baja la barrera tanto para defensores como para adversarios —es la tensión estándar e inevitable de toda herramienta ofensiva publicada—, y por eso la transparencia de la evaluación y de la auditoría del oráculo importa tanto como los resultados de explotación.

Defensas

Para los equipos que leen FORGE como defensores y no como constructores de herramientas:

1. Trate la salida de detección como un borrador, no como una regla lista para desplegar. Una detección generada por LLM refleja una sola reproducción sintética; valídela contra telemetría real y ajústela frente a falsos positivos antes de que condicione nada, la misma cautela que se aplica a la salida de un LLM-escáner.
2. No confíe ciegamente en la puntuación. El veredicto L0–L3 proviene de un oráculo de predominio LLM; el artículo publica sus veredictos de auditoría precisamente para que puedan verificarse. Use la puntuación graduada para priorizar la revisión humana, no para sustituirla.
3. Asuma que los atacantes tienen el mismo pipeline. Si una CVE de su stack es del tipo que agentes al estilo de FORGE pueden llevar hasta L3 sobre un clon fiel, ajuste la urgencia del parche en consecuencia: el margen de evaluación que antes le daba tiempo se está reduciendo.
4. Mantenga la generación en un entorno aislado. La propiedad de seguridad del diseño es que la explotación solo se ejecuta contra objetivos construidos para la ocasión. Cualquier adaptación interna de este esquema debe preservar ese aislamiento y nunca apuntar el agente Exploit a infraestructura viva o compartida.
5. Alimente la priorización con resultados graduados, no solo con el recuento de tickets. El objetivo de la taxonomía de cuatro niveles es separar lo teóricamente explotable de lo demostrablemente explotable; úsela para clasificar la remediación.

Estado

Elemento	Referencia	Fecha	Notas
Artículo	arXiv:2606.03453	2026-06-02	Taller AgentCy, ARES 2026
Pipeline	Intel → Generator → Planner → Exploit → Detector	2026-06-02	Cinco agentes, orden fijo
Puntuación	L0 (sin evidencia) → L3 (compromiso total)	2026-06-02	Oráculo de predominio LLM, auditado
Código	github.com/dynatrace-oss/forge	2026-06-02	Apache 2.0, con repositorio de artefactos

En resumen: FORGE es menos un nuevo ataque que una demostración de que el bucle CVE → exploit → detección puede automatizarse de extremo a extremo con los agentes LLM actuales —y graduarse en confianza por el camino—. Para los defensores, el valor práctico es una ingeniería de detección más rápida y priorizada; el riesgo simétrico es que el mismo plano comprime por igual el calendario ofensivo, de modo que las hipótesis de priorización de parches basadas en un desarrollo de exploit lento merecen una segunda mirada.