La liberar coordinada de PHP para CVE-2026-109618 y CVE-2026-109619 estaba programada para las 14:00 UTC del 21 de octubre. Según la telemetría de nuestro Next-Gen WAF, herramientas que llevaban el nombre de la vulnerabilidad ya realizaban escaneos más de nueve horas antes de eso. Para cuando se liberó, más de 100 direcciones IP de origen habían utilizado herramientas identificadas como PHP2Shell bajo más de dos docenas de nombres. Una de esas herramientas era un kit de explotación que incluía el número de Common Vulnerability and Exposure (CVE) en su Usuario-Agente.

Esta publicación describe cómo fue ese tráfico inicial, cómo distinguir el tráfico real de PHP2Shell del de otras dos campañas similares que están activas al mismo tiempo y qué hacer con las aplicaciones de tu empresa que ejecutan PHP.

Anatomía de los fallos

PHP2Shell es el apodo de dos vulnerabilidades críticas de PHP. Ambas tienen una puntuación CVSS de 9.2 y pueden permitir la ejecución remota de código sin autenticación:

• CVE-2026-109618: Una condición de memoria insuficiente puede interrumpir PHP cuando los datos internos de la solicitud solo se han configurado parcialmente; después, el proceso de limpieza de la solicitud confía en esos datos incompletos.

• CVE-2026-109619: El estado interno puede persistir después de que deje de estar disponible la memoria que lo respalda, y una solicitud posterior en el mismo proceso de trabajo lo retoma.

Para quienes intentan detectar PHP2shell, es importante señalar que no existe ninguna cadena de carga útil con la cual buscar coincidencias. El explotar es una condición: hacer que la solicitud falle justo en el momento equivocado. 

Según PHP, toda instalación que atienda solicitudes web está en riesgo, incluidas las que usan PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Considera que mod_php presenta el mayor riesgo. 

Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y las versiones anteriores no reciben ninguna corrección ascendente.

La cronología

Cómo se desarrolló la divulgación y cuándo aparecieron las herramientas de PHP2shell. Todas las horas están en UTC. Los eventos de divulgación se describen según el análisis posterior de PHP Foundation y los registros de avisos de GitHub.

Los identificadores de las CVE de PHP2shell (2026-109618 & 109619) se filtraron sin detalles técnicos, y aparecieron herramientas denominadas PHP2shell en nuestra telemetría unas ocho horas después del video que mostraba cómo explotarlas. Tanto la primera herramienta identificada por nombre como el primer kit de explotar que detectamos aparecieron antes de liberar anticipadamente las imágenes corregidas. No especularemos sobre qué motivó la aparición de cada herramienta, pero para cuando se realizó el liberar coordinado, el escaneo ya estaba muy avanzado.

El pajar

Desde la primera herramienta cuyo nombre contenía PHP2shell hasta el mediodía del 22 de octubre, almacenamos unas 250 000 solicitudes de herramientas con PHP2shell en el nombre, procedentes de aproximadamente 3200 direcciones IP públicas.

Por supuesto, no todos los escáneres operan con intención de atacar. Alrededor de un tercio de ese tráfico se identifica como defensivo: "verificación autorizada de exposición", "verificación del estado de los parches", "sin explotar". Muchas organizaciones estaban revisando sus propios entornos, y eso es positivo. Esas etiquetas son afirmaciones sin pruebas, pero coinciden con lo que hacen esas solicitudes: pequeñas comprobaciones inofensivas.

Solicitudes de herramientas cuyo nombre contiene PHP2shell, por tipo de herramienta (del 21 de octubre a las 03:59 UTC al mediodía del 22 de octubre, cifras redondeadas). 

El resto fue variado y avanzó rápido. Una herramienta para inventariar versiones de PHP pasó de la versión 4.0 a la 7.2 en unas once horas.

Las herramientas que cambian con tanta rapidez hacen que las firmas basadas en cadenas de Usuario-Agente queden obsoletas en un día.

Las agujas

Hasta ahora, la forma más confiable de distinguir el tráfico de intentos reales de explotación del resto ha sido la cadena delimitadora de las partes del contenido multipart. Cada kit de explotar que encontramos utiliza un delimitador fijo o que sigue un patrón en su encabezado Content-Type. Así identificamos más de diez kits posibles, cinco de ellos vinculados directamente con PHP2shell por su nombre, Usuario-Agente o comportamiento.

El conjunto de herramientas más extendido se ve así:

• POST /index.php (o /), Usuario-Agente php2shell-109618

• Content-Type: multipart/form-data; boundary=B7kQpoc618

• un cuerpo multiparte de tamaño fijo y un conjunto mínimo de encabezados

También se dirige a sus objetivos mediante Dirección IP sin procesar en lugar de nombres de host y envía una o dos solicitudes por host. Eso indica un escaneo masivo del espacio de direcciones IP, no una campaña dirigida contra sitios específicos. 

El tamaño del cuerpo varía mucho de un kit a otro, así que no te bases solo en umbrales de tamaño para identificar este tráfico.

Dos casos similares que hay que descartar primero

Si buscas PHP2shell en tus propios logs, otras dos campañas dificultarán la tarea.

React2Shell (CVE-2025-55182). Dos patrones que circulan como indicadores de PHP2shell son las solicitudes multipart fragmentadas sin Content-Length y los cuerpos rellenados con largas secuencias de la letra A. En la hora que medimos, React2Shell dio cuenta del 98.6 % y el 99.9 % de esas coincidencias, respectivamente. La firma de relleno ya correspondía casi por completo a React2Shell el día anterior a la liberación. React2Shell envía solicitudes a todas las rutas, incluidas /xmlrpc.php y /wp-login.php. La forma más sencilla de distinguirlos es el encabezado de solicitud Next-Action, que usan las acciones de servidor de Next.js, pero que PHP nunca utiliza.

