Cloudflare ya ofrece una mitigación para las vulnerabilidades críticas de PHP: cómo funciona y cómo activarla

Dos vulnerabilidades críticas recientemente divulgadas afectan al motor PHP y podrían permitir la ejecución remota de código sin autenticación. Mientras los administradores trabajan en actualizar sus servidores, Cloudflare ya desplegó medidas de mitigación desde su firewall de aplicaciones web (WAF), incluso para quienes utilizan su plan gratuito.

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de seguridad para corregir las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, conocidas conjuntamente como php2shell. Ambas recibieron una puntuación de severidad de 9,2 bajo CVSS 4.0.

Su gravedad ha obligado a administradores, proveedores de hosting y responsables de seguridad a revisar rápidamente las versiones de PHP utilizadas por sus aplicaciones.

Sin embargo, actualizar una infraestructura productiva no siempre es tan sencillo como ejecutar un comando. Existen aplicaciones heredadas, extensiones que deben mantenerse compatibles y sistemas donde cualquier cambio requiere planificación.

La noticia importante: Cloudflare confirmó que ya desplegó protecciones específicas para mitigar intentos de explotación de estas vulnerabilidades. Están disponibles incluso en su plan gratuito y, cuando el WAF se encuentra desplegado, no requieren configurar nuevas reglas manualmente.

¿Qué ocurre con estas vulnerabilidades de PHP?

A diferencia de otras vulnerabilidades ampliamente conocidas en el ecosistema web, este problema no se encuentra en un plugin de WordPress ni en una aplicación determinada. Afecta al propio motor que ejecuta PHP.

Las fallas están relacionadas con la manera en que PHP administra la memoria durante situaciones excepcionales de procesamiento. Bajo determinadas condiciones, el intérprete puede intentar utilizar información que no fue inicializada correctamente o acceder a memoria previamente liberada.

Un atacante podría aprovechar estas condiciones mediante solicitudes HTTP especialmente preparadas. Las consecuencias pueden incluir interrupciones del servicio, exposición de información sensible o ejecución de código malicioso.

CVE-2026-109618

Se relaciona con el tratamiento de información interna parcialmente inicializada cuando PHP interrumpe una operación por agotamiento de memoria.

CVE-2026-109619

Involucra referencias a memoria previamente liberada que pueden ser utilizadas nuevamente al procesar otra solicitud.

Esto explica por qué mantener actualizado WordPress no resulta suficiente. Una aplicación puede contar con todos sus plugins al día y continuar expuesta si el servidor utiliza una versión vulnerable de PHP.

Cloudflare desplegó protección antes de la divulgación pública

Uno de los aspectos más destacables de este incidente es la coordinación previa entre distintos actores de la industria para desarrollar medidas de protección.

Según informó Cloudflare, sus equipos comenzaron a preparar mitigaciones durante octubre de 2026 y consiguieron desplegarlas aproximadamente nueve horas antes de la divulgación pública de las vulnerabilidades.

Desde el 21 de octubre de 2026, a las 03:02 UTC, los clientes que utilizan el WAF de Cloudflare, tanto en planes gratuitos como pagados, cuentan por defecto con las protecciones anunciadas.

Esto representa una ventaja importante para organizaciones que necesitan tiempo para probar actualizaciones o coordinar intervenciones sobre sistemas productivos.

¿Cómo funciona la mitigación?

Habitualmente, un firewall de aplicaciones web analiza las solicitudes que recibe un sitio e identifica patrones relacionados con ataques conocidos.

Cuando detecta una solicitud sospechosa, puede bloquearla antes de que llegue al servidor de origen.

Para estas vulnerabilidades, Cloudflare incorporó una capacidad denominada Full Transaction Detection, que permite relacionar las señales presentes en una solicitud HTTP con las de la respuesta generada por el servidor.

1. Análisis de solicitudes

El WAF examina las peticiones entrantes y busca patrones asociados con intentos de explotación. Si detecta una coincidencia, puede bloquear la solicitud.

2. Análisis de respuestas

Cloudflare también puede analizar determinadas señales de la respuesta del servidor y relacionarlas con la solicitud original. Esto permite mejorar la detección y reducir falsos positivos.

Esta segunda capacidad resulta especialmente interesante porque no todos los intentos de explotación pueden identificarse observando únicamente la petición.

Una solicitud podría parecer legítima, mientras que la respuesta generada por el servidor entrega información adicional que permite reconocer un comportamiento potencialmente malicioso.

Cuando se identifica una coincidencia con una regla de alta confianza, Cloudflare puede impedir que la respuesta llegue al solicitante.

Una distinción importante: bloquear una respuesta no revierte necesariamente las acciones que hayan ocurrido previamente en el servidor. La mitigación reduce la exposición, pero no corrige la vulnerabilidad en el motor PHP.

Cómo comprobar la protección en Cloudflare

La implementación depende del plan utilizado, aunque Cloudflare confirmó que las nuevas protecciones se encuentran disponibles incluso para usuarios gratuitos.

Cloudflare Free: protección automática

Para quienes utilizan el plan gratuito, las nuevas reglas fueron incorporadas al Cloudflare Managed Free Ruleset.

Según Cloudflare, estas reglas se desplegaron automáticamente, por lo que no es necesario crear una regla específica para php2shell.

