Cloudflare utiliza agentes de IA para someter a prueba su propio firewall de aplicaciones web

Ingenieros de Cloudflare sometieron recientemente su propio Firewall de Aplicaciones Web (WAF) a una rigurosa prueba de estrés utilizando grandes modelos de lenguaje (LLM) de vanguardia. Publicado el 29 de septiembre de 2026, el estudio detalla cómo un sistema automatizado actuó como un hacker adversario, iterando a través de miles de variaciones de carga útil para encontrar puntos ciegos en las defensas en tiempo real. El experimento reveló debilidades específicas en el manejo de intentos de falsificación de solicitudes del lado del servidor (SSRF) ofuscados y de inyección de comandos, lo que llevó a actualizaciones inmediatas en los conjuntos de reglas gestionadas de Cloudflare.

Qué ocurrió

El equipo de seguridad construyó un banco de pruebas personalizado basado en Python para evaluar si los modelos de IA modernos podían evadir las protecciones del WAF con mayor eficacia que las herramientas tradicionales de análisis estático o dinámico. A diferencia de las pruebas de penetración estándar, este sistema utilizaba LLMs para mutar dinámicamente los vectores de ataque basándose en respuestas HTTP en vivo. El probador no tenía acceso al código fuente ni a las reglas internas del WAF, confiando únicamente en los datos de respuesta seleccionados para guiar su siguiente movimiento. Este enfoque de caja negra imitaba cómo un atacante externo podría sondear una aplicación protegida sin conocimiento previo de su infraestructura.

La prueba se ejecutó contra un entorno de preproducción autorizado de un cliente configurado con los ajustes más estrictos de Cloudflare, incluyendo el bloqueo por Puntuación de Ataque del WAF en 30 o menos y el Conjunto de Reglas Core de OWASP en Nivel de Paranoia 3. Durante el experimento, el sistema ejecutó 1.107 intentos de mutación en 45 escenarios que cubrían seis categorías principales de ataque: cross-site scripting (XSS), inyección SQL, inyección de comandos, falsificación de solicitudes del lado del servidor (SSRF), traversal de rutas y exploits de Log4j. Aunque la mayoría de los ataques fueron bloqueados, el proceso identificó 49 hallazgos específicos que requirieron revisión humana y mitigación posterior.

La mayoría de las evasiones exitosas cayeron en dos categorías: inyección de comandos y SSRF. Por ejemplo, en un escenario de SSRF, el modelo descubrió que representar una dirección IP de metadatos de la nube con un punto final le permitía evadir la detección donde las representaciones decimales u octales estándar fallaban. Estos hallazgos no eran exploits confirmados, sino pistas que indicaban que la lógica de normalización del WAF podría tratar ciertos casos límite de manera diferente. El equipo utilizó estas ideas para refinar sus motores de detección, resultando en nuevas reglas para hosts ofuscados y protocolos restringidos.

Cómo funciona

El sistema de pruebas opera sobre un bucle adaptativo impulsado por dos llamadas distintas a LLM por iteración. La primera llamada, la fase de propuesta, recibe el contexto de la solicitud inicial y un historial de resultados previos para sugerir una nueva variación. Podría cambiar la codificación, mover la carga útil a una parte diferente de la solicitud HTTP o alterar el formato del destino. La segunda llamada, la fase de revisión, analiza el estado de la respuesta, las cabeceras y el cuerpo para determinar si el intento fue exitoso o bloqueado. Este bucle de retroalimentación permite al modelo aprender qué mutaciones son efectivas sin ver nunca las expresiones de reglas subyacentes del WAF ni las puntuaciones de ataque.

Crucialmente, el código mantiene un control estricto sobre el entorno de ejecución. El LLM no envía solicitudes directamente; en su lugar, genera sugerencias que el banco de pruebas de Python valida y ejecuta. Antes de cada solicitud, el sistema verifica el nombre de host de destino contra una lista blanca, deshabilita las redirecciones y aplica un límite estricto en los intentos. Después de cada respuesta, el sistema registra evidencia estructurada, tratando cualquier texto devuelto como entrada no confiable. Este diseño asegura que el proceso de pruebas permanezca seguro y reproducible, evitando que la IA cause daños no intencionados o filtre datos sensibles durante la evaluación.

Detalles clave

• La prueba generó 1.107 intentos de mutación, con 558 explícitamente bloqueados por el WAF antes de llegar a la aplicación.
• La triage humana redujo la salida bruta a 49 hallazgos válidos, 48 de los cuales estaban relacionados con inyección de comandos o SSRF.
• La configuración del WAF incluía el bloqueo por Puntuación de Ataque del WAF en 30 o menos y el Conjunto de Reglas Core de OWASP en Nivel de Paranoia 3.
• Se añadieron nuevas detecciones para hosts ofuscados de SSRF y protocolos restringidos al Conjunto de Reglas Gestionadas tras la prueba.
• El sistema utilizó dos llamadas separadas a LLM por iteración: una para proponer mutaciones y otra para revisar respuestas.
• Las solicitudes que evadieron el WAF se trataron como pistas para investigación, no como exploits confirmados, requiriendo validación adicional.

Por qué importa

Para ingenieros de software y líderes de seguridad, este estudio destaca las limitaciones de las defensas estáticas basadas en reglas frente a adversarios adaptativos. Las pruebas de penetración tradicionales a menudo siguen scripts predefinidos, pasando por alto técnicas de codificación novedosas o fallos lógicos que una IA puede descubrir mediante iteración. Al demostrar que los LLMs pueden encontrar brechas incluso en WAFs altamente configurados, Cloudflare subraya la necesidad de pruebas de seguridad continuas y automatizadas que evolucionen junto con los paisajes de amenazas. Sugiere que confiar únicamente en la detección basada en firmas es insuficiente cuando los atacantes pueden usar IA para generar infinitas variaciones de exploits conocidos.

Los hallazgos también refuerzan la importancia de la defensa en profundidad. Incluso cuando un WAF falla al bloquear una solicitud mutada específica, la aplicación misma debe permanecer segura. En el ejemplo de SSRF, la evasión no resultó en exfiltración de datos porque la capa de aplicación probablemente tenía sus propias protecciones o la solicitud estaba malformada de una manera que impedía la explotación real. Esto recuerda a los desarrolladores que parchear software y mantener dependencias actualizadas son complementos críticos para los controles de seguridad a nivel de red. Un WAF es un escudo, no una cura, y su eficacia depende de la resiliencia de toda la pila.

Qué puedes hacer

• Habilita todos los conjuntos de reglas gestionadas disponibles y establece los umbrales de Puntuación de Ataque del WAF en niveles recomendados para tu perfil de riesgo.
• Ejecuta pruebas de seguridad de aplicaciones existentes contra entornos de preproducción protegidos por las mismas configuraciones de WAF que producción.
• Implementa controles de seguridad positivos que definan formas de solicitud esperadas, reduciendo la superficie de ataque para variantes desconocidas.
• Revisa eventos de seguridad en modo solo registro antes de aplicar nuevas reglas para identificar falsos positivos y patrones de tráfico legítimo.
• Mantén las dependencias y frameworks de la aplicación actualizados para mitigar vulnerabilidades que podrían quedar expuestas si fallan las capas de WAF.
• Considera usar herramientas de pruebas impulsadas por IA para complementar las pruebas de penetración manuales, enfocándote en la mutación adaptativa de cargas útiles.