Cloudflare blinda PHP ante php2shell: parchea ya

php2shell: dos fallos críticos en el motor de PHP, no en tu código

El 21 de octubre de 2026, Calif.io, Wiz, OpenAI y Quarkslab divulgaron dos vulnerabilidades en PHP registradas como CVE-2026-109618 y CVE-2026-109619, conocidas en conjunto como php2shell. Afectan a todos los servidores web que ejecuten PHP 5.4 o posterior y permiten a un atacante provocar denegación de servicio, ejecución remota de código y exposición de datos cuando la aplicación procesa tráfico HTTP manipulado.

El detalle que cambia todo para un founder es este: el fallo está en el runtime de PHP, no en tu aplicación. Actualizar el código del sitio o un plugin no lo arregla. Hay que actualizar el software de PHP que corre en el servidor, y si tu hosting lo administra por ti, hay que pedírselo al proveedor.

Por qué php2shell es distinto a un plugin vulnerable

La diferencia de escala es brutal. Según datos recientes de W3Techs citados por Infosecurity Magazine, PHP está detrás de aproximadamente el 69,7% de los sitios web cuyo lenguaje de servidor se puede identificar. Cloudflare lo resume igual de crudo en su comunicado: PHP lo usa casi el 70% de los sitios.

Eso incluye WordPress, Drupal, Joomla y Magento, además de plataformas de e-commerce y servicios web. Si tu startup tiene un sitio corporativo, un blog o una tienda montada sobre cualquiera de esos CMS, estás dentro del perímetro afectado.

Help Net Security reporta que el impacto no se limita a una configuración específica: quedan expuestos PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed. Las instalaciones con modphp enfrentan el mayor riesgo, y un exploit funcional ya demostró que una sola petición no autenticada puede disparar el ataque antes de que se ejecute cualquier línea de código de la aplicación.

El investigador de seguridad Kevin Beaumont lo puso en términos poco tranquilizadores, citado por Help Net Security: "La situación de PHP va a generar una masa de incidentes, es una de las vulnerabilidades más grandes en años".

Cómo funciona: memoria que PHP no limpia a tiempo

Ambas fallas viven en la forma en que PHP maneja la memoria cuando algo sale mal mientras procesa una petición HTTP. Lo normal es que PHP reserve memoria para atender la petición y la libere al terminar. Si el procesamiento se interrumpe de forma inesperada, por ejemplo porque se agota la memoria, PHP no limpia esa memoria de forma segura.

• CVE-2026-109618: PHP se queda sin memoria e interrumpe su trabajo antes de que ciertos datos internos estén inicializados. Durante la limpieza de esa petición, PHP puede usar esos datos a medio construir como si fueran válidos.
• CVE-2026-109619: un error fatal interrumpe la petición y deja a PHP con referencias a memoria que ya fue liberada. Cuando el mismo proceso PHP atiende una petición posterior, puede seguir esas referencias obsoletas y acceder a memoria que ya no es válida, exponiendo datos sensibles.

Un atacante puede enviar peticiones HTTP diseñadas para disparar esas condiciones. Las peticiones grandes son una vía para presionar la memoria, pero el problema va más allá del consumo de recursos: manipulando los datos que PHP encuentra en esa memoria inválida, se puede tumbar el proceso, filtrar información o ejecutar código del atacante.

Qué hizo Cloudflare y por qué el WAF solo no alcanza

Cloudflare desplegó mitigaciones de WAF desde principios de octubre de 2026, unas 9 horas antes de la divulgación pública, y desde las 3:02 UTC del 21 de octubre los clientes con WAF gratuito o pago quedaron protegidos por defecto. La compañía trabajó en coordinación con la PHP Foundation, OpenAI y Wiz, entre otros.

Hay un matiz técnico que vale la pena entender porque explica hacia dónde va la seguridad de aplicaciones. Proteger contra php2shell exigió más que reglas basadas solo en la petición: los datos de la request no siempre alcanzan para distinguir un exploit de tráfico legítimo. La respuesta del origen agrega contexto y permite confirmar si el exploit tuvo éxito, reduciendo falsos positivos.

