Protección proactiva de Fastly para PHP2Shell, Critical PHP RCE CVE-2026-109618 y CVE-2026-109619

PHP —el tiempo de ejecución que sustenta la mayoría de los sistemas de gestión de contenidos, las plataformas de comercio electrónico y la infraestructura de publicación de la web— sigue arrastrando los fantasmas de décadas pasadas: una decisión de diseño que dio lugar a un fallo en la forma en que su motor gestiona los errores fatales. Las vulnerabilidades divulgadas hoy, denominadas php2shell, tienen su origen en esta decisión de diseño, que analizaremos en el artículo.

La PHP Foundation asignó dos identificadores CVE (CVE-2026-109618 y CVE-2026-109619) y se han publicado parches para PHP 8.2 y versiones posteriores (las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35). PHP también publicó parches para las versiones 7.4, 8.0 y 8.1, para su integración por parte de los distribuidores de paquetes. Las versiones anteriores a la 7.4 no recibirán parches de PHP; quedará a criterio de los distribuidores de paquetes aplicarles parches. Todas las versiones de PHP que siguen recibiendo mantenimiento están afectadas. Por ahora, la ruta demostrada más antigua para aprovechar se remonta a 2012. 

Hay pruebas de ataques activos en entornos reales anteriores a su divulgación; no se trata de problemas teóricos.

Recomendamos encarecidamente a los clientes que busquen en su entorno servidores de aplicaciones con mod_php o php-fpm y les apliquen los parches con urgencia. Si no encuentras ninguna forma de aplicar un parche, recomendamos la mitigación activa. 

Por ahora, dada la naturaleza de estos métodos de aprovechar (incluida la RCE previa a la autenticación), debes asumir que la mitigación activa solo ofrecerá protección partial y que, según el enfoque empleado, podría ser necesario bloquear una parte considerable del tráfico legítimo.

Agradecemos la estrecha colaboración con OpenAI y con otros partners del ecosistema de software que contribuyeron a este esfuerzo urgente para proteger al mayor número posible de organizaciones. 

En este artículo, explicaremos las vulnerabilidades con más detalle, describiremos cómo podrían afectar a tu negocio estas formas de aprovechar vulnerabilidades de PHP y ofreceremos orientación para mitigar los intentos de explotación.

Lo esencial sobre CVE-2026-109618 & CVE-2026-109619

Cuando PHP alcanza un límite de memoria, agota el tiempo máximo de ejecución o pierde una conexión, no interrumpe la ejecución de forma ordenada. Abandona a mitad de la operación lo que estuviera haciendo y salta a un punto de recuperación, dejando un estado interno parcialmente modificado. Ese estado residual puede apuntar a memoria que ya se ha liberado o contener estructuras de datos que nunca terminaron de crear.

Los investigadores han demostrado que un atacante puede provocar estas condiciones de error con una sola petición HTTP no autenticada. El atacante puede lograrlo sin necesidad de inicio de sesión, de un punto de conexión especial ni de la colaboración de la aplicación. La RCE permite al atacante ejercer control con suficiente precisión sobre qué queda en el estado residual para lograr que PHP ejecute comandos arbitrarios de shell con la identidad de un usuario del sistema operativo del servidor web aparentemente legítimo. El proceso de trabajo sobrevive y sigue atendiendo peticiones después, sin percatarse de que tiene un nuevo jefe.

La única entrada del registro es un error habitual de falta de memoria. Va a ser toda una aventura, por decirlo suavemente.

No se puede exagerar el posible impacto:

• Alcance: cualquier organización con aplicaciones PHP

• Profundidad: el atacante puede hacer lo que quiera en la aplicación

Como es posible que utilices una configuración de PHP y tengas mod_php o php-fpm sin saberlo, recomendamos encarecidamente a los clientes que consideren cualquier aplicación PHP potencialmente vulnerable y escaneen su entorno en consecuencia.

