php2shell: superficie, hunting y detección en red team

php2shell es el nombre del par CVE-2026-109618 y CVE-2026-109619, dos fallos críticos del runtime PHP divulgados el 21 de octubre de 2026 que, en los escenarios confirmados por los avisos oficiales, permiten RCE sin autenticación en PHP en instalaciones que atienden peticiones HTTP.

Además, el aviso oficial en el archivo de 2026 de php.net sitúa el riesgo en el motor que procesa peticiones web, no en un plugin de CMS. Por eso el ángulo de este texto es superficie, inventario en pentest autorizado y hunting defensivo. En contrapartida, el artículo hermano en basilisk cubre el checklist operativo de parcheo. Así el red team evita canibalizar la guía de corrección y aún así entrega un modelo de amenaza útil.

Qué revela la anatomía de php2shell en los dos fallos

El CVE-2026-109618 describe corrupción ligada a falta de memoria en medio de la inicialización de los datos internos de la petición. El CVE-2026-109619 describe estado global que sobrevive a memoria liberada y se reutiliza en la petición siguiente del mismo worker. En conjunto forman el fallo de memoria en PHP apodado php2shell.

Cómo el OOM deja la petición en estado inválido

En el advisory GHSA-w8hw-w9fx-j79w, el equipo de seguridad de PHP explica el papel de longjmp(). El motor usaba ese mecanismo para abortar la petición cuando la memoria se agotaba. En ciertos puntos, parte de la estructura de la petición ya era alcanzable. Sin embargo, todavía no estaba plenamente inicializada. Si una asignación fallaba en ese momento, la ruta de limpieza podía tratar datos inválidos como válidos. De ese modo, el motor seguía leyendo o ramificando sobre ellos.

Cómo el estado obsoleto atraviesa peticiones en el mismo worker

El segundo identificador, CVE-2026-109619, está en el GHSA-6wmf-4rv5-p3rp. Trata campos globales del worker que apuntan a memoria de una petición. Ese estado debe reiniciarse antes de liberar el heap. Cuando un error fatal, un diagnóstico o una ruta de sesión y carga interrumpe el flujo en el momento equivocado, el puntero global permanece. Después, la petición siguiente en el mismo proceso persistente puede consumir ese valor. En términos de clase, el primer CVE combina fallo en el manejo de una condición excepcional con uso de estado no inicializado. El segundo es use-after-free clásico entre peticiones.

Dónde divergen las fuentes sobre alcance y puntuación

Investigadores y coberturas de nube, entre ellas Cloudflare, sitúan rutas explotables desde PHP 5.4 en ciertas configuraciones. El aviso oficial y las GHSA, en cambio, listan como corregidas las líneas 8.2.35, 8.3.36, 8.4.27 y 8.5.12. También hay backports mínimos de código fuente para 7.4, 8.0 y 8.1. La amplitud desde 5.4 es afirmación de investigadores e informes de terceros. No es un inventario cerrado por el CNA de PHP para cada release legado.

La puntuación publicada por el equipo de PHP y reflejada por CERT-EU, NHS England y Datadog es CVSS v4.0 9.2 para ambos. Circuló un 10.0 en la filtración previa a la divulgación. Además, el NVD y proveedores como Red Hat pueden publicar vectores v3.1 distintos. En inventario, anota la fuente de la puntuación y no mezcles escalas entre v3.1 y v4.0.

En la práctica, lo que más veo en compromisos es que el equipo trata los dos CVE de php2shell como un solo ticket de parche. Así desaparece la diferencia de precondiciones. Quien separa el OOM en la limpieza de la petición de la reutilización del worker entiende mejor dónde colocar sensores y prioriza mejor cuando el inventario muestra mod_php frente a FPM.

Qué precondiciones y superficies de ataque importan de verdad

La superficie confirmada por php.net cubre toda instalación PHP que atiende peticiones web. Eso incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo se describe como más alto para mod_php, con exploit demostrado en el que una petición sin autenticación dispara el ataque antes de cualquier código de la aplicación.

Cómo el SAPI y el worker persistente cambian la ventana

