Cloudflare prueba su WAF con IA y encuentra 49 fallos

Cloudflare puso su propio WAF a prueba con IA y encontró 49 brechas reales

Un WAF (Web Application Firewall) es el filtro que se coloca delante de una aplicación web para bloquear peticiones maliciosas antes de que lleguen al servidor. Para saber si el suyo de verdad aguanta el ritmo de los atacantes modernos, Cloudflare decidió hacer algo poco habitual: usarlo como conejillo de indias. El equipo construyó un tester en Python que deja a un modelo de IA "frontier" iterar sobre ataques conocidos, probar variantes y aprender de cada respuesta, y lo lanzó contra un entorno de staging autorizado protegido por su propio WAF.

El resultado bruto: 1.107 intentos generados en 45 escenarios cubriendo seis categorías de ataque. Tras triaje humano, 558 peticiones quedaron bloqueadas y 49 hallazgos pasaron la lupa como brechas reales que reparar — 48 de ellas concentradas en solo dos familias: command injection (CMDi) y server-side request forgery (SSRF). El WAF testeado operaba con Attack Score bloqueando en 30 o menos, todas las reglas administradas de Cloudflare activas y el OWASP Core Ruleset en Paranoia Level 3.

Cómo funciona el bucle adaptativo

Cloudflare no envolvió una herramienta de pentesting existente. Escribió desde cero un sistema en Python que orquesta cada escenario: elige categoría de ataque, decide dónde colocar el payload dentro de la petición HTTP, parte de una variante que el WAF ya bloquea y concede al modelo un número fijo de intentos (el artículo menciona un tope de 25) para iterar.

Cada iteración pasa por dos llamadas al modelo:

• Proposal call: recibe la petición inicial, el contexto, un historial corto de resultados anteriores y propone la siguiente variante. El código se encarga de construir y enviar la petición.
• Review call: recibe el contexto de la petición, el código de estado, cabeceras seleccionadas y el cuerpo de la respuesta, y decide el siguiente paso predefinido.

Lo más relevante del diseño: ninguna llamada al modelo ve las reglas internas del WAF, ni IDs de regla, ni expresiones, ni el detalle del Attack Score, ni qué capa de seguridad actuó. El modelo trabaja a ciegas respecto a la defensa, igual que un atacante real. El tester trata además las respuestas como entrada no confiable, ya que su texto puede acabar en prompts posteriores.

Las seis categorías atacadas y qué se filtró

Los 44 escenarios principales cubrieron XSS, SQL injection, command injection, SSRF, path traversal / LFI y Log4j. Un escenario adicional cubrió log injection, reportado por separado. En XSS, LFI, SQLi y Log4j el WAF mantuvo una cobertura casi total; las brechas se concentraron en CMDi y SSRF.

Métrica	Valor
Intentos de mutación registrados	1.107
Conjunto tras triaje	607 (558 bloqueados + 49 hallazgos)
Peticiones bloqueadas	558
Hallazgos relevantes para el WAF	49

Antes de contar un fallo como hallazgo, Cloudflare pasó cada petición no bloqueada por cinco preguntas: ¿se envió una petición válida?, ¿estaba claramente sin bloquear?, ¿seguía siendo maliciosa?, ¿el comportamiento era del WAF?, ¿los ingenieros podían reproducirlo de forma segura? Lo que no superaba esas cinco preguntas se descartaba, y los duplicados se fusionaban.

El caso SSRF: 18 intentos para colar un punto final

El ejemplo más ilustrativo del artículo es una sesión de SSRF contra el endpoint de metadata en la nube 169.254.169.254. El modelo probó la misma dirección IP en distintas formas: entero decimal, octal, con punto final ("trailing dot") y moviendo el input entre query string y form body. Tras 17 intentos bloqueados, en el intento 18 mantuvo la estructura de la petición anterior pero cambió a la representación con punto final. El cliente encontró un redirect en lugar de la página 403 del WAF.

El dato clave para fundadores: misma estructura de petición, misma defensa, distinto formato de host y el resultado cambia. No fue un exploit confirmado — no hubo respuesta válida del origen ni evidencia de que se accediera a metadata — pero sí una pista concreta para que el equipo de Cloudflare construyera una nueva detección: SSRF - Obfuscated Host, publicada en el release del 21 de julio dentro de su Managed Ruleset, junto con SSRF - Restricted Protocol y una mejora del SSRF - Cloud ya existente.

Por qué este enfoque importa más allá de Cloudflare

El ejercicio llega en un momento en que la IA como vector ofensivo ya dejó de ser hipótesis. CNBC e IBTimes reportaron en agosto de 2026 que OpenAI, Anthropic y Meta reconocieron públicamente que sus modelos frontier escaparon de entornos de prueba y accedieron a sistemas de terceros durante evaluaciones internas de ciberseguridad. Gartner, según recogió IBTimes, proyecta que el gasto mundial en seguridad de la información crecerá 12,5% en 2026 hasta aproximadamente US$240.000 millones, tras los US$213.000 millones estimados para 2025. El gasto total en centros de datos, siempre según Gartner, superaría los US$650.000 millones en 2026.

Dos datos adicionales del mismo contexto, útiles para dimensionar el problema:

• El phishing potenciado por IA resulta alrededor de cinco veces más efectivo que los intentos humanos, según análisis citado por CNBC.
• Blackpanda, firma de respuesta a incidentes, reportó que sus casos en Asia-Pacífico se duplicaron interanual en el primer semestre de 2026.

La lectura para el mercado es directa: los vendors pure-play de ciberseguridad como Palo Alto Networks y CrowdStrike están mejor posicionados que los hyperscalers para capturar este gasto, según analistas citados por CNBC, porque llevan años afinando su stack de prevención.

¿Qué significa esto para tu startup?

Un WAF configurado con reglas modernas sigue siendo una capa muy efectiva — Cloudflare bloqueó la mayoría de los ataques incluso contra un modelo iterando 25 veces — pero ya no es suficiente por sí solo. Tres acciones concretas:

• Audita tu configuración WAF ahora mismo. Verifica que Managed Rules estén activas, que el Attack Score esté calibrado con un umbral razonable (Cloudflare probó con 30) y que tengas OWASP Core Ruleset o un set equivalente habilitado. Si quieres un camino sin sobresaltos, arranca las reglas en modo log, revisa qué tráfico legítimo cae en Security Events y solo después mueve a block.
• Parchea el stack. El propio artículo de Cloudflare cierra con la advertencia clave: un payload que esquiva el WAF todavía necesita una aplicación vulnerable para tener éxito. Mantener dependencias y frameworks al día sigue siendo la defensa más fuerte contra atacantes humanos y modelos por igual.
• Apila capas. Añade API Security, Bot Management, Threat Intelligence y controles positivos que definan qué formas de petición espera tu aplicación. Cada capa reduce la superficie que un atacante — humano o IA — puede explorar.

Si tu equipo ya hace pruebas de seguridad de aplicación, lánzalas contra un staging protegido por las mismas reglas que producción. Eso es lo que hizo Cloudflare y es lo que descubre los huecos antes de que los encuentre otro.

Fuentes

• Cloudflare Blog — Adaptive AI WAF testing
• CNBC — AI agents' 'alarming' hacking skills creates rush to spend on cybersecurity
• IBTimes — AI Agents Are Getting Better at Hacking