Cloudflare WAF ya detecta exploits en la respuesta HTTP

Cloudflare extiende el WAF a la respuesta del servidor

Cloudflare anunció que su web application firewall (WAF) ahora evalúa cada petición HTTP junto con la respuesta que devuelve el servidor de origen. La nueva capacidad —detección de transacción completa y reglas de respuesta— está disponible para todos sus clientes, incluidos los planes Free. Para un founder con producto en producción el cambio es concreto: la capa que solo miraba lo que entra ahora también mira lo que sale, y eso permite distinguir un intento de ataque de un ataque que efectivamente funcionó.

Las primeras protecciones gestionadas con esta tecnología apuntan a php2shell, la vulnerabilidad crítica de PHP que se divulgó de forma anticipada y que obligó al equipo del lenguaje a adelantar la publicación de sus parches.

¿Qué cambia frente a un WAF tradicional?

Un WAF clásico opera a nivel de petición: reglas gestionadas, reglas personalizadas y rate limiting que inspeccionan IP, ruta, cabeceras y cuerpo del request. Ese enfoque detiene ataques reconocibles antes de que lleguen a la aplicación, y para buena parte del tráfico malicioso sigue siendo el lugar correcto para actuar.

El problema es el trade-off que describe la propia compañía. Las firmas amplias atrapan más ataques potenciales, pero también generan falsos positivos que rompen aplicaciones legítimas. Las reglas conservadoras evitan esos falsos positivos, pero dejan pasar más tráfico ambiguo hacia el servidor.

La respuesta HTTP aporta la evidencia que faltaba. El ejemplo que da Cloudflare es un endpoint de descarga manipulado con un path traversal: GET /download?file=../../config/database.ini. La petición por sí sola no permite saber si la aplicación expondría el archivo, porque puede rechazarla, ignorar el traversal o devolver un error. Si el origen responde 200 OK con contenido con forma de archivo de configuración, la combinación de las dos señales —intento de traversal más respuesta con datos sensibles— es evidencia mucho más fuerte que cualquiera de ellas por separado. La regla de respuesta puede entonces reemplazar esa respuesta por una página de bloqueo del WAF y un HTTP 403 antes de que llegue al atacante.

Hay un límite que conviene tener claro: la mitigación no deshace lo que ya ocurrió en el origen. Si la aplicación ejecutó una acción —escribió en base de datos, creó un archivo, envió un correo—, bloquear la respuesta no revierte ese efecto.

El caso php2shell: por qué esto no es teoría

El contexto que rodea al lanzamiento explica la urgencia. SecurityWeek reportó que las dos fallas, identificadas como CVE-2026-109618 y CVE-2026-109619, tienen un puntaje CVSS de 9.2 y permiten ejecución remota de código sin autenticación. La firma de exposure management WatchTowr confirmó que logró reproducir la primera de ellas, y Sansec advirtió que la explotación masiva probablemente comenzaría minutos después de la publicación de los parches.

La escala del problema es la razón por la que una vulnerabilidad de PHP es un asunto de infraestructura y no de un solo proveedor. Según BleepingComputer, PHP impulsa entre el 75% y el 80% de todos los sitios web, incluidos los que corren sobre gestores de contenido como WordPress, Joomla y Drupal. El mismo medio cita estimaciones de VirusTotal según las cuales hay más de 5,1 millones de hosts PHP expuestos en línea, de los cuales unos 3,8 millones tienen al menos un puerto abierto.

BleepingComputer también recogió que el CTO de Cloudflare, Dane Knecht, confirmó que la compañía ya observaba ataques tempranos contra ambas vulnerabilidades y que sus reglas de WAF desplegadas para el caso eran una medida temporal. El NCSC británico, por su parte, pidió a las organizaciones del Reino Unido actualizar sus sistemas con PHP de inmediato o sacarlos de línea hasta poder parchearlos.

Los parches de emergencia ya están disponibles en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según BleepingComputer, y las fallas afectan a instalaciones que sirven peticiones web como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

¿Cómo se configuran las reglas de respuesta?

