En el post anterior, Chiyana analizaba las implicaciones estratégicas que han dejado las recientes vulnerabilidades críticas de PHP (CVE-2026-109618 y CVE-2026-109619, popularmente bautizadas bajo el conjunto PHP2Shell). Como acertadamente señalaba Chiyana, "la vulnerabilidad no estaba en tu web": podías tener la aplicación perfectamente auditada y, aun así, estar expuesto en la capa del intérprete.

A medida que han transcurrido los días tras los avisos de emergencia del 21 de octubre de 2026, ha comenzado a emerger la telemetría real de producción recopilada por firmas de seguridad como Wordfence, Datadog y Akamai.

El escenario que revelan los datos es apasionante desde la ingeniería de ciberseguridad, se han registrado decenas de miles de intentos de ataque automatizados, pero la brecha entre la explotabilidad teórica en laboratorio y el compromiso efectivo en producción ha resultado ser enorme.

Analizamos técnicamente qué están buscando los atacantes en los servidores, cómo están estructurados sus payloads y por qué este incidente redefine la forma en que evaluamos la gravedad de una vulnerabilidad.

1. El vector de ataque: Session upload progress y OOM

Para entender el tráfico observado en los logs, es necesario bajar al nivel de servicio de PHP. Los exploits dirigidos a PHP2Shell no atacan un archivo de tu código, atacan la superficie de procesamiento multipart y PHP_SESSION_UPLOAD_PROGRESS.

Cuando un servidor PHP recibe un archivo mediante una petición multipart/form-data, el intérprete asigna memoria dinámicamente y procesa los campos antes de que el script ejecute la primera línea de código. Si la petición incluye una variable de progreso de sesión, PHP intenta gestionar el estado en memoria interna.

La técnica de presión de memoria (OOM):

Los atacantes envían peticiones HTTP deliberadamente deformadas que contienen cientos de campos repetidos (t[0], t[1], t[136]...). El objetivo es forzar un escenario de agotamiento de memoria (Out of Memory - OOM) dentro de las estructuras internas de la biblioteca de gestión de memoria de PHP (Zend MM).

POST / HTTP/1.1
Host: objetivo.com
Content-Type: multipart/form-data; boundary=p2s0adf525faa
Content-Length: 63395

--p2s0adf525faa
Content-Disposition: form-data; name="PHPSESSID"
d1f6b03d7696286fe2bb0537a5
--p2s0adf525faa
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"
x
--p2s0adf525faa
Content-Disposition: form-data; name="t[0]"
@0000000AAAAAAAA...system0echo P2S_OK;env;head -c 200 .env wp-config.php...

Al desbordar o alterar los bloques de memoria asignados a las peticiones concurrentes, los atacantes intentan inyectar punteros a funciones internas del sistema (como system() o exec()) para tomar el control del flujo del proceso PHP Worker.

2. Telemetría de producción: ¿Qué están buscando los atacantes?

La telemetría analizada sobre muestras de más de 10.000 eventos de ataque bloqueados por cortafuegos perimetrales muestra que la amenaza no responde a escaneos genéricos, sino a campañas altamente especializadas.
Los patrones de ataque se dividen en varias familias principales de payloads:

Familia de Payload / TécnicaObjetivo Táctico
P2S (OOM / Corruption de Estado)Alterar la asignación de memoria en Zend MM para forzar la ejecución del comando system() enviado en la petición.
Gadget Chains en Cadenas Serializadas (Laravel / Symfony / Monolog)Intentar aprovechar objetos de frameworks conocidos (Illuminate\Broadcasting\PendingBroadcast, Monolog\Handler\BufferHandler) presentes en la memoria de la aplicación.
Session-File Poisoning (NxSP)Corromper archivos temporales de sesión en el sistema de archivos local para combinarlo con fallos de inclusión de archivos locales (LFI).

Las acciones de post-explotación en el payload:

Si el exploit tuviera éxito, las instrucciones inyectadas ejecutan inmediatamente un script de reconocimiento diseñado para:

  1. Validar la ejecución buscando marcadores en la respuesta HTTP como P2S_OK, NxSP o SHL_OK.
  2. Extraer secretos y credenciales leyendo los primeros bytes de los archivos de configuración (.env, ../../.env, wp-config.php) o imprimiendo variables de entorno (env).
  3. Garantizar la persistencia escribiendo webshells PHP en directorios con permisos de escritura con nombres como wp2s.php, php2shell.php o axiom_*.php.

3. ¿Por qué un fallo CVSS 9.2 no ha provocado un desastre masivo?

Desde la publicación de los avisos por parte de agencias como la NSA y proveedores cloud, existía el temor a una ola masiva de servidores comprometidos. Sin embargo, la telemetría confirma que no se han registrado compromisos masivos confirmados en producción.

¿A qué se debe esta paradoja entre una puntuación de gravedad máxima (CVSS 9.2) y la ausencia de infecciones masivas?

La complejidad del entorno del Worker:

Las pruebas de laboratorio independientes aclaran el motivo, la explotación de CVE-2026-109618 y CVE-2026-109619 es extremadamente sensible al entorno de ejecución.

  • El comportamiento en laboratorio: Un proof of concept (PoC) diseñado para forzar la ejecución remota de código (RCE) solo logró ejecutar comandos en entornos PHP compilados con configuraciones de depuración específicas o SAPI muy concretos.
  • El comportamiento en producción: En un entorno PHP de producción optimizado, el mismo payload malicioso en lugar de otorgar una consola de comandos al atacante, provoca una corrupción de memoria limpia que crashia el proceso worker de PHP (provocando un error 500 o 502 Bad Gateway).

En la práctica, la complejidad para alinear la disposición de memoria (heap layout) en un entorno de producción real ha convertido a este ataque en una herramienta inestable para ataques masivos no dirigidos.

4. Indicadores de compromiso (IoCs) para equipos de operaciones

Si gestionas infraestructura web o sistemas SIEM/WAF, debes monitorear la presencia de estos patrones en las peticiones entrantes y en el sistema de archivos:

Patrones de búsqueda en Logs (Nginx / Apache / WAF):

  • Cadenas de control en respuestas/peticiones: P2S_OK, NxSP[0-9]+, SHL_OK, ADV618BOUNDARY.
  • Clases serializadas sospechosas en peticiones multipart: Monolog\Handler\BufferHandler, Illuminate\Broadcasting\PendingBroadcast, Requests_Utility_FilteredIterator.
  • Nombres de archivos de persistencia en disco: wp2s.php, php2shell.php, axiom_*.php.

Conclusión

El caso de PHP2Shell nos deja una lección fundamental de ingeniería de seguridad, la gravedad nominal de un CVE no siempre equivale a una explotación sencilla.

Mientras que en vulnerabilidades de capa de aplicación (como el CVE-2026-32475 en Elementor Pro) los atacantes pueden automatizar la toma de control de un sitio en segundos con una simple petición HTTP POST, las vulnerabilidades en la memoria del runtime (como PHP2Shell) exigen una precisión quirúrgica que la mayoría de las botnets no logran replicar a escala.

Aun así, la ausencia de compromisos masivos hoy no garantiza la seguridad de un servidor sin parchear mañana. La única respuesta definitiva sigue siendo la misma, mantener los entornos de ejecución actualizados (PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35) y asegurar la infraestructura mediante defensas en capas.

Referencias:
· Wordfence Threat Intelligence (2026). Attacks on PHP2Shell Continue, But No Known Compromises as a Result Yet.
· Datadog Security Labs (2026). PHP2Shell: Detection, Analysis, and Remediation.
· Continuous Offensive Security (COS): La Evolución del Pentesting en el Pipeline DevSecOps.

Compartir es construir