Hay un factor que limita el riesgo: para que un ataque permita ejecutar código en x86_64, las POC existentes requieren conocer el binario concreto de PHP que se está ejecutando y la disposición del espacio de direcciones del servidor. Por eso, la mayoría de los despliegues podrían estar «a salvo» de RCE. No des por hecho que este sea tu caso. Si gestionas una aplicación PHP de 32 bits, probablemente deberías partir de la premisa de que ha sido comprometida. 

Análisis en profundidad: el problema de diseño a nivel del motor

El motor de PHP gestiona los errores fatales de una forma peculiar. Si algo sale realmente mal, las funciones que estaban realizando alguna tarea no reciben ninguna notificación ni tienen ocasión de limpiar lo que han dejado a medias. Su trabajo a medio hacer permanece exactamente como lo dejaron. Más concretamente, el motor emplea un mecanismo llamado longjmp(), que traslada la ejecución directamente a un punto de captura (como si agarrara la aplicación por el pescuezo, por así decirlo), en lugar de creación de registros un error y salir inmediatamente de escena.

El motor de PHP invoca este mecanismo —denominado zend_bailout — desde todas las rutas de código que aplican un límite de recursos o gestionan una condición fatal (que son muchas). Cuando la aplicación sufre un agotamiento de memoria, se agota el tiempo máximo de ejecución, se interrumpe una conexión de cliente o se produce un error fatal no capturado, todas estas situaciones se gestionan mediante zend_bailout.

Este enfoque ingenioso sería manejable si se diera rara vez o en circunstancias controladas. Como bien sabe cualquiera que haya vivido los «placeres» del desarrollo en PHP, estos errores fatales se producen habitualmente en los despliegues de PHP en producción y, lo que es más importante, estas condiciones atraen a los atacantes que querrían hacerse con el control de toda la web (es decir, todos los servidores de aplicaciones que ejecutan PHP actualmente).

¿Qué lleva a la explotación?

Cuando se activa zend_bailout, cualquier operación interna de PHP que esté modificando una estructura de datos quedará interrumpida y dejará esa estructura de datos en un estado incoherente, lo que incumple las expectativas de la operación. El código de limpieza de PHP que se ejecuta después de cada petición para eliminar el estado de la petición se encuentra entonces con esos datos incoherentes y actúa sobre ellos como si fueran válidos.

Los POCs publicados deben considerarse ejemplos ilustrativos y están lejos de enumerar toda la variedad de rutas de abandono y salida anticipada que pueden desencadenar condiciones similares que los atacantes pueden aprovechar. Para recalcar por qué esto supone un problema para Internet: el árbol de código fuente de PHP recurre al mecanismo zend_bailout en muchos puntos; cada uno puede interrumpir un conjunto distinto de operaciones en curso y tiene sus propias invariantes cuando se produce la interrupción.

El número de combinaciones posibles es, por decirlo suavemente, explosivo. Aplicar parches a las rutas concretas que demostraron los investigadores no hace que el mecanismo sea seguro. Dado el retorno de la inversión que ofrece esta vulnerabilidad, los atacantes estarán muy motivados para encontrar la próxima ruta aún no descubierta y continuar aprovechándola.

Es de esperar que tanto las organizaciones ciberdelictivas como los Estados aprovechen esto; esta capacidad básica es potente cuando se combina con una filtración de información... y ni siquiera tiene que ser una filtración especialmente sofisticada. El fallo de filtración de información puede bloquear el proceso y seguir considerándose válido gracias al diseño prefork de mod_php. «Cómo entrar en pánico de forma segura» es un tema para otro momento.

¿Por qué es tan elevado el impacto?

Esto es lo que un atacante podría conseguir si lograra ejecutar código de forma remota en un servidor PHP:

• Dejar fuera de servicio sitios web y aplicaciones basados en PHP con una sola petición sin autenticar; a escala, esto se traduce en una interrupción continuada del servicio (suponiendo que el contenido no esté almacenado en caché)

• Ejecuta cualquier comando en el servidor sin provocar ninguna interrupción visible; el servidor acepta sin reparos las entradas de los atacantes

