Cloudflare pone su WAF a prueba: un PHP 8.5.11 sin parchear y un archivo /flag escondido
Un servidor con PHP 8.5.11 sin parchear, Apache 2 corriendo con mod_php y un archivo llamado /flag dentro de un contenedor. Delante, las reglas del WAF de Cloudflare. Eso es todo lo que hay que vencer para cobrar.
Cloudflare abrió un Capture the Flag (CTF) —una competencia en la que el objetivo es capturar un archivo oculto explotando un sistema— dentro de su programa de Bug Bounty en HackerOne. La consigna es simple de enunciar y difícil de ejecutar: saltarse las protecciones del WAF, ejecutar código en un sandbox PHP deliberadamente vulnerable y recuperar el contenido de /flag.
Para un founder que corre su producto sobre PHP, la noticia no es el concurso. La noticia es lo que el concurso revela: la empresa que protege a una parte enorme de la web está pagando por saber si su propia defensa aguanta.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasQué es php2shell y por qué Cloudflare montó este reto
El reto se concentra en CVE-2026-109618 y CVE-2026-109619, las dos vulnerabilidades detrás de php2shell. Ambas tienen un puntaje CVSS de 9.2 y permiten ejecución remota de código sin autenticación, según reportó SecurityWeek.
El alcance es incómodamente amplio. Help Net Security detalla que afecta a toda instalación de PHP que sirva peticiones web: PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed. Los despliegues con modphp son los más expuestos, porque se demostró que un solo request no autenticado puede disparar el ataque antes de que corra una línea del código de la aplicación.
Las causas técnicas, según el mismo medio: CVE-2026-109618 explota el manejo de memoria agotada, interrumpiendo PHP mientras los datos internos del request están a medio inicializar; CVE-2026-109619 deja estado interno de un request vivo después de que su memoria fue liberada, y un request posterior atendido por el mismo worker puede usar ese estado obsoleto.
El contexto de la semana fue más amplio. La propia Cloudflare describe en su anuncio que primero se comprometieron ocho certificados intermedios de eMudhra, abriendo la puerta a certificados falsificados para suplantar servidores, y después llegó php2shell. La compañía respondió con actualizaciones de cliente, reglas nuevas en su WAF y una función llamada full transaction detection, disponible en todos los planes, incluido el gratuito.
Cómo funciona el reto: reglas, alcance y qué no se paga
El sandbox corre PHP 8.5.11 stock con extensiones estándar, Apache 2 vía mod_php y un index.php vacío dentro de un Cloudflare Container. El sandbox se reinicia cada pocos minutos, incluido el archivo de bandera.
Las condiciones para reclamar el bounty, tal como las publica Cloudflare:
- Registrarse en HackerOne y aceptar los términos del programa antes de participar.
- Demostrar ejecución de código o comandos controlados por el atacante dentro del sandbox mediante un request POST autorizado.
- Usar esa ejecución remota para recuperar el contenido actual de
/flagy verificarlo en la interfaz del reto antes de un reinicio. - Enviar un reporte privado a Cloudflare en HackerOne con el endpoint, el payload completo, la secuencia de requests, capturas crudas de request/response, la explicación del bypass y los timestamps UTC.
Hay una lista explícita de lo que no califica: divulgación de archivos sin ejecución de código, ejecución sin recuperación de la bandera, exploits solo locales, redescubrimiento de las vulnerabilidades ya conocidas y cadenas parciales. Tampoco cuentan los cambios cosméticos ni codificaciones equivalentes: solo el primer reporte completo y reproducible se considera válido.
El alcance autorizado es angosto y conviene respetarlo: únicamente los endpoints /php/* del hostname del reto, solo con método POST. Quedan fuera otros servicios de Cloudflare, el acceso directo a la infraestructura subyacente, el proyecto PHP upstream y cualquier sistema de terceros. Nada de denegación de servicio, escaneo de alto volumen, persistencia ni ingeniería social. Si aparece un 429 o un 503, hay que retroceder.
Por qué la IA cambió el cálculo de riesgo
Este es el punto que debería preocupar a cualquier equipo técnico. Los investigadores de Wiz señalaron a Help Net Security que estas fallas estuvieron presentes durante décadas, pero demostrar su explotabilidad exigía una cadena de pasos tan compleja que estaba en el límite de lo que un humano podía lograr. Los modelos de IA frontera redujeron esa barrera y convirtieron un defecto antiguo en un exploit.
El caso lo confirma desde otro ángulo: según Hackread, OpenAI indicó que la firma de ciberseguridad Calif identificó una falla crítica de PHP usando GPT-5.6 Sol a través de su iniciativa Patch the Planet, aunque Calif después acreditó al investigador independiente @lcfr_hax como el primero en encontrar php2shell y desarrollar un exploit funcional.
La velocidad también cambió. Sansec advirtió, según SecurityWeek, que la explotación masiva probablemente empezaría dentro de los 15 minutos posteriores a la publicación del parche. Y Amazon Threat Intelligence detectó un intento de explotación en su red de honeypots MadPot el 17 de octubre de 2026, cuatro días antes de la divulgación pública, según Help Net Security.
El investigador Kevin Beaumont lo resumió sin vueltas ante Help Net Security: la situación de PHP va a generar una masa de incidentes y es una de las vulnerabilidades más grandes en años. El NCSC británico pidió considerar sacar de línea cualquier sistema que no se pueda parchear de inmediato.
¿Qué significa esto para tu startup?
La lección más importante la dice Cloudflare en su propio anuncio: el WAF protege, pero no reemplaza el parcheo. Bloquear una respuesta puede evitar que los datos expuestos lleguen al atacante, pero no deshace lo que ya se ejecutó en el origen. Si tu producto corre sobre PHP, la prioridad no es la regla del WAF: es la versión del runtime.
Estas son las acciones concretas que puedes ejecutar esta semana:
- Verifica tu versión exacta de PHP. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según Help Net Security. Si estás en 8.1 o anterior, quedaste fuera del soporte normal del proyecto y dependes de tu proveedor o de un backport.
- Pregunta a tu proveedor de hosting gestionado. Actualizar WordPress, sus plugins o tu tema no toca la instalación de PHP del servidor. Necesitas confirmación explícita de que el runtime está parcheado.
- Escanea antes de asumir. Searchlight Cyber publicó php2shell-scanner, una herramienta open source que prueba si un host está expuesto a CVE-2026-109618 y CVE-2026-109619, según Help Net Security.
- Si no puedes parchear hoy, aplica mitigaciones parciales. Hackread recoge que las advisories oficiales mencionan desactivar el progreso de carga de sesiones y, en PHP 8.5, desactivar los backtraces de errores fatales, reiniciando después todos los workers. Los propios mantenedores advierten que ningún cambio de configuración cubre todas las rutas de ataque.
- Revisa tu inventario olvidado. El experto en forense Hal Pomeranz apuntó a Help Net Security que hay demasiadas instalaciones embebidas que nunca se parchearán y demasiadas apps abandonadas: la cola larga de este incidente va a ser extensa.
La lección de fondo para un equipo pequeño
Cloudflare eligió exponer su propia defensa a un escrutinio público y pagado en lugar de asumir que sus reglas funcionan. Ese es un modelo mental útil para cualquier startup: cuando tu producto depende de una pieza de infraestructura que no controlas —un runtime, una librería, un proveedor cloud— la pregunta correcta no es si estás protegido, sino cómo lo verificas.
El CTF también deja claro que la ventana entre la divulgación de una vulnerabilidad crítica y su explotación masiva se está comprimiendo a minutos. Para un equipo sin equipo de seguridad dedicado, eso significa que la velocidad de actualización es una capacidad de negocio, no una tarea de mantenimiento.
Fuentes
- Introducing the Cloudflare PHP Capture the Flag challenge
- PHP2Shell: Critical PHP vulnerabilities patched, update now! - Help Net Security
- PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws - SecurityWeek
- PHP Releases Emergency Fixes for Critical PHP2Shell Vulnerabilities - Hackread
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