La CISA, en la alerta del 21 de octubre de 2026, refuerza que todas las instalaciones que atienden HTTP entran en el alcance. También pide inventario donde el PHP viene embebido en producto de terceros. Los workers persistentes cambian el juego del CVE-2026-109619. El consumidor y el productor del estado obsoleto necesitan el mismo proceso.

En SAPI que matan al hijo tras un fallo en la inicialización, la ruta del CVE-2026-109618 puede estrecharse. El advisory del OOM dice exactamente eso sobre FPM. Ese SAPI termina el hijo cuando el arranque falla y así evita consumir el estado inválido en esa rama. Aun así, el análisis de código del propio advisory apunta a FPM como susceptible en otros momentos. No todas las ramas tienen exploit completo demostrado. La PHP Foundation confirma RCE también en rutas de aplicación bajo FPM. Un proceso por petición reduce la ventana del estado obsoleto entre peticiones. Sin embargo, eso no anula por sí solo el OOM en la limpieza si el apagado aún ve memoria parcial.

Qué bloquean las mitigaciones parciales y qué dejan abierto

Otra precondición práctica es la exposición del análisis automático del cuerpo, multipart y rutas de sesión y diagnóstico que corren temprano. Mitigaciones parciales citadas por php.net, como memory_limit=-1 administrativo para el OOM, bloquean rutas confirmadas. Lo mismo vale para session.upload_progress.enabled=0 con reinicio de workers en el estado obsoleto. Dejan variantes abiertas. Por tanto no vuelven segura la instalación frente a php2shell. Aplicaciones CMS habituales aparecen en demos de investigadores, pero el fallo es del runtime. La autenticación de aplicación no es control para la rama que dispara antes del script.

El error que más cuesta caro aquí es asumir que “no usamos carga de archivos” o “solo hay FPM” equivale a quedar fuera del alcance de php2shell. En inventario real, lo que decide la prioridad es el SAPI, la versión del paquete y la exposición a internet, además de la reutilización del worker. El nombre del CMS en la vitrina casi nunca decide el riesgo.

Cómo el fallo de memoria en PHP se vuelve ejecución de código a nivel conceptual

En lenguaje de clase de bug, el atacante no necesita romper la lógica de WordPress. Obliga al motor a seguir operando sobre estructuras que ya no representan una petición válida. En el CVE-2026-109618, la limpieza tras OOM lee o sigue punteros y metadatos incompletos. Con control suficiente sobre el contenido que ocupa o presiona la memoria de la petición, esa lectura se transforma en corrupción útil. En el CVE-2026-109619, un use-after-free entre peticiones permite que la segunda petición interprete bytes moldeados en la primera. También puede interpretar bytes que se filtren de otras peticiones en el mismo worker.

El puente conceptual hasta RCE es el mismo de otros fallos de memoria en intérpretes. La corrupción o reutilización de objetos internos se vuelve desvío de flujo o llamada a función bajo control del atacante. Los privilegios son los de la cuenta del worker web. La divulgación de memoria, descrita por Wiz, Datadog y por el advisory del estado obsoleto como efecto colateral posible, puede entregar direcciones y secretos. Eso hace más estable la cadena de RCE. Nada de eso exige un layout público en este texto. El punto operativo es que la autenticación de la app y un WAF de firma superficial no cierran la clase. La idea de que no hay RCE en el código de la aplicación tampoco cierra php2shell.

Mucha gente cree que solo importa un desbordamiento de heap clásico con offset publicado. Casi siempre se equivoca, porque aquí el disparador es la ruta de error y el ciclo de vida de la petición. En revisión de amenaza, trata php2shell como fallo de runtime con impacto de shell en el usuario del servidor web, y no como CVE de plugin.

Cómo describir la cadena de ataque a alto nivel sin convertirla en PoC

A alto nivel, la cadena de php2shell comienza con una o más peticiones HTTP especialmente construidas contra un endpoint que PHP analiza. Para el CVE-2026-109618, el objetivo conceptual es provocar fallo de memoria o aborto en un momento en que las estructuras de la petición están a medias. Después, la limpieza opera sobre ese estado. Para el CVE-2026-109619, la secuencia suele involucrar una petición que produce estado global residual. Luego otra petición, en el mismo worker, consume ese estado antes del reinicio completo. El resultado buscado es código bajo el usuario de Apache, de FPM o del SAPI equivalente.

