Protección proactiva de Fastly para PHP2Shell, vulnerabilidad crítica de ejecución remota de código (RCE) en PHP CVE-2026-109618 y CVE-2026-109619

PHP, el entorno de tiempo de ejecución detrás de la mayoría de los sistemas de gestión de contenido, las plataformas de e-commerce y la infraestructura de publicación de la web, sigue perseguido por fantasmas del pasado: una decisión de diseño que provocó un defecto en la forma en que su motor maneja los errores fatales. Las vulnerabilidades divulgadas hoy, denominadas php2shell, tienen su origen en esa decisión de diseño, que analizaremos en esta publicación.

La PHP Foundation asignó dos identificadores CVE (CVE-2026-109618 y CVE-2026-109619), y las vulnerabilidades están corregidas en 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 7.4, 8.0 y 8.1 para la integración por parte de los distribuidores de paquetes. Las versiones anteriores a 7.4 no recibirán un parche de PHP; los distribuidores de paquetes decidirán si las corrigen. Todas las versiones de PHP que reciben mantenimiento están afectadas. Hasta ahora, la ruta de explotación demostrada más antigua está presente desde 2012. 

Hay evidencia de ataques activos en entornos reales antes de la divulgación; no se trata de problemas teóricos.

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

Por ahora, dada la naturaleza de estas técnicas de explotar (incluida la RCE previa a la autenticación), debes asumir que la mitigación activa solo ofrecerá una protección partial y que, según el enfoque, podría requerir bloquear una parte considerable del tráfico legítimo.

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

En esta publicación, explicaremos las vulnerabilidades con más detalle, describiremos cómo la explotación de estas vulnerabilidades de PHP podría afectar a tu empresa y ofreceremos recomendaciones para mitigar los intentos de explotación.

CVE-2026-109618 & CVE-2026-109619 en pocas palabras

Cuando PHP alcanza un límite de memoria, se agota el tiempo de ejecución o se interrumpe una conexión, no deshace las operaciones de forma ordenada. Abandona a mitad de la operación lo que estuviera haciendo y salta a un punto de recuperación, lo que deja su estado interno parcialmente modificado. Ese estado residual puede apuntar a memoria que ya se liberó o contener estructuras de datos que nunca se terminaron de construir.

Los investigadores han demostrado que un atacante puede provocar estas condiciones de error con una sola solicitud HTTP no autenticada. El atacante puede lograrlo sin inicio de sesión, sin un endpoint especial y sin que la aplicación coopere. La vulnerabilidad de ejecución remota de código (RCE) permite al atacante controlar con suficiente precisión lo que queda en el estado residual para hacer que PHP ejecute comandos arbitrarios del shell como el usuario supuestamente legítimo del sistema operativo del servidor web. El proceso de trabajo sobrevive y sigue atendiendo solicitudes, sin saber que ahora está bajo el control de un nuevo amo.

La única entrada en el log es un error rutinario por falta de memoria. Será una experiencia intensa, por decir lo menos.

Es imposible exagerar el impacto potencial:

• Alcance: cualquier organización con aplicaciones PHP

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

Como es posible que tengas una configuración de PHP que incluya mod_php o php-fpm sin que lo sepas, recomendamos enfáticamente a los clientes que consideren potencialmente vulnerable cualquier aplicación PHP y analicen su entorno en consecuencia.

Hay un aspecto favorable: para que un ataque logre ejecutar código en x86_64, los POC existentes requieren conocer el binario de PHP específico que se está ejecutando y la disposición del espacio de direcciones en el servidor, por lo que la mayoría de los despliegues podrían estar “a salvo” de la RCE. No asumas que este es tu caso. Si operas una aplicación PHP de 32 bits, probablemente debas asumir que ha sido comprometida. 

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

El motor de PHP maneja los errores fatales de una manera peculiar. Si algo sale muy mal, las funciones que estaban realizando alguna tarea no reciben ninguna notificación ni tienen oportunidad de limpiar lo que dejaron pendiente. El trabajo que dejaron a medias permanece exactamente como lo dejaron. En concreto, el motor emplea un mecanismo llamado longjmp(), que traslada la ejecución directamente a un punto de captura (por así decirlo, toma la aplicación por el cuello) en lugar de logging un error y salir de inmediato.

El motor de PHP invoca este mecanismo, llamado zend_bailout, desde todas las rutas de código que aplican un límite de recursos o manejan una condición fatal (y son muchas). Cuando la aplicación se queda sin memoria, se agota el tiempo de ejecución, se interrumpen las conexiones de los clientes o se producen errores fatales no capturados, en todos esos casos se aplica zend_bailout.

Este enfoque creativo sería manejable si ocurriera rara vez o en circunstancias controladas. Como bien sabe cualquiera que haya vivido las alegrías de desarrollar con PHP, estos errores fatales ocurren habitualmente en los despliegues de PHP en producción y, más importante aún, estas condiciones resultan atractivas para los atacantes que quisieran tener el control total de la web (es decir, todos los servidores de aplicaciones que ejecutan PHP actualmente).

¿Qué da lugar a la explotación?

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

