PHP2Shell: protege PHP con Cloudflare WAF mientras parcheas
Resume este artículo con tu IA
Cómo bloquear PHP2Shell (CVE-2026-109618/19) con las 7 reglas de Cloudflare WAF mientras actualizas PHP. Paso a paso, ID de reglas y verificación.
PHP mueve una parte enorme de la web: webs corporativas, tiendas online, intranets, portales de clientes, campus virtuales… Muchas veces sin que nadie en la empresa recuerde que está ahí. Por eso PHP2Shell afecta a tantas organizaciones a la vez.
El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas en el núcleo de PHP que permiten la ejecución remota de código sin autenticación, con los privilegios del proceso del servidor web. Afectan a cualquier instalación de PHP que sirva peticiones web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed), con independencia de la aplicación: WordPress, Drupal, Joomla o un desarrollo propio. Ya hay explotación activa.
Cloudflare desplegó, horas antes de la divulgación pública, 7 reglas específicas en su conjunto de reglas administradas (WAF) que bloquean los patrones de explotación conocidos. En esta guía te explicamos, paso a paso, cómo activarlas y dejarlas en modo Bloquear sin afectar al tráfico legítimo.
Importante: el WAF da tiempo, el parche resuelve. Las reglas del WAF son una capa de contención temporal. La corrección definitiva es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 (o a un paquete de tu distribución con el parche retroportado). Actualizar el CMS o sus plugins no basta: el fallo está en PHP.
¿Tu web no pasa por Cloudflare? La prioridad es la misma: localizar dónde tienes PHP y actualizarlo cuanto antes. Si cuentas con otro WAF (AWS WAF, Azure, Akamai, Imperva o ModSecurity/Coraza), revisa qué reglas ha publicado tu proveedor para estas CVE. Las medidas complementarias del final de esta guía te sirven en cualquier caso.
Contenido de la guía
- Resumen y acciones prioritarias
- Contexto de la vulnerabilidad
- Alcance y requisitos previos
- Configuración paso a paso en Cloudflare
- Verificación y monitorización
- Falsos positivos y reversión
- Medidas complementarias
- Referencias
1. Resumen y acciones prioritarias
| 2 | CVE críticas · RCE sin autenticación |
| 7 | Reglas WAF de PHP2Shell en modo Bloquear |
| 5 | Pasos de configuración |
| ~15 min | Tiempo estimado por zona |
| Plazo | Acción |
|---|---|
| 0-24 h · Inmediato | Activar el conjunto de reglas administradas y poner las 7 reglas PHP2Shell en Bloquear en todas las zonas con aplicaciones PHP. |
| 0-72 h · Urgente | Actualizar PHP en servidores, contenedores y hosting gestionado expuestos a Internet. |
| Continuo · Monitorización | Revisar los eventos de seguridad filtrando por los ID de regla y ajustar excepciones ante falsos positivos. |
2. Contexto de la vulnerabilidad
Ambos fallos se originan en que PHP deja la memoria en un estado corrupto cuando una petición termina de forma anómala. Los descubrieron investigadores de Calif, OpenAI y Wiz, que demostraron ejecución remota de código sin autenticación contra WordPress, Drupal y Joomla.
| Identificador | Descripción | Severidad |
|---|---|---|
| CVE-2026-109618 | Encadenamiento de debilidades que provoca corrupción de memoria por agotamiento (out-of-memory) y permite ejecución remota de código con la cuenta del proceso web. | Crítica |
| CVE-2026-109619 | Estado global obsoleto (stale global state) que permite use-after-free en heap sin autenticación, divulgación de memoria del proceso y ejecución remota de código. | Crítica |
Versiones afectadas y corregidas
| Rama | Vulnerable | Corregida |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 7.4 – 8.1 | Todas | Backport en código fuente / proveedor LTS |
| ≤ 7.3 | Todas | Migrar a una versión soportada |
Superficie expuesta
| SAPI / despliegue | Riesgo |
|---|---|
| Apache + mod_php | Máximo |
| PHP-FPM | Alto |
| php-cgi | Alto |
| FrankenPHP | Alto |
| LiteSpeed (LSAPI) | Alto |
En mod_php existe un exploit demostrado que se dispara antes de ejecutar código de la aplicación.
Cronología
- 20/10 · Aviso previo: el equipo de PHP anuncia la publicación inminente de parches de seguridad críticos.
- 21/10, 03:02 UTC · Cloudflare: despliega las 7 reglas en sus conjuntos administrados (Free y de pago) y observa los primeros intentos de explotación.
- 21/10 · Divulgación pública: publicación de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y de los avisos de seguridad.
3. Alcance y requisitos previos
Esta guía aplica a todas las zonas (dominios) gestionadas en Cloudflare que publiquen aplicaciones o servicios basados en PHP, o en las que no tengas certeza de la tecnología del origen. Cubre la configuración del WAF a nivel de zona desde el panel de Cloudflare.
Cobertura según tu plan de Cloudflare
| Plan | Conjunto de reglas | Qué tienes que hacer |
|---|---|---|
| Free | Cloudflare Managed Free Ruleset | La protección se despliega automáticamente. Solo tienes que verificarla (sección 5). |
| Pro · Business · Enterprise | Cloudflare Managed Ruleset | Sigue esta guía: activa el conjunto y confirma las 7 reglas en Bloquear. |
| Todos | Managed Response Firewall Default | La regla de respuesta Default block for High confidence Signatures viene activa por defecto. |
Antes de empezar, asegúrate de tener
- Acceso: rol Super Administrator, Administrator o Firewall / WAF Admin sobre la zona.
- Inventario: las zonas con backend PHP y el responsable técnico de cada aplicación.
- Gestión del cambio: una ventana de cambio aprobada o el procedimiento de cambio de emergencia activado (riesgo crítico con explotación activa).
- Línea base: el estado inicial del Conjunto de reglas administradas (activo o inactivo) y las anulaciones existentes, anotados.
- Comunicación: un canal con negocio para avisar de posibles bloqueos de tráfico legítimo.
Elige tu escenario según el estado inicial
| Escenario A · Conjunto ya activo | Escenario B · Conjunto no activo |
|---|---|
| Mantén la configuración existente y verifica que ninguna anulación desactiva o rebaja la acción de las 7 reglas PHP2Shell. Fuérzalas a Bloquear si hace falta. | Activa el conjunto (≈ 837 reglas) con la acción del conjunto en Registro (Log) para proteger producción, y anula solo las 7 reglas PHP2Shell a Bloquear. |
El número total de reglas del conjunto administrado puede variar con las actualizaciones de Cloudflare. Si tu plan no ofrece la acción Registro, mantén la acción predeterminada del conjunto y refuerza la monitorización de eventos durante las primeras 48 h.
4. Configuración paso a paso en Cloudflare
Paso 1 · Accede a la zona
Inicio de la cuenta → Dominios → <dominio>
Inicia sesión en dash.cloudflare.com y selecciona la cuenta correspondiente. En el menú lateral, abre Dominios y selecciona el dominio que quieres proteger. Repite el procedimiento completo para cada zona del inventario con backend PHP.
Consejo: usa la Búsqueda rápida (⌘K / Ctrl+K) para localizar la zona directamente si gestionas muchos dominios.
Paso 2 · Abre la configuración de seguridad
<dominio> → Seguridad → Configuración
Dentro de la zona, despliega el menú Seguridad y pulsa Configuración. Esta vista reúne las herramientas de detección y protección de la zona, incluido el WAF administrado.
Paso 3 · Activa el Conjunto de reglas administradas de Cloudflare
Seguridad → Configuración → Conjunto de reglas administradas de Cloudflare
Localiza el bloque Conjunto de reglas administradas de Cloudflare (puedes filtrar por el grupo Exploits de aplicaciones web) y comprueba el interruptor de Estado:
- Activo → Escenario A. Pulsa Ver conjunto de reglas para revisar las anulaciones existentes y continúa en el Paso 4.
- Inactivo → Escenario B. Activa el interruptor; al desplegar el conjunto, establece la acción del conjunto en Registro (Log) y guarda.
Escenario B: por qué empezar en modo Registro. Activar de golpe el conjunto completo (≈ 837 reglas) en bloqueo sobre una aplicación que nunca lo ha tenido puede generar falsos positivos y cortes de servicio. En modo Registro el resto de reglas solo registra eventos, lo que te permite analizarlos y pasarlas a bloqueo de forma controlada más adelante.
Las 7 reglas PHP2Shell, en cambio, deben quedar en Bloquear desde el primer momento mediante anulación individual (Paso 4).
Paso 4 · Anula las 7 reglas PHP2Shell a Bloquear
Ver conjunto de reglas → Buscar / filtrar por etiqueta → Anulaciones de reglas
Desde Ver conjunto de reglas (o editando la regla de implementación Execute del conjunto en Reglas de seguridad → Reglas administradas), busca las reglas de PHP2Shell filtrando por las etiquetas cve-2026-109618 y cve-2026-109619 o por la descripción PHP Remote Code Execution Attack.
Selecciona las 7 reglas, establece Acción: Bloquear y Estado: Habilitado, y pulsa Aplicar configuración del conjunto de reglas. El resultado debe coincidir con la Figura 4.
Referencia: ID de las reglas (Cloudflare Managed Ruleset · Pro, Business y Enterprise)
Cloudflare ha indicado que las descripciones de estas reglas pueden cambiar (inicialmente se publicaron como Generic Rules – Anomalous Execution 1-7). Identifícalas siempre por su ID. Todas llevan las etiquetas php, cve-2026-109618 y cve-2026-109619.
| # | ID de la regla | Acción | Estado |
|---|---|---|---|
| 01 | c1d409ad838f47f59446f21cc438d5dd | Bloquear | Habilitado |
| 02 | f9a45927414245e3a64bb12d0a0c2f64 | Bloquear | Habilitado |
| 03 | 771c654ae1154d4daa72f4e1545d163c | Bloquear | Habilitado |
| 04 | 217005865f0145f392300bac212afcc9 | Bloquear | Habilitado |
| 05 | 38efdb17ea594501bb55a1d71867b12e | Bloquear | Habilitado |
| 06 | 4148ae686fdb4d01be673fab9d9c073d | Bloquear | Habilitado |
| 07 | 1389aa259617437392ce149c48143645 | Bloquear | Habilitado |
| ID del conjunto (planes de pago) | efb7b8c949ac4650a09736fc376e9aee |
| ID del conjunto (plan Free) | 77454fe2d30c4220b5701f6fdfb893ba |
| Regla de respuesta (todos los planes) | afffe22785674c80a31875c848d2242a |
Precedencia: las excepciones (skip) se evalúan antes que las anulaciones. Comprueba que ninguna regla de excepción omite el conjunto administrado para rutas o hosts PHP de la zona.
Paso 5 · Despliega y confirma la configuración
Reglas de seguridad → Reglas administradas
Guarda e implementa los cambios. Después, en Reglas de seguridad, filtra por Reglas administradas y comprueba que la regla de implementación del conjunto aparece habilitada y que sus anulaciones reflejan:
- Acción del conjunto: predeterminada (Escenario A) o Registro (Escenario B).
- Las 7 reglas PHP2Shell en Bloquear · Habilitado.
- Ninguna anulación o excepción adicional que deshabilite estas reglas.
Deja constancia del cambio: zona, fecha y hora, escenario aplicado y persona que lo ejecutó.
5. Verificación y monitorización
Tras el despliegue, valida que la protección está operativa y vigila la actividad asociada. Que no aparezcan eventos no garantiza que las reglas estén activas: confirma siempre también la configuración (Paso 5).
Revisión de eventos de seguridad
- Acceso: abre Seguridad → Análisis → Eventos de la zona.
- Filtro: Agregar filtro → campo ID de regla → operador es igual a → introduce cada uno de los 7 ID (o filtra por el servicio Reglas administradas).
- Ventana: empieza con intervalos cortos (últimas 24 h) y amplía progresivamente.
- Análisis: expande cada evento para revisar petición, ruta, IP de origen, ASN, país y acción aplicada (Bloquear).
Lista de comprobación tras la implantación
- ☐ Conjunto de reglas administradas de Cloudflare activo en la zona.
- ☐ Las 7 reglas PHP2Shell en Bloquear · Habilitado, verificadas por ID.
- ☐ Ninguna excepción que omita el conjunto en hosts o rutas PHP.
- ☐ Aplicación accesible y funcional tras el cambio (prueba rápida de login, formularios y subida de ficheros).
- ☐ Eventos de bloqueo revisados e IPs atacantes correlacionadas en tu SIEM/MDR y, si procede, bloqueadas.
- ☐ En el Escenario B: revisión de los eventos en modo Registro a las 48-72 h para planificar el paso a bloqueo del conjunto completo.
- ☐ Cambio documentado con evidencias (capturas de las anulaciones y de los eventos).
Revisa si hubo compromiso previo. Si ves bloqueos de estas reglas, o la zona estuvo expuesta sin protección antes del 21/10/2026, revisa en el servidor de origen: procesos hijos inesperados del usuario del servidor web, ficheros PHP nuevos o modificados en directorios web o de subida, y conexiones salientes anómalas. Ante cualquier indicio, escala a tu equipo de respuesta a incidentes (DFIR).
6. Falsos positivos y reversión
Gestión de falsos positivos
Si alguna de las 7 reglas bloquea tráfico legítimo, mantén activos el conjunto y las reglas y aplica la medida más acotada posible:
- Identifica: localiza en Eventos el ID de regla, la ruta, el método y los parámetros implicados.
- Acota: crea una regla de excepción que omita únicamente ese ID para la ruta, el host o la IP de origen concretos (por ejemplo, integraciones de confianza).
- Compensa: prioriza el parcheo de PHP en ese origen y documenta el riesgo aceptado con fecha de caducidad de la excepción.
Plan de reversión
| Situación | Cómo actuar |
|---|---|
| Escenario B con impacto generalizado | Mantén las 7 anulaciones en Bloquear y verifica que la acción del conjunto está en Registro. Si el impacto persiste, revisa los eventos por ID antes de desactivar nada. |
| Falso positivo de una regla PHP2Shell | Excepción acotada por ID de regla y ruta (ver arriba), manteniendo las 7 reglas activas a nivel global. |
| Error de configuración | Restaura la línea base documentada (estado inicial del conjunto y anulaciones) y repite desde el Paso 3. |
Aprobación: desactivar por completo las reglas PHP2Shell en una zona con PHP sin parchear expone un RCE crítico con explotación activa. Esa decisión requiere la aprobación expresa del responsable de seguridad, por escrito.
Quién hace qué
| Rol | Responsabilidad |
|---|---|
| Operador SOC / MDR | Ejecución de los pasos 1-5, verificación y monitorización de eventos. |
| Responsable de la aplicación | Pruebas funcionales, validación de falsos positivos y parcheo de PHP. |
| Responsable de seguridad | Aprobación del cambio, de las excepciones y aceptación de riesgos. |
7. Medidas complementarias
Estas medidas aplican a cualquier servidor con PHP, esté o no detrás de Cloudflare.
- Corrección definitiva: actualiza PHP a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, reconstruye y redespliega los contenedores y verifica la versión efectiva (
php -vy la SAPI en uso). Exige el parche a tus proveedores de hosting gestionado. - Mitigación parcial de CVE-2026-109618:
memory_limit=-1(víaphp_admin_value),post_max_sizea 8M (sin subidas) o 32M, y límites de contenedor/cgroup que terminen solo el worker afectado. - Mitigación parcial de CVE-2026-109619:
session.upload_progress.enabled=0; en PHP 8.5,fatal_error_backtraces=0; reinicia todos los workers y corrige los errores fatales alcanzables por un atacante. - Reducción de exposición: restringe el acceso a los servicios aún sin parchear (lista de permitidos, Zero Trust) o retíralos temporalmente; limita las subidas de ficheros y su tamaño.
8. Referencias
- BleepingComputer · PHP ships emergency patches for critical PHP2Shell flaws (21/10/2026).
- Endor Labs · PHP2Shell: critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619).
- PPC Land · Cloudflare blocks PHP2Shell exploits 9 hours before PHP flaws went public.
- Techdows · Cloudflare PHP2Shell WAF rule: how to turn it on and why it is not a fix.
- Cloudflare Docs · WAF Managed Rules: anulaciones y excepciones de conjuntos administrados.
Información vigente a 23/10/2026. Cloudflare puede añadir o modificar reglas a medida que evolucionen las cargas de ataque; revisa periódicamente las etiquetas cve-2026-109618 y cve-2026-109619 en el conjunto administrado.
¿Te ayudamos a revisar tu exposición?
El equipo SOC/MDR de Cylum puede ayudarte a localizar dónde tienes PHP, aplicar esta configuración en tus zonas de Cloudflare o en tu WAF actual y vigilar los intentos de explotación mientras completas el parcheo.