Las fuentes públicas divergen sobre explotación en campo el 21 de octubre de 2026. La CISA afirmó no haber observado explotación en la publicación de la alerta. Cloudflare reportó tráfico de ataque y mutación de cargas útiles contra reglas ya activas. El Centro Canadiense de Ciberseguridad habló de PoC disponible sin explotación activa identificada en esa fecha. SecurityWeek y watchTowr describieron intentos en sensores, y en algunos relatos el éxito aún era limitado. Para el red team y para el SOC, el estado seguro es asumir que la ventana posterior a la filtración es hostil. Inventario más parche gana al debate de telemetría de terceros sobre php2shell.

Quien ya ha barrido inventario de runtime en un cliente sabe que la cadena de petición anómala, worker bajo presión y proceso hijo inesperado aparece antes que cualquier webshell elegante. Si el compromiso está autorizado, documenta la hipótesis y las evidencias pasivas. No dispares el fallo en producción de un tercero ni en un host fuera del RoE.

Cómo evaluar la exposición a php2shell en un pentest autorizado

En un pentest con autorización formal por escrito, la evaluación correcta de php2shell es inventario y validación del nivel de parche. No es disparar la vulnerabilidad. Recoge la versión del intérprete y del paquete de la distribución. Recoge también el SAPI en uso, la presencia de mod_php, los pools FPM, contenedores y appliances que embuten PHP. Compara con 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Cuando la línea sea 8.1 o anterior, compara con el advisory del proveedor LTS.

El NCSC del Reino Unido, en la alerta sobre el problema crítico en PHP, pidió identificación prioritaria de sistemas orientados a internet. También pidió monitoreo continuo de proveedores que empaquetan el runtime. Valida si el banner o el phpinfo expuesto coinciden con el paquete instalado, porque los proxies y las imágenes antiguas mienten. En el entorno del cliente bajo contrato, prefiere lectura de paquete y reinicio controlado tras el parche. Evita prueba destructiva. Si el alcance pide demostración de impacto, usa un laboratorio aislado que espeje SAPI y versión. Nunca uses el objetivo de producción de un tercero. Busca señales de exposición indirecta, como paneles y productos que declaran PHP embebido sin ofrecer actualización fácil.

1. Inventariar hosts, contenedores y appliances con PHP que responden HTTP, con evidencia de paquete y SAPI.
2. Comparar la versión en ejecución con 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o con backport LTS documentado, y marcar exposición cuando el piso corregido no esté presente.
3. Registrar exposición de red, reutilización de worker y restricciones del RoE, sin disparar OOM ni use-after-free en el objetivo de producción.

En un compromiso autorizado, el criterio que uso es simple. Versión por debajo del piso corregido más SAPI web equivale a hallazgo crítico de exposición a php2shell, con evidencia de paquete y configuración. Disparar OOM o use-after-free en el objetivo solo si el RoE lo dice de forma explícita y el entorno es descartable. De lo contrario, mezclas validación con incidente.

Qué señales en logs e indicadores públicos conviene seguir

Las señales útiles para php2shell aparecen en tres capas. La primera es la petición. La segunda es el log de PHP o del servidor web. La tercera es el proceso. El material de Datadog Security Labs sobre php2shell describe correlación entre envíos anómalos, errores fatales de límite de memoria durante la inicialización de la petición y workers que lanzan shell.

Los errores fatales de memoria antes del script entran en la misma familia de IOC. Lo mismo vale para reinicios de hijos Apache con fallo de segmentación. También entran picos de cuerpos grandes o multipart fuera del baseline. Procesos hijos inesperados bajo el UID del servidor web completan el cuadro. La CISA y la alerta canadiense piden atención a workers PHP que lanzan shells, descargan herramientas o crean procesos, archivos, cuentas y conexiones de salida atípicas.

