Cloudflare bloquea PHP2Shell, pero tu WAF no protege un origen abierto

El martes 21 de octubre, a las 03:02 UTC, las reglas de WAF de Cloudflare se activaron para todos sus clientes, gratis y de pago. Nueve horas más tarde, a las 14:00 UTC, PHP publicó los parches que cierran CVE-2026-109618 y CVE-2026-109619, las dos RCE sin autenticación que la prensa bautizó como PHP2Shell. Ese orden no fue casualidad: Cloudflare estaba sentado en la mesa de divulgación coordinada desde principios de octubre y levantó su defensa antes de que existiera el anuncio público.

Es un movimiento que merece atención, porque el titular que se está discutiendo (“PHP2Shell es la peor vulnerabilidad de la historia”) esconde lo que de verdad cambió en el ecosistema: por primera vez, un proveedor de CDN desplegó una capa de mitigación activa nueve horas antes de que el mundo supiera que el problema existía. Pero también merece una advertencia, y es la que ninguna nota de prensa está mencionando: un WAF solo inspecciona el tráfico que lo atraviesa. Si tu servidor PHP sigue contestando por su IP directa o por un hostname que no pasa por el proxy, estás sin protección aunque Cloudflare haya desplegado las reglas más importantes del mundo.

Qué es realmente PHP2Shell

Antes de hablar de la defensa, conviene tener claro el problema, porque mucha gente sigue creyendo que esto es un fallo de WordPress o de algún plugin. No lo es. Las dos vulnerabilidades están en el runtime de PHP, no en ninguna aplicación que corra encima. Un “Hello World” en PHP vulnerable es explotable igual que un WordPress completo.

El nombre colectivo php2shell agrupa dos identificadores. Ambos fueron reportados de forma coordinada por Calif.io, Wiz, OpenAI y Quarkslab el 21 de octubre, con Cloudflare y la PHP Foundation participando en el mismo esfuerzo de divulgación. PHP los puntúa con CVSS v4.0 9.2 en ambos casos, y el equipo de PHP califica el riesgo como máximo para mod_php, con un exploit demostrado donde una petición no autenticada dispara el ataque antes de que corra una sola línea de tu código de aplicación.

La causa raíz común es el manejo de memoria cuando PHP encuentra un error durante el procesamiento de una petición. El motor reserva memoria para cada request y la libera cuando el trabajo termina. Si el procesamiento se corta de forma inesperada, esa limpieza no ocurre de forma segura, y PHP termina usando datos a medias o memoria ya liberada como si fueran válidos.

El mecanismo técnico detrás de ambos casos es longjmp(). Cuando el motor aborta una operación con un error fatal, salta fuera de la pila de C sin ejecutar el código de limpieza intermedio: nada de lo que el código de la aplicación había preparado queda respaldado, y el estado a medias sobrevive hasta que el shutdown de la petición lo toca como si fuera válido. Esa es la razón por la que un fallo de memoria, en principio inocuo, se convierte en ejecución de código arbitrario.

Vulnerabilidad	Qué sale mal	Impacto
CVE-2026-109618 (corrupción por agotamiento de memoria)	PHP se queda sin memoria y corta su trabajo antes de que algunos datos internos estén correctamente inicializados. Durante el cleanup de esa petición, usa esos datos a medias como si fueran válidos.	RCE sin autenticación y lectura de memoria del proceso
CVE-2026-109619 (estado global obsoleto)	Un error fatal interrumpe la petición dejando referencias a memoria que se libera cuando la petición termina. Cuando el mismo worker procesa una petición posterior, sigue esas referencias obsoletas.	Filtración de datos sensibles, use-after-free y corrupción de OPcache

Lo relevante para un sysadmin no es la teoría del heap sino el alcance: todos los servidores web con PHP 5.4 o posterior están afectados. PHP mueve cerca del 70% de los sitios web según w3techs, y las versiones corregidas fueron 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas 8.2, 8.3, 8.4 y 8.5 recibieron los arreglos; la 8.1 y anteriores ya no reciben actualizaciones del proyecto y solo tienen backports mínimos de código fuente para 7.4, 8.0 y 8.1. PHP 8.2 llega a su fin de vida el 31 de diciembre de 2026.

