El lanzamiento coordinado de PHP para CVE-2026-109618 y CVE-2026-109619 estaba previsto para las 14:00 UTC del 21 de octubre. Según la telemetría de nuestro WAF de última generación, las herramientas cuyos nombres hacían referencia al fallo ya estaban realizando análisis más de nueve horas antes. Para cuando se produjo el lanzamiento, más de 100 direcciones IP de origen ya habían utilizado herramientas identificadas como PHP2Shell bajo más de dos docenas de nombres distintos. Una de esas herramientas era un kit para aprovechar vulnerabilidades que incluía el número de Vulnerabilidad y exposición comunes en su User-Agent.

Este artículo analiza cómo era ese tráfico inicial, cómo distinguir el tráfico real de PHP2Shell del de dos campañas similares que están activas al mismo tiempo y qué hacer con las aplicaciones de tu empresa que utilizan PHP.

Anatomía de los errores

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 falta de memoria puede interrumpir PHP cuando los datos internos de la petición solo se han inicializado parcialmente. Después, el proceso de limpieza de la petición da por válidos esos datos incompletos.

• CVE-2026-109619: El estado interno puede persistir más allá de la memoria que lo sustenta, y una petición posterior en el mismo proceso de trabajo lo recupera.

Para detectar PHP2shell, es importante tener en cuenta que no hay ninguna cadena en la carga útil que se pueda buscar. La explotación depende de una condición: provocar que la petición falle justo en el peor momento. 

PHP indica que todas las instalaciones que atienden peticiones web están en riesgo, incluidas PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Considera que mod_php presenta el mayor riesgo. 

Los lanzamientos corregidos 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.

Cronología

Cómo se desarrolló la divulgación y cuándo aparecieron las herramientas de PHP2shell. Todas las horas se indican en UTC. Los acontecimientos relacionados con la divulgación se describen tal como aparecen en el análisis posterior de PHP Foundation y en los registros de avisos de GitHub.

Los identificadores de las CVE de PHP2shell (2026-109618 & 109619) se filtraron sin detalles técnicos, y unas ocho horas después del vídeo que mostraba cómo aprovechar la vulnerabilidad aparecieron en nuestra telemetría herramientas con el nombre PHP2shell. Tanto la primera herramienta con nombre propio como el primer kit para aprovechar la vulnerabilidad que detectamos aparecieron antes del lanzamiento anticipado de las imágenes parcheadas. No especularemos sobre qué motivó la creación de cada herramienta, pero, cuando se produjo el lanzamiento coordinado, el escaneo ya estaba muy avanzado.

El pajar

Desde la primera petición de una herramienta cuyo nombre contiene PHP2shell hasta el mediodía del 22 de octubre, almacenamos unas 250 000 peticiones procedentes de herramientas cuyo nombre contiene PHP2shell, enviadas desde unas 3200 direcciones IP públicas.

Por supuesto, no todos los escáneres operan con intención de ataque. Aproximadamente un tercio de ese tráfico se identifica como defensivo: «comprobación autorizada de exposición», «comprobación del estado de aplicación de parches», «sin aprovechar vulnerabilidades». Muchas organizaciones estaban comprobando sus propios entornos, y eso es positivo. Estas etiquetas autodeclaradas son afirmaciones sin pruebas, pero concuerdan con lo que hacen esas peticiones: pequeñas comprobaciones inofensivas.

Peticiones 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 evolucionó rápidamente. 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 se modifican con tanta rapidez hacen que las firmas basadas en cadenas de User-Agent queden obsoletas en cuestión de un día.

Las agujas

Hasta ahora, la forma más fiable de distinguir el tráfico real de aprovechar del resto ha sido la cadena delimitadora de las partes multipart. Cada kit de explotación que hemos encontrado utiliza un delimitador fijo o que sigue un patrón en su encabezado Content-Type. De este modo, identificamos más de diez kits candidatos, cinco de ellos vinculados directamente a PHP2shell por su nombre, su User-Agent o su comportamiento.

El kit más extendido tiene este aspecto:

• POST /index.php (o /), User-Agent php2shell-109618

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

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

También se dirige a sus objetivos mediante direcciones IP directamente, en lugar de nombres del host, y envía una o dos peticiones por host. Se trata de un escaneo masivo del espacio de direcciones IP, no de una campaña contra sitios concretos. 

Los tamaños del cuerpo de las peticiones varían mucho de un kit a otro, así que no te bases únicamente en los umbrales de tamaño para detectar este tráfico.

Dos casos similares que conviene descartar primero

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