La postexplotación clásica sigue siendo válida. Webshells nuevos en directorios escribibles, descargas con herramientas de red desde el worker, cron o servicios systemd creados por el usuario de PHP, cuentas locales nuevas y conexiones de salida atípicas. Ninguna señal aislada prueba php2shell. Un pico de memoria legítimo y un despliegue mal hecho también generan OOM. La fuerza está en la correlación temporal entre anomalía de petición, fallo de worker y ejecución.

En hunting, el atajo que más engaña es cazar solo cadenas de webshell conocidas. El día cero de la divulgación, lo que aparece primero suele ser ruido de worker e hijos de shell. Yo empezaría por los árboles de proceso de Apache y de FPM. Solo después cerraría en archivos ligados a php2shell.

Cómo pensar la detección php2shell con Sigma y WAF a alto nivel

Las reglas al estilo Sigma para detección php2shell deben describir lógica, no carga útil. Ejemplos de condición genérica incluyen proceso padre del servidor web o del pool FPM creando un intérprete de shell o una utilidad de descarga. Eso vale sobre todo tras una ráfaga de errores fatales de memoria o de reinicio de hijo. Otra familia correlaciona método POST con campos o cabeceras multipart fuera del baseline de la aplicación y respuesta de error en la fase de inicialización. Los umbrales deben nacer del tráfico legítimo del entorno, porque existen cargas reales e importaciones pesadas.

En el lado WAF, Cloudflare describió protecciones gestionadas para php2shell activadas el 21 de octubre de 2026 a las 03:02 UTC. Cubrieron planes Free y de pago con WAF. La publicación habla de un conjunto de reglas de ejecución anómala y de detección de transacción completa. Esa detección combina señales de petición y de respuesta en la misma transacción HTTP. Así reduce el falso positivo y bloquea una respuesta de origen sospechosa. Esto es defensa en profundidad. La propia Cloudflare y php.net repiten que solo el parche cierra el problema. Los atacantes ya intentaban mutar el tráfico contra las reglas.

La detección sin inventario se vuelve teatro. La regla Sigma o el WAF que yo mantendría encendidos mañana son los que alertan proceso hijo anómalo y fallo de inicialización ligado a php2shell. Mientras tanto, el ticket de parche de las versiones corregidas sube con dueño y plazo. El WAF solo no se convierte en aceptación permanente de riesgo.

Qué hacer en respuesta a incidente y en la remediación de php2shell

La remediación completa de php2shell es actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. La alternativa equivalente es aplicar el paquete del proveedor LTS y reiniciar todos los workers. Si la línea es 8.1 o más antigua, el proyecto PHP no emite release normal. Hay backports mínimos de código fuente para 7.4, 8.0 y 8.1. La orientación cruzada de CISA, NCSC y Centro Canadiense es aislar o sacar de exposición los sistemas que no puedan subir a una línea corregida. Las mitigaciones de configuración del aviso oficial reducen rutas específicas. No sustituyen el binario corregido.

En la respuesta a incidente, trata cualquier evidencia de shell bajo el worker como compromiso hasta prueba en contrario. Aísla el host o el pool. Preserva logs de acceso, error_log de PHP, journal del servicio y telemetría de proceso. Ejecuta caza de webshell y de persistencia. Rota credenciales que pudieran estar en la memoria del worker. Valida el nivel de parche en toda la flota, no solo en el host sintomático. El efecto colateral del parche puede incluir cambio de comportamiento de OOM y de rutas de sesión. Prueba en homologación cuando el calendario lo permita. No uses eso como excusa para mantener expuesto a internet un sistema vulnerable a php2shell.

Después del parche, lo que suele sobrar es un appliance olvidado y una imagen de contenedor fijada. Yo cerraría el incidente solo con un inventario rehecho de php2shell. También exigiría confirmación de que no queda un worker antiguo todavía en pie detrás del balanceador.

Preguntas frecuentes sobre php2shell

Esta sección cierra las dudas que más aparecen en compromisos de red team y en war rooms el 21 de octubre de 2026 sobre php2shell y el par CVE-2026-109618 y CVE-2026-109619. Las respuestas separan lo que el aviso oficial confirma de lo que aún depende de telemetría de terceros. También refuerzan el límite ético de la prueba. Úsalas como checklist verbal con el cliente o con el SOC, sin transformar el FAQ en una guía de explotación.