Detalle que no aparece en la mayoría de los resúmenes: además de la RCE, Wiz demostró que los atacantes pueden leer datos sensibles de la memoria del proceso PHP, contraseñas, tokens, claves API y certificados, sin necesitar siquiera alcanzar la ejecución de código. En un servidor con pooling de FPM, esos valores pueden pertenecer a peticiones ajenas.

Qué desplegó Cloudflare antes de la divulgación

Cloudflare describe el trabajo como parte de un esfuerzo más amplio para proteger internet, con el WAF como una de las capas. Las reglas se empezaron a desarrollar a principios de octubre de 2026 y quedaron activas por defecto el 21 de octubre a las 03:02 UTC para clientes con WAF, tanto del plan gratuito como de pago. No hay que hacer nada para activarlas en Free: se despliegan solas.

Lo que hay que revisar es el plan de pago, porque ahí sí hay una acción manual pendiente. Cada plan de pago usa un Ruleset distinto y el comportamiento por defecto no siempre es el que uno asume.

Plan	Ruleset	ID del ruleset	Acción para ti
Free	Cloudflare Managed Free Ruleset	77454fe2d30c4220b5701f6fdfb893ba	Ninguna. Se activa sola, con 7 reglas “Generic Rules – Anomalous Execution”
Professional, Business, Enterprise	Cloudflare Managed Ruleset	efb7b8c949ac4650a09736fc376e9aee	Verificar que esté desplegado en modo block, no solo en modo detección
Todos, incluido Free	Cloudflare Managed Response Firewall Default	Regla afffe22785674c80a31875c848d2242a	Ninguna. Bloquea respuestas del origin con firmas de alta confianza

Cloudflare también relata un detalle que da idea de lo que venía: la información sobre las fallas se filtró antes de la fecha oficial y la empresa observó tráfico de ataque real dirigido a sus clientes, incluidos intentos de mutar el payload para evadir las reglas. Lo hicieron rastreando el volumen de coincidencias y cruzándolo con la lógica de cada regla, no confiando en un patrón fijo. Eso es un recordatorio de que las reglas WAF hay que revisitarlas: una firma que funciona hoy puede quedarse obsoleta en horas.

Full transaction detection: la primera vez que un WAF lee la respuesta

Esta es la parte que más me interesa como sysadmin, y es la innovación técnica real de este despliegue. Las reglas WAF clásicas miran solo la petición: la URL, los headers, el body, el user agent. La respuesta del servidor no participa en la decisión. Y en el caso de php2shell, esa limitación era fatal: los datos de la petición no siempre dan evidencia suficiente para distinguir un exploit de tráfico legítimo.

Cloudflare desarrolló para esto full transaction detection, una capacidad nueva del WAF que correlaciona señales del request y de la response dentro de la misma transacción HTTP. Suena abstracto, pero el caso de uso es concreto: un intento de path traversal contra un endpoint de descargas se ve idéntico a una petición normal si solo miras el request. Si la respuesta del origin viene con el contenido de un archivo de configuración, la combinación de ambos señales es prueba mucho más fuerte de exposición de datos que cualquiera de las dos por separado.

Y aquí está lo importante: las response rules pueden bloquear la respuesta del origin antes de que llegue al solicitante. El atacante no alcanza a ver ni un byte de la credencial filtrada. Cloudflare dice que las protecciones contra php2shell son las primeras detecciones gestionadas que usan esta capacidad, y que la función está disponible para todas las zonas que pasan tráfico por su red, incluyendo planes gratuitos.

Hay un matiz honesto que conviene tener presente: bloquear la respuesta evita que el atacante reciba la data, pero no deshace lo que ya se ejecutó en el origin. Si el exploit llegó a escribir un archivo o a lanzar un proceso, esa acción sigue en pie. La detección de respuesta es un cierre de puerta, no un deshacer.

El límite que el anuncio no discute: un WAF solo ve lo que lo atraviesa

Esta es la parte que me preocupa, y es la razón por la que este post existe. Todo el anuncio de Cloudflare se concentra en los clientes cuyo tráfico pasa por el proxy. Eso es la enorme mayoría, pero no es todos, y la diferencia no es teórica: es la diferencia entre estar protegido y estar expuesto a un escaneo masivo.

Un WAF es un filtro de red. Solo ve peticiones que llegan a su posición en la ruta. Si tu servidor PHP es alcanzable de otras maneras, esas peticiones nunca pasan por las reglas y llegan directamente al runtime vulnerable. Los escenarios reales donde esto pasa son varios, y ninguno requiere que seas descuidado:

• El origin responde por su IP pública. Es el caso clásico. El DNS del dominio apunta a Cloudflare, pero el servidor también acepta conexiones directas en los puertos 80 y 443. Un atacante que descubre esa IP se salta el WAF por completo. Y lo descubre fácil: registros históricos de DNS, certificados TLS emitidos para ese host, escaneos de rango, o simplemente el encabezado Server de tu respuesta directa.
• Existe un hostname alterno que no está proxied. Un origin.tudominio.com sin el proxy naranja activo, o un directo.tudominio.com “para probar”, resuelve a la misma IP y ofrece un camino sin filtros al mismo PHP.
• El backend PHP-FPM está expuesto. El puerto 9000 de FPM no debería salir a internet nunca, pero un cambio de firewall mal aplicado lo deja alcanzable. En ese caso el atacante habla el protocolo de FastCGI directamente, sin pasar por HTTP y sin pasar por el WAF.
• Contenedores con imágenes PHP viejas. Un php:8.2 descargado de la registry antes del 21 de octubre sigue corriendo un runtime vulnerable, aunque tu aplicación esté impecable y tus plugins al día. Y si ese contenedor publica un puerto en el host, es otro camino directo al runtime.

Un matiz importante sobre nginx y Apache: tener nginx delante con proxy_pass hacia un backend PHP-FPM no es un problema por sí mismo, siempre que ese backend no sea alcanzable por otra vía. Es la configuración estándar y, mientras todo el tráfico entre al servidor por el proxy, el WAF sí protege. El agujero aparece cuando existe una segunda puerta: la IP directa, el hostname alterno, el puerto de FPM abierto o el contenedor que publica su propio puerto.

Por eso la mitigación en el borde no es opcional. Y hay un dato adicional: en su aviso conjunto, el CERT-EU recomendó, para organizaciones que no pudieran parchear de inmediato, considerar aislar las aplicaciones expuestas a internet de la red pública hasta que las correcciones estuvieran disponibles. Es una recomendación más drástica que la de Cloudflare, y tiene sentido cuando el origin no está bien cerrado.

Auditar tu stack PHP antes de que llegue el parche

Empieza por lo básico: saber qué versión ejecuta realmente tu servidor. Ojo con un detalle que engaña a mucha gente: php -v en la terminal muestra el binario de CLI, que puede ser distinto del que atiende las peticiones web.

# Versión del intérprete y configuración efectiva que ve PHP
php -v
php -i | grep -E '^(memory_limit|post_max_size|upload_max_filesize|max_input_vars|max_input_nesting_level|session.upload_progress.enabled|fatal_error_backtraces)'

Este segundo comando te da el perfil de riesgo real de tu instalación. memory_limit y post_max_size son los dos valores que más importan: un análisis de CrowdStrike sobre php2shell señala que el exploit por agotamiento de memoria es alcanzable cuando memory_limit es menor que cuatro veces post_max_size. Los valores por defecto de PHP (post_max_size de 8M con memory_limit de 128M) no cumplen esa condición, pero muchos servidores en producción están ajustados para aceptar subidas grandes: post_max_size de 64M con memory_limit de 128M, o 100M con 256M, sí la cumplen. Tu servidor probablemente no usa los defaults.

Segundo paso: confirmar qué SAPI está sirviendo el tráfico. mod_php es el más expuesto porque el exploit se dispara antes de que corra tu código.

# ¿mod_php o php-fpm? El SAPI que atiende las peticiones es el que importa
apache2ctl -M 2>/dev/null | grep -i php
httpd -M 2>/dev/null | grep -i php
ps -eo pid,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Tercero: revisar la configuración real de los pools, que es donde se puede aplicar una restricción que la aplicación no pueda sobrescribir.

# Pools de FPM: qué listen, qué límites y qué php_admin_value aplican
ls -1 /etc/php/
grep -rn '^listen' /etc/php/*/fpm/pool.d/
grep -rn 'php_admin_value' /etc/php/*/fpm/pool.d/

Cuarto: la comprobación que más se salta la gente. ¿Tu origin contesta por IP directa?

# Tu dominio público debería pasar por Cloudflare
curl -sI https://tu-dominio.example/ | grep -iE '^(server|cf-ray|cf-cache-status)'
# El origen directo NO debería responder con un PHP vivo
curl -sI http://IP_DEL_ORIGEN/ | head -1
# Todos los hostnames de tu dominio deberían resolver a IPs de Cloudflare
dig +short tu-dominio.example A