De todas formas, conviene comprobar que el tráfico del sitio pase efectivamente por Cloudflare.

  1. Ingresar al panel de Cloudflare.
  2. Seleccionar el dominio que se desea proteger.
  3. Acceder a DNS → Records y comprobar que los registros correspondientes al sitio tengan habilitado el proxy de Cloudflare, identificado por la nube naranja.
  4. Revisar la sección Security para comprobar las protecciones administradas disponibles.
  5. Consultar Security → Security Analytics → Events para examinar solicitudes detectadas o bloqueadas.

Atención: si un registro utiliza únicamente los servicios DNS de Cloudflare (nube gris), las solicitudes HTTP no pasan por su proxy y, por tanto, no reciben la protección del WAF.

Cloudflare Pro, Business y Enterprise

En los planes pagados, Cloudflare incorporó las protecciones al Cloudflare Managed Ruleset.

La recomendación es comprobar que este conjunto esté desplegado y que las reglas correspondientes utilicen una acción efectiva de bloqueo.

  1. Ingresar al panel de Cloudflare y seleccionar el dominio.
  2. Localizar la sección de WAF Managed Rules dentro de las opciones de seguridad.
  3. Comprobar que Cloudflare Managed Ruleset se encuentre habilitado.
  4. Verificar que las protecciones relevantes estén configuradas para utilizar la acción Block.
  5. Revisar posibles excepciones o reglas de omisión que puedan excluir las rutas vulnerables.

La documentación oficial explica cómo desplegar y administrar los conjuntos de reglas desde el panel de Cloudflare.

Cómo comprobar que las reglas funcionan

Una vez revisada la configuración, Cloudflare permite examinar las detecciones registradas por el WAF.

Para hacerlo, ingresar a Security → Security Analytics → Events y revisar las coincidencias, las acciones ejecutadas y las rutas sobre las cuales se registraron eventos.

Cloudflare también publicó nuevas reglas de análisis de respuestas, incluidas en el conjunto denominado Cloudflare Managed Response Firewall Default, disponible para todos los planes.

Regla de referencia:
Default block for High confidence Signatures

Identificador:
afffe22785674c80a31875c848d2242a

Este identificador puede utilizarse para buscar coincidencias en los eventos de seguridad.

Es importante considerar que la ausencia de eventos de bloqueo no demuestra que la protección esté deshabilitada. Puede que simplemente no se hayan recibido solicitudes coincidentes durante el período consultado.

La mitigación no reemplaza la actualización de PHP

Este es probablemente el aspecto más importante del anuncio.

Cloudflare puede reducir la exposición frente a determinadas técnicas de explotación, pero no elimina los errores que permanecen dentro del motor PHP.

Además, cuando el servidor permite conexiones directas que evitan pasar por Cloudflare, el WAF no puede inspeccionar ni bloquear ese tráfico.

Por ese motivo, el proyecto PHP publicó las siguientes versiones corregidas el 21 de octubre de 2026:

Rama de PHP Versión corregida
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

Estas versiones incorporan las correcciones oficiales de las vulnerabilidades divulgadas.

Quienes administran servidores con CyberPanel, OpenLiteSpeed, Apache, Nginx o entornos Docker deben identificar qué instalación de PHP ejecuta realmente cada aplicación.

Por ejemplo, actualizar PHP en el sistema operativo no actualiza automáticamente las imágenes PHP utilizadas dentro de contenedores Docker.

También corresponde revisar las aplicaciones que todavía dependen de versiones antiguas sin soporte oficial, planificando su migración a ramas compatibles.

Qué deberían revisar las organizaciones

Más allá de instalar los parches, este incidente constituye una oportunidad para revisar cómo se administra la exposición de las aplicaciones publicadas en Internet.

  • Identificar las versiones de PHP en uso. Revisar servidores, hosting, contenedores y aplicaciones heredadas.
  • Aplicar las actualizaciones. Instalar las versiones corregidas y validar previamente su compatibilidad.
  • Mantener habilitado el WAF. Comprobar que las reglas administradas están desplegadas y que las acciones de protección son efectivas.
  • Proteger el servidor de origen. Restringir los accesos directos que permitan evitar Cloudflare.
  • Revisar los eventos de seguridad. Identificar intentos de explotación, posibles falsos positivos y comportamientos anómalos.
  • Planificar la migración de versiones obsoletas. Evitar mantener indefinidamente aplicaciones sobre ramas de PHP que ya finalizaron su soporte.

La importancia de contar con distintas capas de protección

Cada vez que se divulga una vulnerabilidad crítica aparece el mismo desafío: los atacantes pueden comenzar a buscar sistemas vulnerables antes de que todas las organizaciones hayan completado sus actualizaciones.

Ese intervalo forma parte del riesgo que los equipos de seguridad e infraestructura deben administrar.

La respuesta de Cloudflare demuestra el valor de contar con mecanismos capaces de incorporar nuevas detecciones rápidamente, especialmente cuando una actualización requiere pruebas de compatibilidad y ventanas de mantenimiento.

También demuestra que no siempre es necesario contratar una solución de alto costo para disponer de una capa adicional de protección. En esta ocasión, Cloudflare extendió las medidas de mitigación incluso a sus usuarios gratuitos.

Sin embargo, sería un error interpretar esta protección como una autorización para postergar indefinidamente las actualizaciones.

La seguridad no depende de una sola herramienta. Depende de conocer nuestra infraestructura, mantener sus componentes actualizados y contar con controles adicionales que permitan reducir la exposición cuando aparece una nueva amenaza.

El WAF ayuda a proteger. La actualización corrige. Ambas medidas son necesarias.

Fuentes y referencias