• Roba todas las credenciales que utiliza la aplicación: contraseñas de bases de datos, claves de API, claves de proveedores de servicios en la nube y claves de cifrado

• Acceder a las bases de datos, los sistemas para almacenar en caché, las colas de mensajes y los sistemas internos protegidos por esas credenciales: registros de clientes, transacciones, información de carácter personal (PII) y cualquier otro sistema con el que se comunique la aplicación; esto puede dar lugar a obligaciones de notificación de violaciones de la seguridad y a otras obligaciones normativas

• Adéntrate más en la red: recorre la infraestructura en la nube, los tokens de las cuentas de servicio de Kubernetes, Envoy, las claves SSH almacenadas en disco y los servicios internos, dado que el servidor web ya está dentro de tu entorno de confianza

• Establece un acceso persistente que sobreviva a los reinicios del servidor y a los nuevos despliegues (el equivalente, para el atacante, a una cómoda tumbona de playa, en forma de puertas traseras en archivos PHP o procesos de cron ocultos)

• Sin indicios evidentes: la única entrada en el registro es un error de memoria habitual que los equipos de Operaciones ven con frecuencia y rara vez investigan (salvo que haya algún SRE excepcionalmente curioso).

La cadena de consecuencias puede ser grave en diversos casos de uso. Pensemos en un escaparate típico: una petición HTTP → servidor comprometido → instalación de un programa persistente que roba datos de tarjetas → robo masivo y continuado de datos de tarjetas de todos los clientes → violación de la seguridad de las Normas de seguridad de datos para el sector de tarjetas de pago (PCI DSS) → posible pérdida de la capacidad de procesar pagos con tarjeta.

Cómo determinar si existe exposición

Recomendamos a nuestros clientes que consideren potencialmente vulnerable cualquier aplicación PHP y auditen sus entornos de producción en consecuencia. Este no es el momento de escatimar esfuerzos al investigar la vulnerabilidad; empieza ya a hacer el inventario. Para determinar con mayor precisión si estás expuesto, comprueba lo siguiente:

• PHP con Apache y mod_php en modo prefork

• Una relación entre memory_limit / post_max_size que permita a un atacante provocar una situación de OOM mediante el cuerpo de una petición POST

• Las variantes de denegación de servicio (DoS) (que provocan fallos sin ejecutar código) afectan a un conjunto más amplio de configuraciones, incluido php-fpm

Entre los sectores que creemos que pueden ser especialmente vulnerables a estos ataques se encuentran:

• Comercio electrónico (plataformas de comercio online) | post_max_size suele ser superior al valor predeterminado para permitir la carga de archivos

• Medios & publicaciones (sistemas de gestión de contenidos) | gran número de instancias estándar de mod_php en Apache con configuraciones predeterminadas (o casi predeterminadas)

• Educación (plataformas de aprendizaje, portales personalizados para estudiantes, herramientas para el profesorado) | La presencia de PHP en la educación superior es considerable y, a menudo, la gestionan equipos reducidos

• Hostelería y viajes (motores de reservas, plataformas de fidelización, sistemas de gestión de establecimientos) | Las aplicaciones PHP personalizadas sobre pilas LAMP suelen tener límites de subida generosos para fotos y documentos

• Servicios financieros (integraciones de pago, portales de solicitud de préstamos, reclamaciones de seguros) | valor elevado de post_max_size debido a los numerosos flujos de trabajo con gran cantidad de documentos; PHP es el COBOL de las aplicaciones orientadas al cliente

• Saas (herramientas internas de administración, paneles de atención al cliente, marcos de desarrollo web) | a menudo menos supervisados y gestionados por equipos reducidos de empresas SMB

• Proveedores de alojamiento gestionado y alojamiento compartido (paneles de control de alojamiento web, entornos Apache multiinquilino) | impacto multiplicador si una configuración vulnerable de PHP afecta a un servidor compartido

