En resumen: WAF en lugar de actualizar no funciona con PHP2Shell. Un firewall de aplicaciones web, es decir, un filtro delante del sitio web, examina las peticiones y puede bloquear patrones de ataque conocidos. Pero la vulnerabilidad en sí está en el intérprete de PHP y solo desaparece con la actualización y el reinicio de todos los procesos de PHP. Un WAF es una capa adicional razonable y un puente de unos pocos días, no la solución.
Por qué esta pregunta se plantea ahora con tanta frecuencia
Muchos operadores leyeron en la semana de PHP2Shell una noticia aparentemente buena: Cloudflare tiene, según sus propias indicaciones, reglas de protección activas desde el 21 de octubre de 2026, 03:02 UTC, también para clientes de la tarifa gratuita. Quien de todos modos está detrás de Cloudflare o de otro WAF se pregunta, comprensiblemente, si entonces la actualización sigue siendo urgente.
La respuesta honesta es sí. El propio Cloudflare matiza: las reglas basadas solo en los datos de la petición no bastan, por lo que el servicio examina además la respuesta del servidor. Cloudflare ha observado además patrones de ataque modificados. Y la protección solo actúa para el tráfico que realmente pasa por Cloudflare. Los detalles sobre este proveedor los describe Reglas de protección de Cloudflare contra PHP2Shell. Aquí se trata de la ponderación de fondo, independiente del proveedor.
Qué ve un WAF y qué cambia una actualización
Un WAF se sitúa delante de la aplicación. Ve cada petición, la compara con reglas y la deja pasar, la bloquea o la registra. No sabe cómo procesa PHP internamente la petición. Pero las dos vulnerabilidades de PHP2Shell surgen justo ahí: CVE-2026-109618 en una condición de falta de memoria mientras los datos de la petición solo están inicializados en parte, y CVE-2026-109619 por un estado interno que persiste tras una petición en el mismo worker.
La actualización corrige ese código. Después la causa está eliminada, sea cual sea el aspecto de una petición. Quien quiera entender en qué punto del procesamiento de una petición ocurre esto encontrará los fundamentos en El ciclo de vida de una petición en PHP.
WAF en lugar de actualizar: la comparación honesta
| Criterio | Firewall de aplicaciones web | Actualización de PHP con reinicio |
|---|---|---|
| ¿Qué se corrige? | Nada, se frenan patrones conocidos | La causa en el intérprete de PHP |
| Protección ante nuevas variantes de ataque | Solo si las reglas se adaptan a tiempo | Sí, la vulnerabilidad ya no existe |
| ¿Es posible eludirlo? | Sí, por ejemplo por la accesibilidad directa del servidor de origen | No, siempre que todos los procesos de PHP se hayan reiniciado |
| Rapidez | A menudo activo de inmediato | Depende de la versión, el acceso y la ventana de mantenimiento |
| Efectos secundarios | Falsas alarmas, formularios o subidas perturbados | Raros; en saltos de versión hacen falta pruebas de compatibilidad |
| Utilidad ante la próxima vulnerabilidad | Alta, si está mantenido | Ninguna, cada vulnerabilidad necesita su propia actualización |
| ¿Ayuda con PHP 8.1 y anteriores? | Como transición | Solo mediante backport o migración |
La tabla muestra por qué ambas medidas van juntas. El WAF es rápido y amplio, pero nunca completo. La actualización es completa, pero solo para una vulnerabilidad concreta y no siempre posible de inmediato.
En la práctica se pasa por alto a menudo un punto: un WAF cambia el comportamiento del sitio web. Las reglas estrictas pueden bloquear pedidos legítimos, formularios de contacto o subidas de archivos sin que nadie lo note enseguida. Quien activa un WAF en modo estricto en plena crisis debería por ello recorrer una vez por sí mismo los flujos más importantes del sitio web y revisar los registros de los primeros días en busca de peticiones bloqueadas pero legítimas.
Cómo combinar ambos con sentido
- De inmediato: comprobar si hay un WAF y si las reglas adecuadas están activas. En Cloudflare, en las tarifas de pago, poner el Managed Ruleset en Block, según el proveedor.
- De inmediato: asegurarse de que el servidor de origen solo sea accesible a través del WAF, por ejemplo mediante una autorización en el firewall solo para sus rangos de direcciones. De lo contrario, la protección no sirve de nada.
- Dentro de la próxima ventana de mantenimiento: actualizar PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o instalar el backport confirmado de la distribución.
- Justo después: reiniciar todos los workers y procesos de PHP y comprobar que no queda ningún proceso antiguo en ejecución. Los archivos nuevos por sí solos no bastan; más información en Tras la actualización: reiniciar PHP-FPM y todos los workers.
- Después: mantener las reglas del WAF, analizar las falsas alarmas y fijar excepciones de forma dirigida en lugar de desactivar reglas en bloque.
Con un WAF propio basado en ModSecurity y el OWASP Core Rule Set se puede lograr algo similar; los fundamentos los describe Usar ModSecurity y el OWASP Core Rule Set. Una forma especial es el filtrado, propuesto por autores especializados, de las peticiones de subida fuera de las rutas de subida reales. No es oficial, puede romper formularios y solo debe pasar a producción tras una prueba.
Ni el WAF ni la actualización eliminan el software malicioso introducido antes. Compruebe tras el parche si desde el 17 de octubre de 2026 han aparecido anomalías.
Cuándo no necesita un WAF y cuándo no necesita un proveedor de servicios
Un WAF no es obligatorio para todo sitio web. Un pequeño sitio web corporativo en un proveedor de alojamiento que parchea PHP con prontitud y lo confirma suele estar suficientemente protegido sin WAF propio si el CMS y los plugins están actualizados. Tampoco necesita el WAF como puente quien puede actualizar su servidor por sí mismo en poco tiempo.
Cobra sentido en tiendas, portales y aplicaciones con muchos formularios, en sistemas antiguos que no pueden actualizarse de inmediato y donde se quiere proteger de forma centralizada varios sitios web. Un proveedor de servicios solo lo necesita para ello si la configuración, las pruebas y el mantenimiento continuo no están cubiertos internamente.
¿Cómo ayuda PHP SOS en concreto?
- Comprobamos si su WAF está realmente delante de todos los accesos y si el servidor de origen es accesible directamente.
- Configuramos o adaptamos las reglas y probamos formularios, subidas e interfaces en busca de efectos secundarios.
- Instalamos la actualización de PHP, reiniciamos todos los procesos y documentamos el estado.
- Donde la actualización se demora, la cubrimos con WAF y parcheo virtual y una fecha fija para el parche real.
Conclusión
La pregunta «¿WAF o actualización?» está mal planteada. La actualización cierra la vulnerabilidad; el WAF da tiempo y frena muchas otras cosas. Quien apuesta solo por el WAF confía en reglas que los atacantes pueden eludir. Quien solo parchea se queda sin puente ante la próxima vulnerabilidad.
Preguntas frecuentes
¿Basta un WAF como protección contra PHP2Shell?
No. Un WAF examina el tráfico y puede bloquear patrones de ataque conocidos. La vulnerabilidad en sí está en el intérprete de PHP y permanece hasta que PHP se actualiza y se reinicia. Cloudflare subraya expresamente que sus reglas no sustituyen a la actualización.
¿Estoy protegido automáticamente detrás de Cloudflare?
Solo para el tráfico que realmente pasa por Cloudflare. Si el servidor de origen es accesible directamente desde internet, la protección se elude. En las tarifas de pago debería comprobar, según Cloudflare, que el Managed Ruleset esté en Block.
¿Compensa un WAF después de la actualización?
A menudo sí. Un WAF puede frenar escaneos masivos, ataques conocidos contra plugins y el uso indebido de páginas de inicio de sesión, y da tiempo ante la próxima vulnerabilidad. Pero necesita mantenimiento y pruebas; de lo contrario, las falsas alarmas perturban el funcionamiento.
¿Qué es el parcheo virtual?
Se refiere a proteger temporalmente una vulnerabilidad mediante reglas situadas delante de la aplicación, en lugar de modificar el código. Es un puente hasta la actualización real, no un sustituto.