Dos vulnerabilidades críticas en el núcleo de PHP — CVE-2026-109618 y CVE-2026-109619 (CVSS v4.0 9.2)— desencadenaron una ola de escaneos e intentos de explotación en cuestión de horas tras su divulgación el 21 de octubre de 2026. Las vulnerabilidades permiten la ejecución remota de código sin autenticación a través de peticiones HTTP especialmente diseñadas y afectan a todas las versiones de PHP anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Según varios grupos de investigación independientes — Sophos, Arctic Wolf y Hunt.io— ninguno de los intentos observados ha dado lugar a una compromisión confirmada. Ya hemos escrito sobre los detalles técnicos de estas vulnerabilidades y las medidas de protección; este material se centra en el análisis de la actividad real de los atacantes y en las razones por las que la explotación ha resultado ser más complicada de lo esperado.
Naturaleza de las vulnerabilidades y alcance de la superficie de ataque
Según el boletín de CERT/CC (VU#763488), CVE-2026-109618 es una vulnerabilidad de corrupción de memoria en el mecanismo de gestión de falta de memoria (OOM) de PHP: bajo determinadas condiciones, los datos de una petición parcialmente inicializada pueden ser accesibles durante la limpieza. CVE-2026-109619 es una vulnerabilidad de tipo «use-after-free», en la que un estado global obsoleto perteneciente a una petición se reutiliza en una petición posterior del mismo proceso de trabajo.
El código vulnerable está presente en PHP desde la versión 5.4 (año 2012), lo que significa que el problema afecta no a una aplicación concreta, sino al propio motor de PHP. Cualquier sitio en WordPress, Drupal o Joomla con código de aplicación limpio sigue siendo vulnerable si PHP no está actualizado. Se ven afectadas las configuraciones de PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Según CERT/CC, Apache mod_php representa el mayor riesgo, ya que la explotación puede producirse antes de que se ejecute el código de la aplicación.
Según las estimaciones de Censys, a 23 de octubre de 2026 más de 34,4 millones de servicios PHP seguían siendo potencialmente vulnerables, de un total de más de 56,6 millones de propiedades web que utilizan PHP. Las organizaciones que siguen en PHP 7.4, 8.0 o 8.1 no reciben actualizaciones de seguridad oficiales por parte de PHP Project y necesitan backports de los distribuidores o migrar a una rama con soporte.
Actividad de los atacantes: mucho ruido, cero resultados
El escaneo a gran escala y los intentos de explotación comenzaron en los 45 minutos posteriores a la divulgación pública de las vulnerabilidades. Según Arctic Wolf, la actividad observada oscilaba entre comprobaciones básicas del comportamiento vulnerable del mecanismo de seguimiento del progreso de cargas de sesión de PHP y intentos de confirmar la ejecución de comandos del sistema operativo.
Un hecho fundamental: Sophos informó inicialmente de una explotación exitosa de PHP2Shell en algunos de sus clientes, pero posteriormente corrigió esta evaluación, indicando que la telemetría solo mostraba escaneos e intentos fallidos sin pruebas de una compromisión exitosa. Hunt.io confirmó este resultado de forma independiente: el único operador de explotación masiva detectado realizó diez pasadas sobre 123 servidores y no obtuvo ni un solo shell. Wordfence, Previdian, Beelzebub y Dataminr registran el mismo panorama.
La principal razón de los fracasos de los atacantes es la necesidad de sortear ASLR (Address Space Layout Randomization), un mecanismo de aleatorización del espacio de direcciones que hace impredecible la ubicación del código en memoria. VulnCheck desarrolló un método que encadena ambas vulnerabilidades para eludir ASLR en sistemas x86-64 con la configuración de PHP recomendada para producción, pero subrayó que crear un exploit de este tipo «está lejos de ser trivial». Esto explica la brecha entre el escaneo masivo y la ausencia de ataques exitosos.
El botnet Potassium y la infraestructura de los ataques
El tráfico de explotación observado está vinculado a Potassium, una variante del botnet Mirai detectada por primera vez por la plataforma Synthient en marzo de 2026. La relación se ha establecido a nivel de infraestructura y de muestras de malware por tres grupos de investigación independientes (Sophos, Arctic Wolf, Hunt.io), aunque el atacante concreto responsable no ha sido identificado. Es importante subrayar que las pruebas vinculan las peticiones PHP2Shell con la infraestructura de Potassium, pero no confirman que las muestras asociadas hayan sido descargadas y ejecutadas a través de estas vulnerabilidades.
Según Sophos, una muestra de Potassium establece una conexión TCP con el servidor C2 134.199.154[.]64, envía una petición HTTP y espera a cambio un binario ELF para Linux. El botnet soporta 24 comandos para llevar a cabo ataques DDoS a través de los protocolos ICMP, TCP, UDP y OpenVPN. Entre sus características técnicas destacan el uso de ChaCha20 para cifrar la tabla de configuración estática (por primera vez en variantes de Mirai), un esquema de redirección DNS con permutación de las mitades de 16 bits de cada registro A, así como compatibilidad inactiva pero integrada para resolver la infraestructura C2 mediante Ethereum Name Service (ENS).
Por separado, SOCRadar descubrió en un servidor abierto del atacante (206.188.197[.]105:9999) un conjunto de herramientas para la explotación de PHP2Shell, incluido el script aslr_exploit.py, un exploit para PHP 8.4.26 bajo Apache mod_php que funciona en tres fases: reinicio del worker de PHP, filtración de direcciones de memoria a través de una cookie de sesión para eludir ASLR y abuso del mecanismo de seguimiento del progreso de cargas de sesión para ejecutar un comando.
Indicadores de compromiso
IOC clave extraídos de las investigaciones:
- Direcciones IP de origen de los ataques: 85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169
- Infraestructura de descarga: 92.118.112[.]100, 206.188.197[.]105
- Servidor C2: 134.199.154[.]64 (puerto TCP 50792)
- Dominios: thunder[.]godofthunder[.]st, hackattackkaboom[.]botlesscucks[.]st
- Hashes de muestras: 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3
Detección práctica de intentos de explotación
Según Hunt.io y Arctic Wolf, para distinguir entre intentos de escaneo y una compromisión real es necesario correlacionar varias señales:
- User-Agent que contenga cadenas del tipo
php2shell-scan/109618ophp2shell-109618 - Peticiones POST multipart con el campo
PHP_SESSION_UPLOAD_PROGRESSy un cuerpo anómalamente grande - Picos de errores «Allowed memory size exhausted» en los registros de PHP-FPM
- Actividad posterior: creación de procesos, cambios en el directorio raíz del servidor web, conexiones de red salientes hacia las direcciones C2 enumeradas
La presencia de los tres primeros indicios apunta a un intento de explotación; el cuarto indica una posible compromisión que requiere una investigación inmediata.
Recomendaciones
- Actualice PHP de inmediato a las versiones 8.2.35, 8.3.36, 8.4.27 o 8.5.12, tal y como recomienda CERT/CC
- Las organizaciones que utilizan PHP 8.1 o versiones anteriores no reciben actualizaciones de PHP Project: es necesaria la migración a una rama con soporte o la aplicación de un backport del distribuidor
- Revise los registros de los servidores web en busca de los IOC y patrones de explotación enumerados
- Bloquee las conexiones de red hacia las direcciones C2 y dominios indicados a nivel de perímetro
- Para configuraciones con Apache mod_php, considere un cambio temporal a PHP-FPM, que proporciona un aislamiento adicional de procesos
La situación actual con PHP2Shell recuerda a los primeros días de Log4Shell: el código vulnerable lleva existiendo más de diez años, afecta al motor y no a la aplicación, y no hay parches para las ramas obsoletas. La ausencia de compromisos confirmados por el momento es consecuencia de la complejidad técnica de eludir ASLR, y no de la seguridad de los sistemas vulnerables. VulnCheck ya ha demostrado que esta barrera puede superarse. La prioridad para cualquier organización que utilice PHP es actualizar a una versión corregida antes de que los exploits fiables estén disponibles para un círculo más amplio de atacantes.