¿El CVE-2026-109618 es lo mismo que php2shell?

No por sí solo. Php2shell es el apodo del par CVE-2026-109618 y CVE-2026-109619. El primero cubre la corrupción vía OOM en la inicialización y limpieza de la petición. El segundo cubre estado global obsoleto entre peticiones en el mismo worker. En inventario y en ticket de parche, trata ambos juntos. En hunting y en modelo de amenaza, conserva la diferencia de precondiciones, porque los sensores y la mitigación parcial no son idénticos en php2shell.

¿La autenticación de la aplicación bloquea la explotación?

En las ramas en las que el disparo ocurre antes del código de la aplicación, no. El aviso de php.net y las reproducciones de laboratorio enfatizan peticiones no autenticadas que alcanzan el motor. Los controles de login del CMS no son el control correcto para esta clase. Por eso el hallazgo debe clasificarse como exposición de runtime de php2shell, no como fallo de plugin o de formulario autenticado.

¿Vale confiar solo en el WAF mientras el parche no sube?

No como solución completa. Un WAF gestionado, como el descrito por Cloudflare, puede reducir exposición y ganar tiempo. Aun así hay riesgo de bypass y de falso negativo cuando el analizador del edge no ve lo mismo que PHP. El aislamiento de sistemas expuestos sigue siendo la alternativa cuando el parche se atrasa. La aceptación permanente de riesgo solo con WAF es una decisión frágil frente a RCE sin autenticación en PHP ligada a php2shell.

¿PHP 7.x y 8.1 están corregidos por el proyecto?

El proyecto no mantiene releases normales de esas líneas. Publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1 y apunta a paquetes de distribuciones y vendors LTS. Sin paquete corregido confirmado, la orientación de varias autoridades es migrar o aislar. En un pentest autorizado, registra la línea EOL como exposición crítica a php2shell hasta haber evidencia de backport aplicado y workers reiniciados.

¿Ya existe explotación masiva confirmada por todas las autoridades?

No hay un consenso único el 21 de octubre de 2026. CISA reportó ausencia de explotación observada en su alerta. Cloudflare, watchTowr y otras empresas reportaron intentos o tráfico de ataque. El Centro Canadiense habló de PoC disponible sin explotación activa identificada en esa fecha. Trata la divergencia con transparencia y prioriza el parche y el monitoreo de procesos ligados a php2shell.

¿Cómo demostrar exposición sin explotar?

Compara versión y paquete con las releases corregidas, confirma SAPI y exposición de red, y documenta. En laboratorio propio o en el entorno autorizado por el RoE, la prueba de concepto queda aislada. En un objetivo de tercero sin autorización formal, cualquier disparo es ilegal y queda fuera del alcance ético. La prueba aceptable en un informe suele ser paquete más configuración más mapeo de superficie de php2shell, no un fallo inducido en producción.

Conclusión

El CVE-2026-109618 y el CVE-2026-109619 desplazan la discusión del bug de plugin al fallo de runtime. El impacto es shell en el usuario del servidor web. Para red team y para detección, la lectura útil de php2shell es inventariar SAPI y nivel de parche. También es correlacionar errores de inicialización con procesos hijos anómalos. Las mitigaciones de configuración entran como reductor de ruta, nunca como cierre del riesgo.

La mayoría de los entornos gana más con una flota corregida en las versiones 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o con equivalente LTS verificado, que con un debate sobre qué laboratorio vio el primer exploit de php2shell. La respuesta cambia cuando el PHP está embebido en un appliance sin canal de actualización. Ahí el primer paso se vuelve aislamiento y presión al proveedor. La caza de compromiso debe asumir que la ventana posterior al 21 de octubre de 2026 ya fue hostil.

Este texto tiene carácter informativo y educativo sobre php2shell y los identificadores CVE-2026-109618 y CVE-2026-109619. No sustituye la evaluación de tu proveedor, de tu equipo de seguridad ni del responsable del entorno. Las pruebas técnicas solo deben realizarse en infraestructuras propias o con autorización formal por escrito del titular del sistema.