Cloudflare separó a propósito la detección de la mitigación. Las detecciones analizan el tráfico y adjuntan metadatos a la petición y a la respuesta; las reglas deciden después qué hacer con ese resultado. Esa separación permite observar primero el comportamiento real del propio tráfico antes de activar bloqueos.

La plataforma agrega tres campos nuevos, espejo de los que ya existían para detecciones de petición:

• cf.waf.signature.response.confidence: valores de confianza asociados a las firmas que coinciden.
• cf.waf.signature.response.categories: categorías asociadas a esas firmas.
• cf.waf.signature.response.ref: identificadores de referencia de firma, hasta 10.

Con esos campos se pueden construir reglas personalizadas que combinen propiedades de la petición y de la respuesta. El ejemplo que da la compañía bloquea solo cuando una petición no autenticada apunta a /admin y el origen devuelve efectivamente una página HTML de administración con código 200, sin afectar fallos de autenticación normales ni redirecciones.

Los puntos prácticos de la implementación:

• Todos los clientes, incluidos los planes gratuitos, pueden crear hasta tres reglas de respuesta personalizadas con acciones de registro (Log) y bloqueo (Block).
• Los controles de fase de respuesta están en el panel, al final de Security > Security Rules.
• El ruleset gestionado Cloudflare Managed Response Firewall Default se despliega con un clic y devuelve una página de bloqueo estándar cuando una firma coincide; su alcance se puede restringir a rutas específicas.
• Crear reglas sobre el cuerpo de la respuesta todavía no está disponible.
• Los eventos generados por reglas de respuesta aparecen en Security Events, dentro de los servicios Managed Rules o Custom Rules.

¿Qué significa esto para tu startup?

Si tu producto corre sobre PHP o sobre cualquier stack que exponga endpoints con datos sensibles, esta actualización cambia dos cosas: qué puedes ver y cuándo puedes actuar.

Primero, revisa si ya estás cubierto. Entra a Security > Security Rules en el panel de Cloudflare y confirma que el ruleset gestionado de respuesta está activo. Si estás en un plan gratuito, esta es la primera vez que accedes a protecciones gestionadas de este tipo sin costo, así que vale la pena verificarlo antes de asumir que no te toca.

Segundo, observa antes de bloquear. Como la detección y la mitigación están separadas, puedes revisar en Security Analytics qué transacciones están marcando las firmas en tu propio tráfico, entender qué endpoints y qué firmas están involucrados, y recién después decidir la política. Es la forma de evitar el clásico escenario donde una regla nueva rompe un flujo legítimo en producción un viernes.

Tercero, no confundas el WAF con el parche. Este es el punto que más se repite en la cobertura del caso php2shell. La desarrolladora del core de PHP Gina Peter Banyard advirtió que ninguna mitigación bloquea por completo los ataques potenciales y que aplicar los parches oficiales es la única defensa permanente. Si tu equipo todavía corre PHP 7 o versiones sin soporte, el WAF no te va a salvar: hay que migrar a una versión con mantenimiento o aislar esos sistemas.

Cuarto, piensa en tus endpoints de administración. La lógica de las reglas de respuesta —bloquear solo cuando el origen devuelve una página de admin exitosa a una petición no autenticada— es un patrón reutilizable para cualquier panel interno que hayas expuesto por descuido. Vale la pena auditar cuáles de tus rutas devuelven 200 con contenido sensible y no deberían.

Conclusión

La detección de transacción completa es una respuesta directa a un cambio en el panorama de amenazas: los modelos de frontera están encontrando vulnerabilidades profundas en software ampliamente usado, y los agentes que escanean en busca de fallas son persistentes, adaptan sus payloads con el feedback que reciben y encadenan vulnerabilidades, credenciales y permisos. En ese escenario, la respuesta del servidor deja de ser un detalle de observabilidad y se convierte en una señal de seguridad de primer nivel.

Para un founder, la conclusión práctica es que la seguridad de aplicación se está moviendo hacia políticas que combinan contexto de entrada y de salida. Las herramientas para hacerlo ya están disponibles incluso en los planes gratuitos, pero siguen siendo una capa complementaria: el parche sigue siendo la defensa que no se negocia.

Fuentes

• Introducing full transaction detection for Cloudflare WAF
• PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
• PHP ships emergency patches for critical PHP2Shell flaws