La inteligencia artificial está transformando la investigación de vulnerabilidades, pero la mayoría de los debates se mantienen en un plano teórico: lo que un modelo podría llegar a hacer, en lugar de lo que realmente puede lograr hoy. El equipo de Intruder decidió responder a una pregunta más práctica: usando los modelos ya disponibles, ¿hasta dónde puede llegar la IA para encontrar vulnerabilidades reales y explotables en software de producción?
Este artículo detalla cómo Intruder utiliza modelos de lenguaje (LLMs) junto con marcos de análisis de código para descubrir vulnerabilidades novedosas. Presentan un hallazgo concreto: una inyección SQL ciega remota de múltiples etapas en un plugin de WordPress con más de 300.000 usuarios, detectada y explotada de forma totalmente automatizada, sin intervención humana.
El problema del enfoque: por qué apuntar la IA a todo el código no funciona
El gran desafío al combinar IA con un escáner de código es la concentración. Los LLMs son excelentes para analizar fragmentos pequeños de código o descripciones de problemas específicos, pero si se les pide examinar una base de código completa en busca de fallos de seguridad, intentarán ingerir todos los archivos del repositorio. Esto resulta caro en tokens y perjudica la precisión: cuando el modelo llega a la mitad, su contexto está lleno de código irrelevante y el bug real queda sepultado entre el ruido.
Para bugs complejos que requieren encadenar varios pasos, es necesario que el marco mantenga el contexto adecuado en memoria o lo recupere inteligentemente. En la experiencia de Intruder, eso produce resultados pobres en lugar de bugs reales e interesantes. Los escáneres de código tradicionales ya resuelven este problema: utilizan una técnica llamada 'program slice', similar a cuando un IDE o herramienta LSP emplea funciones como 'buscar implementación' o un grafo de llamadas para localizar todas las funciones invocadas por una función dada. Estas herramientas son maduras y evitan por completo el problema del contexto diluido.
El pipeline: de la base de código al exploit funcional
Intruder construyó un pipeline que toma una base de código, la procesa con el motor de análisis Joern, genera fragmentos de código relevantes para cada hallazgo, y utiliza un LLM para clasificar y explotar el problema. El diseño se inspiró en el trabajo de nooperator sobre Slice, aunque usan Joern en lugar de CodeQL y adaptaron el algoritmo de fragmentación para manejar clases específicas de vulnerabilidades.
El equipo probó el pipeline con los 200 plugins de WordPress más populares, código ya muy revisado por cazadores de bugs, para demostrar que el proceso puede competir con investigadores humanos. Joern se ejecuta con reglas que marcan patrones 'interesantes' de forma deliberadamente amplia, para no perder bugs. Como el agente de clasificación filtra después, se permiten falsos positivos. Para este experimento, buscaban superficie de ataque no autenticada en plugins de WordPress: rutas REST, hooks de plantillas, llamadas AJAX nopriv, etc.
Para cada hook de WordPress, Joern genera un fragmento: la función que llama el hook, todos los métodos que esta función invoca, y así sucesivamente. Reglas básicas de rastreo de datos descartan funciones obviamente seguras, como entradas SQL o XSS que pasan por un sanitizador conocido. Cuando se puede verificar estáticamente que el código es seguro, esos fragmentos pasan a un LLM.
Cada fragmento es evaluado por un modelo ligero (Sonnet en sus pruebas) para filtrar lo obviamente no interesante, como hooks públicos sin efectos secundarios. Lo que queda pasa a un modelo más pesado (Opus) que evalúa la explotabilidad, con el contexto completo de llamadas relevante en memoria. Cualquier elemento considerado explotable se envía a un agente final de explotación, que tiene acceso al código fuente completo para búsquedas específicas y puede levantar un contenedor Docker con el software para probar el exploit mientras lo desarrolla.
La primera vulnerabilidad: una inyección SQL ciega en un plugin popular de WordPress
El primer bug que produjo el pipeline fue CVE-2026-3985, una inyección SQL en el plugin Creative Mail. Destaca por varias razones: es de alto impacto, pues da acceso de lectura a la base de datos (incluyendo hashes de administradores y tokens secretos); requiere múltiples solicitudes encadenadas para explotarse, lo que dificulta su detección por herramientas tradicionales; y la causa raíz estaba oculta para las herramientas de análisis estático del desarrollador debido a un error en su código.
La explotación requiere que WooCommerce esté instalado junto con Creative Mail, pero como WooCommerce tiene más de 7 millones de instalaciones activas, la combinación es común. El agente de explotación generó una prueba de concepto funcional en un solo intento, produciendo una verificación de la existencia del problema y un método completo de extracción capaz de obtener hashes de contraseñas de la base de datos.
Esta vulnerabilidad también fue descubierta de forma independiente por Dmitrii Ignatyev de CleanTalk Inc., quien la reportó a Wordfence. El plugin ha sido retirado de la tienda de WordPress pendiente de revisión; si usas Creative Mail junto con WooCommerce, desactívalo hasta que haya un parche disponible.
El descubrimiento se acelera. La detección debe seguir el ritmo
Esta es solo la primera vulnerabilidad que ha producido el pipeline. Ya se están encontrando más y reportándolas a los proveedores afectados, aunque aún están bajo divulgación responsable. La IA tiene claramente un papel creciente en la investigación de vulnerabilidades, y el trabajo actual consiste en construir los marcos adecuados para aprovechar al máximo los modelos existentes. Los atacantes ya utilizan herramientas similares para alimentar a la IA con datos de alta calidad, por lo que la misma ventaja de velocidad demostrada aquí no es exclusiva de los defensores.
Las vulnerabilidades descubiertas por esta máquina expendedora se convierten en comprobaciones de detección en la plataforma Intruder, de modo que el próximo escaneo las encuentre y las reporte.