Porcentaje de cada firma "PHP2shell" en circulación que en realidad corresponde a React2Shell, medido a partir del encabezado Next-Action de las solicitudes POST a endpoints de PHP, el 21 de octubre de 21:00 a 22:00 UTC. A la misma hora del día anterior a liberar, la firma de relleno ya correspondía en un 99.7 % a React2Shell.

wp2shell. Se trata de una vulnerabilidad completamente distinta: una vulnerabilidad de ejecución remota de código sin autenticación en el núcleo de WordPress, divulgada en julio de 2026. Su kit envía cuerpos multipart grandes al archivo index.php de WordPress, con un delimitador que comienza con ----wp2shell. Ya estaba activo mucho antes de que PHP2shell se hiciera público, por lo que incluirlo en el recuento crearía una historia inexistente de actividad de php2shell "previa a su divulgación".

Una lección general de ambos casos: una firma basada en la estructura de las solicitudes describe un tipo de solicitud, no a un atacante. Compara con un valor de referencia anterior a la divulgación y desglosa cualquier aumento según un encabezado o delimitador que permita identificarlo antes de atribuirlo.

Qué puedes ver y qué no desde el edge

Los intentos de explotar son visibles en el edge, pero no es posible saber desde allí si tuvieron éxito. PHP2shell funciona provocando una falla o corrupción en un proceso de trabajo de PHP, por lo que un intento exitoso y uno fallido pueden verse iguales desde el exterior. Si crees que fuiste un objetivo, la confirmación está en el servidor de origen:

• Log de errores de PHP-FPM

• Log de errores de Apache que muestran fallas de los procesos de trabajo (por ejemplo, entradas AH00051 "child pid … exit signal")

• Conexiones salientes inesperadas desde los procesos de trabajo de PHP, ya que una shell de conexión inversa genera tráfico saliente desde el servidor de origen

Lo que PHP2Shell dice sobre la IA

Sin duda, la IA ayuda a descubrir vulnerabilidades y lo hace mucho más rápido que antes. En aproximadamente un día desde la aparición de la primera herramienta, observamos decenas de herramientas identificadas por nombre provenientes de unas 3200 direcciones IP, y una de ellas pasó de la versión 4.0 a la 7.2 en aproximadamente once horas. 

No podemos saber con certeza si alguno de ellos se escribió con IA. Lo que sí observamos es que el tráfico en sí es común: los kits envían un cuerpo multipart fijo a direcciones IP sin procesar, una o dos solicitudes por host, desde los mismos tipos de infraestructura de VPN y alojamiento que están detrás de la mayoría de los escaneos. Independientemente del grado de asistencia de la IA, observamos un panorama de amenazas cada vez más amplio y dinámico.

Y, hasta ahora, la defensa sigue siendo principalmente una cuestión de personas. Los equipos de defensa revisaron sus propios sistemas y clasificaron el tráfico. Los cazadores de amenazas compartieron firmas que resultaron corresponder casi por completo a una campaña diferente. Aplicar parches, establecer líneas de base y revisar minuciosamente los log de origen siguen siendo tareas que dependen en gran medida de las personas, incluso con asistencia de IA. Requieren que las personas definan una estrategia para aplicar las defensas por capas adecuadas en los lugares adecuados.

Qué hacer ahora

1. Aplica el parche. Actualiza a la versión 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o al paquete con el parche de tu distribución. Si usas la versión 8.1 o una anterior, consulta con el distribuidor del paquete sobre las correcciones retroportadas o actualiza a una versión más reciente.

2. No persigas pistas falsas. El Usuario-Agente, la Dirección IP y el tamaño de los cuerpos pueden llevarte por mal camino al investigar amenazas. La verdadera pista está en la cadena del delimitador multipart.

3. Descarta React2Shell y wp2shell antes de contabilizar cualquier caso como PHP2shell.

4. Ten cuidado con las listas de bloqueo de direcciones IP. Varias direcciones IP de las listas que circulan sobre esta vulnerabilidad son nodos de salida de VPN o Tor, o direcciones residenciales y móviles que transportan tráfico normal. Bloquearlas perjudica a usuarios reales.

5. Clientes del WAF de siguiente generación de Fastly: para las aplicaciones protegidas por Next-Gen WAF, opten por activar la señal que cubre tanto CVE-2026-109618 como CVE-2026-109619. Es una Templated Rule específica de la CVE que funciona como parche virtual y busca indicios estructurales de explotación.
   Consulta la publicación de Fastly sobre protección proactiva para obtener más detalles.
   

Nota: También recomendamos considerar la opción Automatic Common Vulnerability and Exposure (CVE) Virtual Patching dentro de Workspace Configuración, que se muestra a continuación:

Indicadores

Cómo lo medimos

Estas cifras provienen de la telemetría de solicitudes del WAF de siguiente generación de Fastly entre el 20 y el 22 de octubre de 2026. La cronología de la divulgación se basa en el análisis posterior al incidente de la PHP Foundation y en los registros de avisos de GitHub. Los conteos representan límites inferiores: solo podemos informar sobre las solicitudes que nuestro WAF detectó y registró, y algunas cifras relativas a los encabezados provienen de horas de muestreo con coincidencias, en lugar de días completos.

Lee 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 para obtener información más actualizada.