• Sanidad (portales para pacientes, sistemas de programación de citas, integraciones de datos sanitarios) | La subida de archivos sensibles, como resultados de análisis, formularios de derivación y tarjetas del seguro, requiere un valor de post_max_size más elevado

Cómo obtener protección activa ahora

Para reducir el riesgo de las aplicaciones protegidas por NGWAF, los clientes de Fastly pueden activar la señal que cubre tanto CVE-2026-109618 como CVE-2026-109619. La lógica de detección de esta regla con plantilla específica para estas CVE busca los rasgos estructurales característicos de estos intentos de explotación —cuerpos y parámetros cuya estructura difiere de la del tráfico legítimo— que pueden indicar posibles intentos de aprovechar las CVE de php2shell.

El equipo de investigación de seguridad de Fastly desarrolló y probó este contenido en estrecha colaboración con OpenAI y socios de la comunidad; agradecemos esta colaboración. Nuestro equipo de investigación de seguridad actualizará el parche virtual según sea necesario; quienes hayan optado por activarlo recibirán automáticamente las actualizaciones posteriores. 

Fastly seguirá investigando otros niveles de defensa que podamos ofrecer a nuestros clientes para detectar y bloquear el tráfico de ataques relacionados con php2shell. Seguiremos desarrollando y perfeccionando el contenido NGWAF pertinente a medida que observemos intentos de explotación.

Señales e indicios que se recomienda investigar

Para mitigar el error más sencillo relacionado con el progreso de carga, asegúrate de establecer session.upload_progress.enabled = Off en php.ini. 

En el caso de la vulnerabilidad zend_bailout, que es más grave, los principales patrones observados hasta la fecha en el tráfico de aprovechar y de pruebas de concepto son:

Reduce la superficie de ataque mediante la configuración de PHP

• post_max_size = 8M —mantiene los cuerpos de las peticiones POST por debajo del umbral necesario para provocar un agotamiento de memoria con una sola petición. Haz pruebas con cualquier flujo de trabajo que acepte cargas de archivos o envíos de formularios de gran tamaño; 8M es el valor predeterminado de PHP, pero se ha aumentado en muchos despliegues de producción.

• max_input_nesting_level = 4 — limita la profundidad de anidamiento de los nombres de variables, que se utilizan en la carga útil diseñada para aprovechar la vulnerabilidad de la tabla hash. Aumenta el valor a 6 si la aplicación utiliza estructuras de formularios anidados complejas. Prueba el envío de formularios que utilicen nombres de campo con formato de matriz.

• session.upload_progress.enabled = 0 — desactiva la función de seguimiento del progreso de carga que activa las rutas para aprovechar relacionadas con las sesiones. Solo afecta a las aplicaciones que muestran barras de progreso de carga en tiempo real mediante el mecanismo de sesiones integrado de PHP. La mayoría de las aplicaciones que muestran el progreso de carga utilizan, en cambio, soluciones basadas en JavaScript.

En el tráfico HTTP (WAF, proxy o inspección de red)

• Envíos de formularios de tamaño excesivo. Cuerpos de peticiones POST de más de 1-2 MB que usan application/x-www-form-urlencoded. Los envíos de formularios legítimos casi siempre ocupan menos de 100 KB. Los formularios codificados para URL que ocupan varios megabytes son lo bastante inusuales como para justificar una investigación en cualquier punto de conexión que utilice PHP.