Los POC publicados deben considerarse ejemplos ilustrativos: están lejos de enumerar todas las rutas posibles de abandono y salida anticipada que pueden desencadenar condiciones similares que los atacantes pueden explotar. Para reforzar por qué esto supone un problema para internet: el código fuente de PHP llama al mecanismo zend_bailout en muchos lugares; cada llamada puede interrumpir un conjunto distinto de operaciones en curso, y cada una tiene sus propias condiciones que deben mantenerse al producirse la interrupción.

La cantidad de combinaciones posibles es, por decirlo suavemente, enorme. Corregir las rutas específicas que demostraron los investigadores no hace que el mecanismo sea seguro. Dado el retorno de la inversión que ofrece esta vulnerabilidad, los atacantes tendrán grandes incentivos para encontrar la próxima ruta aún no descubierta y continuar con sus ataques.

Da por hecho que tanto las organizaciones ciberdelincuentes como los Estados aprovecharán esto; esta técnica 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 que filtra información puede hacer que el proceso se bloquee y aun así considerarse válido gracias al diseño prefork de mod_php. “Cómo entrar en pánico de forma segura” es un tema para otra ocasión.

¿Por qué es tan alto el impacto?

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

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

• Ejecutar cualquier comando en el servidor sin causar ninguna interrupción visible; el servidor acepta sin problemas las instrucciones de los atacantes

• Robar todas las credenciales que usa la aplicación: contraseñas de bases de datos, claves de API, claves del proveedor de servicios en la nube y claves de cifrado

• Acceder a las bases de datos, los sistemas de caché, las colas de mensajes y los sistemas internos protegidos por esas credenciales: registros de clientes, transacciones, información de identificación personal y cualquier otro recurso con el que se comunique la aplicación; esto puede generar obligaciones de notificación de filtraciones y otras obligaciones normativas

• Adéntrate más en la red: recorre la infraestructura en la nube, los token 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

• Establecer un acceso persistente que sobreviva a reiniciar el servidor y los nuevos despliegues (el equivalente a una cómoda silla de playa para el atacante, en forma de puertas traseras en archivos PHP o cron jobs ocultos)

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

La cadena de consecuencias puede ser grave en diversos casos de uso. Consideremos un escaparate típico: una solicitud HTTP → servidor comprometido → instalación de un skimmer persistente → robo masivo y continuo de datos de tarjetas de toda la cliente → filtración de Payment Card Industry Data Security Standard → posible pérdida de la capacidad de procesar pagos con tarjeta.

Cómo determinar la exposición

Recomendamos a los clientes que consideren cualquier aplicación PHP potencialmente vulnerable y auditen su entorno de producción en consecuencia. Este no es el momento de tomar atajos al investigar las vulnerabilidades; comienza el inventario ahora. Para determinar con mayor precisión si existe exposición, comprueba los siguientes criterios:

• PHP con mod_php de Apache en modo prefork

• Una relación entre memory_limit y post_max_size que permite a un atacante provocar una condición de memoria agotada (OOM) mediante el cuerpo de una solicitud POST

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

Entre los sectores que creemos que podrían ser especialmente vulnerables a estos ataques se encuentran:

• E-commerce (plataformas de comercio en línea) | post_max_size suele tener un valor superior al predeterminado para permitir la carga de archivos

• Medios de comunicación y publicaciones (sistemas de gestión de contenido) | enorme superficie de instancias estándar de Apache con mod_php y configuraciones predeterminadas (o casi predeterminadas)

• Educación (plataformas de aprendizaje, portales personalizados para estudiantes, herramientas para docentes) | PHP tiene una presencia considerable en la educación superior, donde suele estar a cargo de equipos pequeños

• Hotelería & viajes (motores de reservas, plataformas de fidelización, sistemas de gestión de propiedades) | Las aplicaciones PHP personalizadas en entornos LAMP suelen tener límites de carga amplios para fotos y documentos

• Financial Services (integraciones de pagos, portales de solicitud de préstamos, reclamaciones de seguros) | post_max_size elevado debido a los numerosos flujos de trabajo con gran cantidad de documentos; PHP es el COBOL de las aplicaciones orientadas a clientes

• Software como servicio (herramientas internas de administración, tableros de atención al cliente, marcos de desarrollo web) | a menudo tienen menos monitor y están a cargo de equipos reducidos de pymes

• Proveedores de hosting administrado y compartido (paneles de control de hosting web, entornos Apache multiinquilino) | el impacto se multiplica si una configuración vulnerable de PHP afecta a un servidor compartido

• Sector salud (portales de pacientes, sistemas de programación de citas, integraciones de datos de salud) | la carga de documentos sensibles, como resultados de laboratorio, formularios de derivación y tarjetas de seguro, requiere un valor mayor de post_max_size

Cómo obtener protección activa ahora

Para mitigar 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. El contenido de detección de esta regla basada en plantilla específica para las CVE busca los rasgos estructurales característicos de estos intentos de explotación —cuerpos y parámetros con estructuras distintas a las del tráfico legítimo— que pueden indicar posibles intentos de explotar 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 recibirlo recibirán automáticamente las actualizaciones posteriores. 

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