Para eso Cloudflare desarrolló full transaction detection, una capacidad nueva que combina señales de la petición y de la respuesta dentro de la misma transacción HTTP. Las reglas de respuesta pueden bloquear una respuesta del origen antes de que llegue a quien la pidió. Las protecciones de php2shell son las primeras detecciones gestionadas que usan esta capacidad.

El contexto de la divulgación tampoco fue limpio. Infosecurity Magazine reporta que un usuario publicó en un foro el 20 de octubre los identificadores CVE, que debían permanecer secretos hasta que existieran los parches, y que el equipo de PHP adelantó la fecha de publicación. Cloudflare confirmó que observó tráfico de ataque dirigido a sus clientes y que los atacantes mutaban el payload para intentar evadir las reglas.

Qué versiones parchear y cómo

Según Help Net Security, los parches de emergencia están en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones de Linux y los proveedores de soporte extendido recibieron los parches antes del anuncio público, así que conviene revisar con tu proveedor los paquetes actualizados.

El proyecto PHP ya no da soporte a PHP 8.1 y versiones anteriores, pero liberó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila desde código fuente o no tiene un proveedor de soporte extendido. Quien dependa de rpms.remirepo.net, un repositorio mantenido por voluntarios, debería migrar a paquetes de su distribución o compilar PHP desde el código fuente.

La NCSC del Reino Unido pidió parchear de inmediato y considerar sacar de línea cualquier sistema que no se pueda arreglar en el momento. CERT-EU emitió una recomendación en el mismo sentido: si el parche inmediato no es viable, aislar las aplicaciones expuestas a internet.

¿Qué significa esto para tu startup?

Si tu producto corre sobre PHP, este es el momento de tratarlo como un incidente, no como una tarea de mantenimiento. La ventana entre la filtración y el parche ya está abierta, y The News reporta que la explotación activa en el mundo real fue confirmada por Cloudflare y otros investigadores.

Acciones concretas que puedes ejecutar hoy:

• Actualiza el runtime, no solo el CMS. Sube a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usas un hosting gestionado, abre un ticket pidiendo la actualización por escrito y con fecha: es tu única palanca real.
• Mantén el WAF activo mientras parcheas. Cloudflare lo aplica por defecto en todos los planes, incluido el gratuito. Si estás en plan Professional, Business o Enterprise, revisa que tu Managed Ruleset esté desplegado en modo bloqueo.
• Revisa los eventos de seguridad. En el panel de Cloudflare, filtra por los IDs de regla de php2shell y revisa petición, acción y ruta para saber si alguien ya te está probando.
• Haz forense después del parche. The News recomienda revisar logs hasta junio de 2026 buscando web shells, archivos modificados, usuarios administradores no autorizados y conexiones salientes anómalas.
• Reduce superficie mientras tanto. Limitar las subidas innecesarias y el tamaño máximo de archivos baja la exposición, pero no reemplaza el parche de PHP.

Hay un punto de gestión que suele pasarse por alto: si tu equipo tiene aplicaciones olvidadas, entornos de staging o instalaciones embebidas que nadie mantiene, esas son las que van a quedar sin parchear. El experto en forense Hal Pomeranz lo advirtió en Help Net Security: "hay muchísimas instalaciones embebidas que nunca se van a parchear, demasiadas apps olvidadas y sin mantenimiento. Esta va a tener una cola larga".

Para un founder, la lección de arquitectura es más profunda que este CVE. La seguridad de una startup no se mide por lo bien escrito que esté su código, sino por cuánto de su stack depende de software que no controla. Inventariar ese stack, saber quién lo actualiza y tener un canal directo con el proveedor de hosting es una inversión que se paga sola la próxima vez que aparezca un php2shell.

Fuentes

• Cloudflare deploys protections against php2shell vulnerability (fuente original)
• PHP2Shell: Critical PHP vulnerabilities patched, update now!
• Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches
• Critical PHP security vulnerabilities: How to fix them