# Reglas de protección de Cloudflare contra PHP2Shell: qué logran y qué no > Cloudflare protege con reglas WAF contra PHP2Shell desde el 21/10. Qué cubren las reglas, dónde pueden eludirse y qué debe revisar usted ahora mismo. Fuente: https://phpsos.de/es/blog/cloudflare-waf-php2shell/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** Según sus propias indicaciones, Cloudflare tiene activas desde el 21 de octubre de 2026, a las 03:02 UTC, reglas de protección contra PHP2Shell, también para clientes del plan gratuito. Las reglas reducen el riesgo para el tráfico que pasa por Cloudflare. No actúan si el servidor de origen es accesible directamente y no sustituyen la actualización de PHP. Quien use Cloudflare debería revisar el modo de las reglas, la protección del origen y el nivel de parcheo. ## El punto de partida: protección ya antes del parche Cloudflare llegó con PHP2Shell inusualmente pronto. Según el blog de Cloudflare, las reglas de protección estaban activas varias horas antes de la publicación oficial de las actualizaciones de PHP a las 14:00 UTC. Cloudflare informó además de haber observado intentos de ataque contra clientes y de que los atacantes modificaban sus patrones para eludir las reglas. Muchos administradores han concluido: «Estamos detrás de Cloudflare, así que estamos protegidos». Eso solo es cierto en parte. Este artículo explica qué cubren realmente las reglas. Una ponderación general entre cortafuegos y actualización la ofrece el artículo [¿WAF o actualización?](https://phpsos.de/es/blog/waf-oder-update/). ## Qué ha desplegado Cloudflare contra PHP2Shell Según el blog de Cloudflare, hay tres elementos: | Plan | Protección según Cloudflare | Qué debería hacer | |---|---|---| | Free | nuevas reglas en el Managed Free Ruleset, activas automáticamente | comprobar que el dominio pasa por Cloudflare | | Pro, Business, Enterprise | reglas correspondientes en el Managed Ruleset | asegurarse de que el ruleset esté en «Block» | | todos los planes | regla estándar en el nuevo cortafuegos de respuestas | no desactivar nada, observar los eventos | El tercer elemento es nuevo. Cloudflare lo llama «full transaction detection»: el WAF examina no solo la petición, sino también la respuesta del servidor. El motivo, según Cloudflare: la petición por sí sola no siempre basta para distinguir con seguridad un ataque del tráfico normal. PHP2Shell es el primer uso de esta función en las reglas gestionadas. ## Los límites de las reglas de Cloudflare Por útiles que sean las reglas, tienen límites claros, que Cloudflare mismo menciona en parte: - **Solo el tráfico a través de Cloudflare:** las reglas examinan lo que fluye por Cloudflare. Si el servidor de origen es accesible directamente por su dirección IP, un atacante puede eludir la protección. - **No se puede deshacer:** según Cloudflare, una regla en el lado de la respuesta puede retener la respuesta, pero no deshacer lo que ya ha ocurrido en el servidor. - **Patrones de ataque cambiantes:** Cloudflare ajusta las reglas continuamente porque los atacantes modifican sus peticiones. Entre una nueva variante y una nueva regla puede haber un hueco. - **No sustituye la actualización:** Cloudflare recomienda expresamente actualizar PHP a pesar del WAF. Tampoco una actualización del código de la aplicación o de los plugins corrige las vulnerabilidades. - **Caso especial CVE-2026-115560:** según la ampliación de Cloudflare del 23 de octubre, la regla no actúa si se ha cambiado en la configuración el nombre del seguimiento del progreso de subida de sesión. Más sobre este aviso en [CVE-2026-115560](https://phpsos.de/es/php2shell/cve-2026-115560/). ### Qué dicen y qué no dicen las peticiones bloqueadas Muchos clientes, tras el aviso, miran sus eventos de seguridad y encuentran allí peticiones bloqueadas. Eso solo demuestra, en primer lugar, que su dominio fue examinado y que la regla actuó. No prueba una intrusión. Y al revés, una lista de eventos vacía no es una señal de tranquilidad: si un ataque se dirigió directamente al servidor de origen o se produjo antes del 21 de octubre, no aparece en Cloudflare en absoluto. Más fiable es el contraste con los registros del propio servidor web. Las peticiones que llegan allí pero no proceden de direcciones de Cloudflare apuntan a un acceso directo. Conserve esos registros desde el 20 de octubre, como aconseja la prensa especializada. Cloudflare señala además que las restricciones a las subidas pueden reducir el riesgo, pero no sustituyen la actualización de PHP. > **Importante:** > La debilidad más frecuente detrás de Cloudflare no es la regla, sino el camino que la esquiva: un servidor de origen que responde directamente por su dirección IP o por un subdominio no protegido. ## Lista de comprobación para clientes de Cloudflare Usted o su proveedor de servicios pueden hacer estos pasos a corto plazo: 1. **Revisar el plan y el modo de las reglas:** en los planes de pago, comprobar en el panel que el Managed Ruleset esté activo en modo «Block». 2. **Mirar los eventos de seguridad:** en Security Events, comprobar si aparecen peticiones bloqueadas. Eso muestra si sus dominios ya fueron objetivo. 3. **Repasar las entradas DNS:** toda entrada que apunte al servidor web pero no pase por Cloudflare es un posible rodeo. Son típicos los subdominios de staging, FTP o correo en el mismo servidor. 4. **Blindar el origen:** configurar el servidor web para que acepte HTTP y HTTPS solo desde Cloudflare, por ejemplo con un cortafuegos con los rangos de direcciones publicados por Cloudflare o mediante un túnel. Cómo hacerlo en general lo describe el artículo [Cortafuegos para servidores web](https://phpsos.de/es/blog/firewall-fuer-webserver/). 5. **Probar el acceso directo:** comprobar desde fuera si el origen responde sin Cloudflare. 6. **Actualizar PHP y reiniciar:** las reglas son la segunda línea. La primera es PHP en una versión corregida con el [reinicio de todos los procesos de PHP](https://phpsos.de/es/php2shell/php-fpm-neustart/). Para el paso 5 basta una prueba inofensiva que solo consulta las cabeceras. La dirección IP es un marcador de posición de su servidor de origen: ```bash # ¿Responde el servidor de origen directamente, sin pasar por Cloudflare? curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/ ``` Si aquí llega una respuesta normal de su sitio web, el origen es accesible directamente y la protección de Cloudflare puede eludirse. ## ¿Cómo ayuda PHP SOS en concreto? - **Revisión de la configuración:** comprobamos el modo de las reglas, las entradas DNS y el acceso directo al servidor de origen. - **Proteger el origen:** limitamos el servidor web al tráfico a través de Cloudflare sin interrumpir su sitio web. - **Parche y justificante:** actualizamos PHP, reiniciamos todos los procesos y documentamos el estado. - **Evaluar los eventos:** revisamos las peticiones bloqueadas y las contrastamos con los registros del servidor. Cómo combinamos las reglas WAF y las medidas provisionales lo describe [WAF y parcheo virtual](https://phpsos.de/es/leistungen/waf-virtuelles-patching/). ## Conclusión Las reglas de Cloudflare contra PHP2Shell son una ventaja real, sobre todo porque llegaron pronto y también al plan gratuito. Pero son un escudo delante de la puerta, no una cerradura en la puerta. Quien esté detrás de Cloudflare debería asegurar tres cosas: reglas en modo Block, ningún camino que esquive el proxy y PHP en una versión corregida. ## Preguntas frecuentes **¿Estoy protegido contra PHP2Shell con el plan gratuito de Cloudflare?** Según Cloudflare, los clientes del plan Free también reciben las reglas de protección automáticamente. Pero solo actúan sobre el tráfico que pasa por Cloudflare y no sustituyen la actualización de PHP en el servidor. Si el servidor de origen es accesible directamente, la protección no actúa. **¿Qué debo configurar en los planes de pago de Cloudflare?** Cloudflare aconseja a los clientes de los planes Pro, Business y Enterprise comprobar que el Managed Ruleset funcione en modo Block. Si solo está en modo de registro, los ataques se registran, pero no se detienen. **¿Qué es full transaction detection?** Una nueva función del WAF de Cloudflare que examina no solo la petición, sino también la respuesta del servidor. Así se puede reconocer si un intento de ataque surte efecto y retener la respuesta. Según Cloudflare, no deshace lo que ya se haya ejecutado en el servidor. **¿Cloudflare cubre también CVE-2026-115560?** Cloudflare completó su artículo el 23 de octubre con CVE-2026-115560. Según Cloudflare, la regla correspondiente no actúa si se ha cambiado en la configuración de PHP el nombre del seguimiento del progreso de subida de sesión. Con independencia de ello, php.net recomienda fijar session.upload_progress.enabled=0. ## Fuentes - [Blog de Cloudflare: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) - [Blog de Cloudflare: Introducing full transaction detection for Cloudflare WAF](https://blog.cloudflare.com/full-transaction-waf/) - [php.net: avisos de seguridad](https://www.php.net/)