• Nombres de campo vacíos con un anidamiento profundo. Cuerpos de peticiones POST que comienzan por = (un campo sin nombre), seguido de un nombre de campo que contiene varios caracteres de corchete de apertura [ repetidos. Esta es la estructura específica de la carga útil utilizada para aprovechar la tabla hash.

• Nombres de campos de seguimiento del progreso de las cargas. Cargas de archivos multipart que contienen un campo denominado PHP_SESSION_UPLOAD_PROGRESS. Se trata de una función legítima de PHP, pero también es el desencadenante de las rutas para aprovechar relacionadas con las sesiones. Márcalo para su revisión en los puntos de conexión que no utilizan el seguimiento del progreso de las cargas.

En los registros de errores de la aplicación y del servidor web

• Errores OOM procedentes de los componentes internos de PHP, no del código de la aplicación. Busca «Allowed memory size ... exhausted» con la ubicación «Unknown» en la línea 0. El archivo «Unknown» y la línea 0 indican que el error se produjo durante el análisis de la petición realizado por el propio PHP, antes de que se ejecutara cualquier script de la aplicación. Un error OOM procedente del código de la aplicación indicaría un archivo real y un número de línea.

• Ráfagas de fallos de segmentación. Clústeres de entradas «Apache AH00052 ... exit signal Segmentation fault (11)» en un breve intervalo. Unos pocos fallos de segmentación aislados no son inusuales; decenas de ellos en cuestión de minutos, seguidos de una única respuesta HTTP 200 lenta, coinciden con la fase de fuerza bruta para recuperar direcciones del aprovechar.

Monitorización dentro del proceso (a nivel de host)

• Procesos de trabajo de Apache/PHP que inician procesos de shell. Cualquier proceso de trabajo de mod_php que ejecute /bin/sh -c ... como proceso secundario. En operación normal, los procesos de trabajo de mod_php nunca inician procesos secundarios, a menos que la aplicación PHP llame explícitamente a una función de ejecución de comandos (exec, system, shell_exec, etc.). Si no se ha ejecutado código de la aplicación (con aprovechar conocidos actualmente, no se ejecuta), considera que un shell iniciado por un proceso de trabajo de PHP indica que se ha activado la carga útil de ejecución de código.

Para despliegues de PHP-FPM

• pm.max_requests = 50 — obliga al reinicio de los procesos de trabajo después de 50 peticiones, lo que impone un límite al periodo durante el cual se puede aprovechar la corrupción entre peticiones (los errores de sesión y de conversión de datos). No evita el fallo de la tabla hash, que aprovecha la corrupción de datos dentro de una única petición. Un valor de 1 impediría por completo los ataques entre peticiones, pero a costa de una grave pérdida de rendimiento.

Qué nos deparará el futuro

Sabemos que nuestros clientes nos confían la resiliencia de sus servicios vitales para el negocio, y un aspecto fundamental de la misión de nuestra empresa es estar ahí para ayudarles cuando surgen imprevistos como CVE-2026-109618 y CVE-2026-109619. Nuestros equipos están a tu disposición mientras sigues con la mitigación de php2shell, tanto si llevas tiempo siendo cliente de la plataforma de Fastly como si acabas de llegar y necesitas protección inmediata. Dinos cómo podemos ayudarte.

En resumen:

• El mecanismo utilizado con fines maliciosos — zend_bailout, que llama a longjmp() para abandonar las operaciones en curso— está presente en toda la base de código y es accesible mediante tráfico HTTP normal. 

• Aplica los parches cuanto antes y ten en cuenta que solo reflejan los errores descubiertos y aprovechados hasta la fecha. 

• Es de esperar que aparezcan ataques en entornos reales y nuevas variantes, como mínimo, durante esta semana y la próxima. 

• La condición arquitectónica que hizo que fueran posibles es una propiedad fundamental del diseño de gestión de errores del motor, no un «defecto» localizado del código, y seguirá existiendo después de que se publiquen estos parches.

Agradecemos poder aportar nuestro granito de arena a este esfuerzo colectivo para proteger internet en su conjunto. Nos comprometemos a seguir colaborando a medida que se desarrollen los ataques; queremos que nuestros clientes y el ecosistema del software en general puedan actuar con rapidez y mantenerse seguros. 

Con el fin de mantener la resiliencia de Internet y la colaboración del ecosistema, Fastly supervisará de forma proactiva nuestra red global en busca de intentos de explotación de php2shell y ofrecerá actualizaciones posteriores de la actividad que observemos, de forma similar a la información que publicamos durante los incidentes de React2Shell y Log4Shell. Si necesitas ayuda, no dudes en ponerte en contacto con nosotros. Pronto habrá más novedades.