Señales e indicios recomendados para 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 más grave de zend_bailout, los patrones clave observados hasta la fecha en el tráfico de explotar y de prueba de concepto incluyen:

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

• post_max_size = 8M — mantiene los cuerpos de las solicitudes POST por debajo del umbral necesario para provocar una condición de memoria agotada con una sola solicitud. Pruébalo con cualquier flujo de trabajo que acepte cargas de archivos o el envío de formularios grandes; 8M es el valor predeterminado de PHP, pero muchos despliegues de producción lo han aumentado.

• max_input_nesting_level = 4: es un límite para los nombres de variables con anidamiento profundo, que se utilizan en la carga útil para explotar tablas hash. Aumenta el valor a 6 si la aplicación utiliza estructuras complejas de formularios anidados. Prueba los envíos de formularios que utilizan nombres de campo con sintaxis de arreglos.

• session.upload_progress.enabled = 0 — desactiva la función de seguimiento del progreso de carga que activa las rutas para explotar 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, métodos basados en JavaScript.

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

• Envíos de formularios demasiado grandes. Cuerpos de solicitudes POST que usan application/x-www-form-urlencoded y superan los 1–2 MB. Los envíos de formularios legítimos casi siempre son inferiores a 100 KB. Los formularios codificados para URL de varios megabytes son lo bastante inusuales como para justificar una investigación en cualquier endpoint que atienda solicitudes mediante PHP.

• Nombres de campo vacíos con anidamiento profundo. Cuerpos de solicitudes POST que comienzan con = (un campo sin nombre), seguidos de un nombre de campo que contiene caracteres de corchete de apertura [ repetidos. Esta es la estructura específica de la carga útil del explotar de la tabla hash.

• Nombres de campos de seguimiento del progreso de carga. Cargas de archivos multipartes que contienen un campo llamado PHP_SESSION_UPLOAD_PROGRESS. Esta es una función legítima de PHP, pero también activa las rutas de explotar relacionadas con las sesiones. Márcalo para revisión en los endpoints que no usan el seguimiento del progreso de carga.

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

• Errores de falta de memoria (OOM) en componentes internos de PHP, no en el código de la aplicación. Busca Allowed memory size ... exhausted con la ubicación indicada como Unknown on line 0. El archivo Unknown y la línea 0 significan que el error se produjo durante el análisis de la solicitud por parte de PHP, antes de que se ejecutara cualquier script de la aplicación. Un error de falta de memoria en el 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. Grupos de entradas Apache AH00052 ... exit signal Segmentation fault (11) en un periodo breve. Unos cuantos fallos de segmentación aislados no son inusuales; decenas en cuestión de minutos, seguidos de una única respuesta HTTP 200 lenta, corresponden a la fase de fuerza bruta para recuperar direcciones del explotar.

En el monitoreo de procesos (a nivel del host)

• Procesos de trabajo de Apache/PHP que generan 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 generan 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 ejecutó código de la aplicación (con los explotar conocidos actualmente, no se ejecuta), considera que una shell generada por un proceso de trabajo de PHP indica que se activó la carga útil de ejecución de código.

Para despliegues de PHP-FPM

• pm.max_requests = 50 — obliga a reiniciar los procesos de trabajo después de 50 solicitudes, lo que establece un límite al periodo durante el cual se puede explotar la corrupción entre solicitudes (los errores de sesión y de conversión de datos). No impide el error de la tabla hash, que explota la corrupción dentro de una sola solicitud. Un valor de 1 impediría por completo los ataques entre solicitudes, pero con un costo considerable para el rendimiento.

¿Qué sigue?

Sabemos que nuestros clientes nos confían la resiliencia de sus servicios críticos para el negocio. Una parte fundamental de la misión de nuestra empresa es respaldarlos cuando surgen imprevistos como CVE-2026-109618 y CVE-2026-109619. Nuestros equipos están aquí para ayudarte mientras continúas con la mitigación de php2shell, tanto si eres cliente de la plataforma Fastly desde hace tiempo como si acabas de llegar y necesitas protección inmediata. Dinos cómo podemos ayudarte.

En resumen:

• El mecanismo utilizado para los ataques — zend_bailout llama a longjmp() para abandonar operaciones en curso— está presente en todo el código base y puede activarse mediante tráfico HTTP común. 

• Aplica los parches cuanto antes y ten en cuenta que solo contemplan los errores detectados y explotados hasta la fecha. 

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

• La condición arquitectónica que las hizo posibles es una propiedad fundamental del diseño de manejo de errores del motor, no un “defecto” localizado en el código, y persistirá después de que se publiquen estos parches.

Agradecemos poder contribuir 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 de software en general actúen con rapidez y se mantengan seguros. 

Con el objetivo de contribuir a la resiliencia de internet en su conjunto y a la colaboración del ecosistema, Fastly monitoreará de forma proactiva nuestra red global para detectar intentos de explotar php2shell y ofrecerá actualizaciones posteriores sobre la actividad que observemos, similares a las observaciones que publicamos durante los incidentes de React2Shell y Log4Shell. Si necesitas ayuda, no dudes en contactarnos. Mantente al tanto.