React2Shell (CVE-2025-55182). Dos firmas que circulan para PHP2shell son las peticiones multipart fragmentadas sin Content-Length y los cuerpos rellenados con largas secuencias de la letra A. Durante la hora que analizamos, React2Shell representó el 98,6 % y el 99,9 % de las coincidencias con cada firma, respectivamente. La firma basada en el relleno ya correspondía casi en su totalidad a React2Shell el día anterior al lanzamiento. React2Shell lanza peticiones a todas las rutas, incluidas /xmlrpc.php y /wp-login.php. La forma más sencilla de distinguirlos es el encabezado de petición Next-Action, que utilizan las acciones de servidor de Next.js, pero que PHP nunca utiliza.

Porcentaje de cada firma «PHP2shell» en circulación que corresponde realmente a React2Shell, medido mediante el encabezado Next-Action en peticiones POST a puntos de conexión PHP, del 21 de octubre de 21:00 a 22:00 UTC. La misma hora del día anterior al lanzamiento: el 99,7 % de las coincidencias con la firma de relleno ya correspondían a React2Shell.

wp2shell. Se trata de una vulnerabilidad completamente distinta: una RCE sin autenticación en el núcleo de WordPress divulgada en julio de 2026. Su kit envía cuerpos multipart de gran tamaño al archivo index.php de WordPress, con un delimitador que empieza por ----wp2shell. Ya estaba activo mucho antes de que PHP2shell se hiciera público, así que incluirlo en el recuento crearía una falsa historia sobre php2shell «anterior a su divulgación».

Una conclusión general de ambos casos: una firma basada en la estructura de la petición describe un tipo de petición, no a un atacante. Compara los datos con una referencia anterior a la divulgación y, antes de atribuir cualquier aumento, desglósalo según un encabezado o delimitador identificativo.

Qué se puede y qué no se puede ver desde el edge

Los intentos de aprovechar son visibles en el edge, pero no se puede saber si han tenido éxito. PHP2shell funciona provocando la caída o la corrupción de un proceso de trabajo de PHP, por lo que, desde fuera, un intento que haya tenido éxito puede parecer igual que uno fallido. Si crees que has sido objetivo de un ataque, encontrarás la confirmación en el servidor de origen:

• Registros de errores de PHP-FPM

• Registros de errores de Apache que muestran caídas de procesos de trabajo (por ejemplo, entradas AH00051 "child pid … exit signal")

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

Qué nos dice PHP2Shell sobre la IA

La IA contribuye sin duda a descubrir vulnerabilidades, y lo hace mucho más rápido que antes. Aproximadamente un día después de la aparición de la primera herramienta, detectamos decenas de herramientas con nombre propio procedentes de unas 3200 direcciones IP, y una de ellas pasó de la versión 4.0 a la 7.2 en unas once horas. 

No podemos saber con certeza si alguno de ellos se creó con ayuda de la IA. Lo que sí observamos es que el tráfico en sí no tiene nada de inusual: los kits envían un cuerpo multipart fijo directamente a direcciones IP, una o dos peticiones por host, desde los mismos tipos de infraestructura de VPN y alojamiento que se utilizan en la mayoría de los escaneos. Con independencia del grado de ayuda de la IA, observamos un panorama de amenazas cada vez más amplio y dinámico.

Y, hasta ahora, la defensa sigue dependiendo principalmente de las personas. Los equipos de defensa revisaron sus propios sistemas y clasificaron el tráfico. Los equipos de búsqueda de amenazas compartieron firmas que resultaron corresponder casi por completo a una campaña distinta. La aplicación de parches, el establecimiento de valores de referencia y el análisis de los registros del servidor de origen siguen dependiendo en gran medida de las personas, incluso con ayuda de la IA, y requieren que estas planifiquen 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 u 8.2.35, o al paquete parcheado de tu distribución. Si utilizas la versión 8.1 o una anterior, consulta con tu distribuidor de paquetes sobre los parches retroportados o actualiza.

2. No sigas pistas falsas. El User-Agent, 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 nada como PHP2shell.

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

5. Clientes del WAF de última generación de Fastly: para las aplicaciones protegidas por el WAF de última generación, activa la señal que cubre tanto CVE-2026-109618 como CVE-2026-109619. Es una regla basada en plantillas específica para estas CVE que funciona como un parche virtual y busca indicios estructurales de explotación.
   Consulta el artículo de Fastly sobre la protección proactiva para obtener más información.
   

Nota: también recomendamos considerar la posibilidad de activar la opción de parcheo virtual automático de Vulnerabilidad y exposición comunes en la configuración de las áreas de trabajo, que se muestra a continuación:

Indicadores

Cómo lo medimos

Estas cifras proceden de la telemetría de peticiones del WAF de última 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 retrospectivo de la PHP Foundation y en los registros de avisos de GitHub. Los recuentos son cifras mínimas: solo podemos informar de las peticiones que nuestro WAF detectó y registró, y algunas cifras relativas a los encabezados proceden de horas de muestreo coincidentes, no de días completos.

Lee Protección proactiva de Fastly para PHP2Shell, Critical PHP RCE CVE-2026-109618 y CVE-2026-109619 para obtener información más actualizada.