Si el primer comando no devuelve cf-ray, no estás realmente detrás de Cloudflare. Si el segundo devuelve una respuesta con Server de Apache o nginx en lugar de rechazarse, tienes el origen abierto y el WAF no te protege. Y si el dig devuelve una IP que no es de Cloudflare, tienes un hostname alterno sirviendo PHP sin filtrar.

Quinto, si trabajas con contenedores, el estado de tus imágenes PHP:

# Imágenes PHP en el host: una etiqueta vieja es un runtime vulnerable
docker images --format '{{.Repository}}:{{.Tag}} {{.CreatedSince}}' | grep -i php
# Contenedores corriendo con puertos publicados hacia el host
docker ps --format '{{.Image}} {{.Ports}}' | grep -i php

Una imagen php:8.2 con meses de antigüedad arrastra el runtime vulnerable. La etiqueta dice 8.2 porque en la época en que se descargó, 8.2 era la versión corregida; hoy ya no lo es. Actualizar el compose file no cambia nada si la imagen no se vuelve a descargar.

Y para confirmar si hay intentos en curso, los logs del worker PHP dejan firma propia: el agotamiento de memoria aparece como “allowed memory size” y los errores fatales como “PHP Fatal error”. Si ves cualquiera de los dos tras el 21 de octubre, trátalo como incidente hasta demostrar lo contrario.

# Firmas del intento en los logs del worker PHP
grep -i 'allowed memory size' /var/log/php*-fpm.log | tail -20
grep -i 'PHP Fatal error' /var/log/php*-fpm.log | tail -20

Aplicar las mitigaciones provisionales mientras llega el parche

Cloudflare es explícito en su nota, y vale la pena citarlo textual porque es el punto que más se pierde de vista: los clientes deben parchear sus repos de PHP aun con la protección WAF activa, porque el WAF es una capa adicional de defensa en profundidad, no la solución. Y la propia empresa lo refuerza: restringir subidas innecesarias y limitar el tamaño de las subidas reduce exposición, pero no reemplaza el fix de PHP.

El advisory de php.net publica medidas provisionales explícitas y, con muy buen criterio, insiste en que ninguna vuelve segura una instalación. Sirven para ganar tiempo, no para cerrar el incidente.

; Pool de FPM: php_admin_value gana a lo que ponga la aplicación
; Requiere reiniciar TODOS los workers después del cambio
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 8M
php_admin_value[session.upload_progress.enabled] = 0

Sobre memory_limit = -1: el advisory lo pide de forma explícita y teniendo en cuenta que se aplique de modo que la aplicación no lo pueda revertir, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache, y verificando que ningún pool, directorio o ajuste de la aplicación vuelva a poner un límite finito. El objetivo es quitar el disparador predecible del agotamiento de memoria, aunque una asignación que falle por otra causa todavía puede alcanzar la ruta vulnerable. Ojo con dos cosas: no sustituyas esto por RLIMIT_AS o RLIMIT_DATA, porque pueden provocar precisamente el fallo de asignación que dispara el bug, y no confundas memoria ilimitada con seguridad: es un riesgo de denegación de servicio por sí solo. El advisory sugiere en su lugar un límite de contenedor o cgroup como frontera de disponibilidad, idealmente con una política que mate solo al worker afectado.

; Ajustes globales de php.ini
; session.upload_progress.enabled bloquea las rutas de sesión confirmadas
; del CVE-2026-109619, pero no todas las variantes
session.upload_progress.enabled = 0
; Solo aplica a PHP 8.5: bloquea la ruta confirmada del backtrace de error fatal
fatal_error_backtraces = 0

Dos precisiones importantes sobre esas dos directivas. Primero: el cambio debe aplicarse en php.ini, en el pool de FPM o en la configuración del servidor, y tiene que SURGIR EFECTO ANTES del parseo de la petición; no confíes en ini_set() ni en el .user.ini de FPM, porque llegan demasiado tarde. Después hay que reiniciar cada worker. Segundo: ocultar los diagnósticos con error_reporting, display_errors u @ no ayuda en nada, y el advisory lo dice para evitar el malentendido más común.

