Máquina expendedora de vulnerabilidades: una IA que encuentra y explota zero-days
El 15 de julio de 2026, Intruder detalló un pipeline con LLM que por sí solo sacó a la luz más de 300 fallos, incluida una inyección SQL sin autenticar en un plugin de correo de WooCommerce usado en más de 300 000 sitios WordPress.
¿Qué es esto?
El 15 de julio de 2026, la firma de seguridad Intruder publicó el informe de lo que denomina una máquina expendedora de vulnerabilidades: un pipeline automatizado que combina el análisis de programas clásico con grandes modelos de lenguaje y que, según el equipo, convierte tokens de IA en zero-days. La demostración es concreta, no aspiracional: el pipeline sacó a la luz más de 300 hallazgos en código real y, en al menos un caso, llevó un fallo desde el descubrimiento hasta un exploit funcional sin intervención humana.
El resultado principal es una inyección SQL sin autenticar, hasta ahora desconocida, en un plugin de marketing por correo para WordPress muy extendido, usado en más de 300 000 sitios. El fallo en sí recibió un identificador CVE y se divulgó públicamente en mayo de 2026; lo nuevo en la publicación de julio es la revelación de la maquinaria que lo produjo. Aquí informamos sobre una demostración de capacidad ofensiva por parte de un actor identificado, apoyada en vulnerabilidades ya documentadas públicamente, no un manual de instrucciones. No reproducimos la técnica de inyección.
Cómo funciona
El truco central del pipeline no es «pedir a un LLM que encuentre errores en este archivo». Entregar un repositorio entero a un modelo produce ruido: fallos alucinados, flujos de datos entre archivos pasados por alto y ventanas de contexto que se desbordan antes de alcanzar la ruta interesante. El enfoque de Intruder se basa en cambio en el code slicing —una técnica de análisis de programas que extrae solo las instrucciones relevantes para una variable o un punto sensible dado— para entregar al modelo un fragmento de código reducido y semánticamente completo en lugar de un repositorio entero. El LLM razona sobre ese fragmento acotado, propone vulnerabilidades candidatas y el marco intenta después validarlas.
Según el informe, la ejecución produjo un amplio abanico de tipos de fallo: ejecución remota de código sin autenticación, inyección SQL oculta tras anotaciones de supresión del linter, escalada de privilegios mediante el sistema de hooks de WordPress, falsificación de peticiones del lado del servidor (SSRF) y una cadena de ataque por degradación. El caso del plugin de correo es ilustrativo precisamente porque es el tipo de error que los escáneres tradicionales suelen pasar por alto: es no autenticado pero solo alcanzable cuando hay instalado un plugin de comercio electrónico complementario, y requiere varias peticiones encadenadas para activarse, de modo que ninguna firma de petición única se dispara. Cabe destacar que el equipo indica haber trabajado con modelos de frontera disponibles antes del nivel Mythos, lo que subraya que esta capacidad no depende de un modelo aún no publicado.
Por qué importa
Lo relevante es económico tanto como técnico. Help Net Security resumió la misma tendencia en mayo de 2026 con una cifra contundente —unos 20 dólares por zero-day ya es la realidad de los plugins de WordPress— y la imagen de la máquina expendedora hace explícito el incentivo: si encontrar un fallo cuesta unos pocos dólares de inferencia, rastrear todo un ecosistema de plugins se vuelve racional para los atacantes, no solo para los investigadores. El mercado de plugins de WordPress, con decenas de miles de extensiones de calidad de código muy dispar, es una superficie de ataque casi ideal para esto.
Es el espejo ofensivo de una tendencia que seguimos en el lado defensivo. Guarda paralelismo con la integración por parte de Microsoft del descubrimiento asistido por IA en el ciclo de parches de Windows, con la avalancha de informes de vulnerabilidades de código abierto impulsada por la IA y con pipelines de investigación como el descubrimiento en bucle cerrado OpenAnt de Knostic y el escaneo multimodelo MDASH de Microsoft. La misma capacidad que permite a un defensor anticipar los errores permite a un atacante «expenderlos»; el factor decisivo es quién ejecuta el pipeline y con qué rapidez responden los mantenedores. También encaja en el patrón de las huellas de zero-days redactados por IA: los fallos hallados por IA se están convirtiendo en una entrada habitual de la economía de la divulgación, no en un evento exótico.
Defensas
Para los mantenedores de plugins y aplicaciones, la lección accionable es que las causas raíz aquí son antiguas y corregibles. La inyección SQL existía porque una entrada de usuario llegaba a una consulta sin parametrizar: la mitigación estándar son las consultas preparadas ($wpdb->prepare() en WordPress) y una validación estricta de cada parámetro controlable desde el exterior, incluidos los que solo son alcanzables a través de un segundo componente instalado. No trate una anotación de supresión del linter como una medida de seguridad: el pipeline encontró precisamente una inyección oculta tras un comentario de exclusión de PHPCS, y suprimir una advertencia de análisis estático no elimina el error, solo lo oculta al siguiente revisor. Cartografíe las rutas de interacción entre plugins, porque «no autenticado pero explotable solo si también está presente el plugin X» es exactamente la condición compuesta que las herramientas automatizadas ya destacan encontrando y que la revisión humana tiende a omitir.
Para los operadores, dé por sentado que sus dependencias se escanean a velocidad de máquina y ajuste su cadencia de parches en consecuencia. Inventaríe los plugins y sus dependencias complementarias, suscríbase a los feeds de vulnerabilidades de los que usa y priorice según la explotabilidad y la exposición en lugar de tratar cada aviso por igual. Conceda el mínimo privilegio a las cuentas de base de datos para que una inyección de solo lectura no pueda alcanzar los hashes de administrador ni los secretos, coloque un cortafuegos de aplicaciones (WAF) frente a los patrones de peticiones encadenadas y vigile las secuencias de peticiones en varias etapas que la detección de firma única pasa por alto. La conclusión más amplia: la IA reduce el coste de encontrar las clases de errores rutinarias y bien entendidas, de modo que la victoria defensiva sigue siendo entregar código sin ellas y reducir la ventana entre la divulgación pública y el parche desplegado.
Estado
| Elemento | Detalle |
|---|---|
| Divulgación | Intruder, «We built a vulnerability vending machine», 15/07/2026 |
| Método | Code slicing + razonamiento LLM sobre fragmentos acotados, con validación automatizada |
| Alcance reportado | 300+ hallazgos: RCE sin autenticar, inyección SQL, escalada de privilegios, SSRF, cadenas de degradación |
| Caso destacado | Inyección SQL sin autenticar en el plugin de WordPress Creative Mail (Constant Contact), 300 000+ instalaciones; acceso de lectura a la base de datos; requiere WooCommerce; CVE-2026-3985 (CVSS 7.5), afecta a ≤ 1.6.9, divulgada en mayo de 2026 |
| Modelos usados | Modelos de frontera disponibles antes del nivel Mythos |
| Naturaleza | Demostración de capacidad ofensiva sobre vulnerabilidades divulgadas públicamente; ningún exploit reproducido aquí |
Este artículo resume la información del proveedor y de fuentes de terceros a 15 de julio de 2026. La disponibilidad de un parche para el plugin citado puede haber cambiado desde la divulgación de mayo de 2026: verifique la versión corregida actual en el repositorio de plugins de WordPress antes de basarse en cualquier mitigación.