Y hay un motivo extra para activar session.upload_progress.enabled = 0 hoy: el 23 de octubre, el mismo día de este análisis, PHP publicó un aviso informativo pidiendo exactamente ese ajuste hasta la próxima versión de corrección regular, en preparación del CVE-2026-115560. El escenario de ese vector es poco común, porque la aplicación tiene que cambiar session.serialize_handler a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), pero “poco común” no es “imposible” y el ajuste no cuesta nada.

En el borde, el contrato con Cloudflare funciona así: los eventos de las reglas se consultan en Security > Security Analytics > Events, donde se puede filtrar por ID de regla para ver la petición que coincidió, la acción aplicada y la ruta. Los eventos de reglas de respuesta quedan bajo el servicio Managed Rules o Custom Rules, y se pueden filtrar por ID en la lista de reglas relativa. Si estás en plan de pago y quieres ajustar la cobertura, el scope del Managed Ruleset se puede limitar a las partes de la aplicación donde tenga sentido.

En hosting gestionado, el parche no depende de ti

Si tu PHP corre en cPanel, Plesk, Hostinger o cualquier hosting compartido, no tienes acceso al binario. Y ahí hay una trampa de proceso muy común: alguien entra al panel de selección de versión de PHP, cambia de 8.2 a 8.3 y cree que quedó parcheado. Eso no funciona. El parche de seguridad de PHP se aplica como actualización de la misma rama: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Cambiar de rama te deja en una versión que tampoco tiene el fix, y de paso puede romper extensiones, límites de memoria o la configuración de tu sitio.

La vía correcta en hosting gestionado es simple y a la vez incomoda: abrir un ticket y pedir explícitamente que apliquen el parche de PHP para CVE-2026-109618 y CVE-2026-109619 en tu rama actual, indicando la versión exacta que tienes y la fecha de tu instalación. Y mientras esperas, aplicar las mitigaciones provisionales del apartado anterior mediante .user.ini o el php.ini del panel, si el hosting lo permite, aceptando que ahí no aplicas php_admin_value y que el ajuste puede llegar tarde al parseo.

En la práctica, la respuesta de un hosting compartido ante un ticket de este tipo te dice una de dos cosas: “ya lo aplicamos en todas las instalaciones” o “no controlamos la versión de PHP de tu plan”. La primera es buena noticia. La segunda significa que tu única capa de control es reducir exposición: WAF activo, uploads restringidos, y si puedes, aislando el origen de la red pública como recomienda el CERT-EU.

Ejecutar tu plan de acción en las próximas 24 horas

Si recién te enteraste de esto, el orden de ataque importa, porque el tiempo corre desde que los identificadores de los CVE aparecen en foros públicos, no desde que lees la nota de prensa.

1. Verifica qué versión sirve tu web, no solo la del CLI, y contrasta con la lista de versiones corregidas: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
2. Confirma que Cloudflare está realmente delante y que tu Managed Ruleset está en modo block, no solo detectando.
3. Cierra el origin: revisa la IP directa, los hostnames alternos, el puerto de FPM y los puertos publicados por contenedores.
4. Aplica las mitigaciones provisionales con php_admin_value o php.ini, y reinicia todos los workers.
5. Pide el parche a tu hosting si no puedes actualizar tú, indicando la versión exacta y los dos CVE.
6. Revisa los logs en busca de intentos de explotación y, si usas WAF, filtra los eventos por los IDs de regla.
7. Revisa el plan de rollback: cuando llegue el parche, deshaz memory_limit = -1 y devuelve post_max_size a lo que tu aplicación necesite de verdad, porque memoria ilimitada es un riesgo de denegación de servicio por sí mismo.

Y una cosa más, la más difícil de aceptar: si tu aplicación procesa tráfico HTTP hecho a medida, es decir, si es una API, un webhook o un servicio que recibe peticiones de clientes que no son navegadores, la exposición es mayor de lo que sugiere un análisis de superficie. La documentación de php.net es explícita sobre este punto en los avisos de divulgación.

Preguntas frecuentes

Lee también

• PHP tardó 2 años en parchear una RCE: el fallo estructural que la PHP Foundation reconoció
• CVE-2026-35273: ShinyHunters evade WAF y reabren la explotación de Oracle PeopleSoft
• LunexStealer infecta más de 100 sitios con verificación falsa de Cloudflare
• Montaje de Servidor Web Linux: guía completa para sysadmins hispanohablantes