Investigadores de seguridad han detectado intentos fallidos de actores de amenazas por explotar las recién reveladas vulnerabilidades PHP2Shell con el objetivo de incorporar sistemas comprometidos a una variante del botnet Mirai denominada Potassium. Estos ataques buscan aprovechar CVE-2026-109618 y CVE-2026-109619, ambas con una puntuación CVSS de 9.2, que permiten ejecución remota de código (RCE) sin autenticación mediante solicitudes HTTP especialmente diseñadas. Las fallas ya fueron corregidas en las versiones de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Según Sophos, el ejemplar analizado corresponde a una versión actualizada y considerablemente ampliada de la variante derivada de Mirai identificada a principios de 2026, e incluye funciones de descarga y de interrupción de red. El malware resuelve una dirección de comando y control (C2) cifrada y codificada de forma fija, establece una conexión TCP con 134.199.154[.]64 y envía una solicitud HTTP. Después verifica que la respuesta tenga el estado HTTP 200 y que el contenido comience con los bytes mágicos ELF 7F 45 4C 46, lo que indica que espera un binario ELF de Linux como carga útil secundaria.
La función de resolución admite direcciones IPv4 y nombres de host, con lógica de respaldo adicional que incluye servidores DNS públicos codificados de forma fija como 8.8.8.8, 1.1.1.1 y 1.0.0.1. Sophos añadió que, al igual que el malware Mirai histórico, esta muestra puede ejecutar ataques de denegación de servicio distribuido (DDoS).
Los ataques se originaron desde tres direcciones IP: 85.11.167[.]243, 217.60.242[.]76 y 45.198.224[.]169. Estas fuentes contactaron a 92.118.112[.]100 para obtener un cargador responsable de desplegar la variante de Mirai. El análisis en un entorno de pruebas aislado reveló que el botnet consulta el dominio thunder.godofthunder[.]st, lo resuelve a 134.199.154[.]64 y establece un canal C2 en el puerto TCP 50792. El objetivo final es lanzar ataques volumétricos sostenidos contra dos hosts adyacentes dentro de una misma red ucraniana: 45.88.138[.]0 y 45.88.138[.]44.
La ausencia de un ataque exitoso con PHP2Shell en entornos reales sugiere que los actores de amenazas están teniendo dificultades para desarrollar exploits fiables, según Sophos. Potassium fue señalado por primera vez por la plataforma de seguimiento de botnets Synthient en marzo de 2026. En un análisis posterior, investigadores de Nokia Deepfield describieron el malware como un fork de Mirai que emplea ChaCha20 para la tabla de configuración estática (la primera vez que se observa este uso en una variante de Mirai), un único byte estático (0xED) para todo el tráfico en la red, un protocolo de shell inverso denominado (SHELL / SHOUT) en el mismo canal que los comandos de ataque, y un esquema de redirección DNS que intercambia las dos mitades de 16 bits de cada registro A resuelto antes de connect().
Arctic Wolf, que también compartió detalles adicionales del mismo intento de explotación armada de PHP2Shell, indicó que el botnet admite 24 comandos para facilitar ataques de inundación sobre ICMP, TCP, UDP y el protocolo OpenVPN. Ambas compilaciones para ARM y x86 contienen además configuración para resolver la infraestructura C2 mediante el Servicio de Nombres de Ethereum (ENS). La firma señaló que la resolución ENS estaba deshabilitada en ambas muestras, lo que indica que la capacidad existía pero estaba inactiva. Si se habilitara en variantes futuras, podría complicar la mitigación al reducir la dependencia de registradores y proveedores de DNS, obligando a los defensores a bloquear los nombres ENS, la infraestructura RPC y las direcciones de comando y control resueltas.
Explotación masiva por parte de actores de amenazas
SOCRadar informó del hallazgo de herramientas de explotación de PHP2Shell para PHP 8.4.26 en un servidor expuesto controlado por atacantes (206.188.197[.]105:9999), junto con tres scripts de sondeo que verifican sitios web activos en busca de las condiciones previas que requiere la cadena PHP2Shell. Estos scripts comprobaron aproximadamente 20 sitios públicos en Canadá, China, Finlandia, Francia, Polonia, Reino Unido y Estados Unidos, examinando la versión de PHP, la configuración del servidor y los ajustes de sesión necesarios para el exploit.
El archivo central, aslr_exploit.py, es un exploit en Python que el operador describe como una herramienta de explotación de PHP2Shell de un solo clic para PHP 8.4.26 bajo Apache mod_php. Funciona completamente mediante solicitudes HTTP ordinarias en tres pasos: recicla el proceso trabajador de PHP del objetivo, filtra direcciones de memoria a través de la cookie de sesión para eludir la aleatorización del espacio de direcciones (ASLR) y luego abusa del manejo del progreso de carga de sesiones de PHP para ejecutar un comando de shell. Los otros tres scripts complementarios son php2shell_fp.py, que lee la versión de PHP y la configuración del servidor en unos 20 sitios; deep_probe.py, que examina 11 de esos sitios en busca de errores visibles, páginas phpinfo, inclusión de archivos e inyección de sesión para determinar si cumplen los requisitos del exploit; y wp_attack.py, que se centra en cinco sitios de WordPress para enumerar usuarios y plugins.
No obstante, hasta el 22 de octubre de 2026 no había evidencia de acceso a shell en ninguno de los sitios sondeados, lo que indica que los sitios objetivo no cumplían las condiciones previas del exploit. El conjunto de herramientas se considera parte de una operación más amplia en la que el atacante extrae claves de API y URL de backend del JavaScript del lado del cliente de los sitios web, rastrea sistemáticamente rutas web y de API en busca de acceso sin autenticación, y utiliza un grupo de proxies rotativos para distribuir el tráfico y evadir límites de velocidad y bloqueos. SOCRadar señaló que los artefactos relacionados en el servidor apuntan además a reconocimiento de archivos web y resolución automática de CAPTCHA, lo que en conjunto sugiere un actor con motivación económica centrado en objetivos de criptomonedas y Web3.
El mismo servidor de explotación (206.188.197[.]105) también fue señalado por Hunt.io, que indicó que el actor detrás de la operación atacó 123 servidores en redes de nube, alojamiento compartido y proveedores de servicios de internet. Alrededor de 57 ejecutan PHP, muchos en versiones 5.x a 7.x sin soporte. Diez rechazaron la solicitud directamente, incluidos tres de los cinco que están detrás de Cloudflare. Ninguno fue explotado. En total, se identificaron diez directorios abiertos que contienen herramientas relacionadas con PHP2Shell, entre ellos 206.188.197[.]105, 102.210.149[.]166, 122.10.110[.]72, 122.10.17[.]49, 58.221.60[.]160:8000, 41.223.30[.]7, 157.230.117[.]70, 104.219.251[.]31, 107.150.31[.]151, 217.160.132[.]82, 47.100.125[.]108, 54.169.109[.]7 y 139.162.165[.]136.
Cómo superar las protecciones ASLR
La divulgación coincide con el desarrollo de un exploit de PHP2Shell capaz de lograr ejecución remota de código en sistemas x86-64 con ASLR habilitado y con la configuración de producción recomendada por PHP. Spencer McIntyre, director de desarrollo de exploits de VulnCheck, explicó a The Hacker News que uno de los mayores obstáculos ha sido la aleatorización del espacio de direcciones (ASLR), una protección diseñada para dificultar la explotación de vulnerabilidades de corrupción de memoria. El equipo desarrolló una técnica novedosa que encadena ambas vulnerabilidades, utilizando una fuga de memoria para eludir ASLR y lograr ejecución remota de código en sistemas x86-64, incluso con la configuración de visualización de errores de producción recomendada por PHP.
McIntyre añadió que no han identificado otro exploit público o comercial que logre esto en las mismas condiciones. Desarrollar esta capacidad no fue trivial, pero demuestra que se puede superar una barrera importante para explotar PHP2Shell en sistemas configurados para producción. Las consecuencias de una explotación exitosa son graves, ya que permite a un atacante ejecutar código con los permisos de la aplicación web, accediendo potencialmente a claves de API, conexiones a bases de datos y otros servicios internos a los que la aplicación puede llegar. Según McIntyre, un atacante no necesita necesariamente acceso de administrador o root para causar daños significativos; el acceso a una aplicación web vulnerable podría proporcionar un punto de apoyo en otras partes de la infraestructura de una organización.
Muchos intentos de explotación, ninguno exitoso
Los hallazgos coinciden con informes que indican amplios intentos de explotación de las vulnerabilidades, incluido uno desde una dirección IP con sede en China que intentó depositar una web shell a través de un archivo de sesión del lado del servidor. La empresa de infraestructura web Cloudflare informó que observó decenas de miles de intentos de explotación 45 minutos después del anuncio público de las fallas, cifra que ascendió a cientos de miles en dos horas y a millones a principios del 22 de octubre de 2026.
Cisco Talos señaló que la mayor parte de la actividad es de escaneo, junto con algunos intentos descoordinados de entregar diversas cargas útiles. Esto es esperable, ya que el escaneo o la explotación básica con código de prueba de concepto (PoC) público requiere mucho menos esfuerzo que integrar una vulnerabilidad en las propias herramientas de un actor. Los datos de la telemetría de Previdian han registrado cientos de intentos de explotación contra CVE-2026-109618 desde docenas de direcciones IP, y en menor medida contra CVE-2026-109619. El primer evento de explotación dirigido a CVE-2026-109618 se registró el 21 de octubre de 2026 a las 13:05 UTC. Previdian indicó que han visto numerosas sondas y intentos de explotación de PHP2Shell en sus honeypots, pero hasta el momento no han observado ejecución remota de código exitosa ni archivos PHP depositados, por lo que lograr RCE fiable puede ser más difícil de lo esperado inicialmente.
Esta evaluación también fue compartida por Beelzebub, Dataminr y Wordfence, con actividad observada limitada hasta ahora al escaneo, la identificación de huellas y los intentos de confirmar la ejecución de comandos, robar credenciales y secretos de variables de entorno, instalar acceso persistente y recuperar y ejecutar una carga útil de segunda etapa. Wordfence compartió las siguientes direcciones IP entre las que intentan explotar las fallas: 87.121.84[.]174, 181.215.186[.]252, 185.196.220[.]132, 185.161.210[.]29, 152.233.51[.]69, 45.134.225[.]16, 107.189.14[.]87, 193.47.62[.]24, 2409:40d2:204e:4be:2a1f:f9c9:a055:e00b y 103.147.220[.]17.
La gravedad de las fallas también llevó a que varios sitios web gubernamentales, escolares y hospitalarios se desconectaran en Asia, Europa y Norteamérica por precaución. El gobierno del Reino Unido confirmó que 32 servicios digitales están no disponibles y cuatro parcialmente no disponibles, en gran medida debido a cierres preventivos mientras se aplicaban actualizaciones de seguridad y mitigaciones. El Centro Nacional de Ciberseguridad (NCSC) emitió aproximadamente 50.000 advertencias a empresas y otras organizaciones.
El equipo de investigación de amenazas de Sysdig señaló que el código vulnerable se remonta a PHP 5.4, lanzado en 2012, y que los errores residen en el motor de PHP, no en una aplicación concreta. Por esa razón, cualquier sitio de WordPress, Drupal o Joomla con código de aplicación limpio sigue expuesto. Dado que las correcciones no están disponibles para versiones antiguas de PHP, se espera que PHP2Shell tenga una larga cola similar a Log4Shell. Según estimaciones de VirusTotal, propiedad de Google, unos 272.000 hosts ejecutan una rama de PHP con soporte (8.2 a 8.5). Se recomienda a las organizaciones que usan PHP 7.4, 8.0 u 8.1 que migren a una rama con soporte o utilicen un backport de la distribución.
La plataforma de gestión de superficie de ataque Censys indicó que actualmente detecta más de 3,08 millones de hosts y 56,6 millones de propiedades web que ejecutan PHP. De ellas, más de 34,4 millones de servicios PHP siguen evaluados como vulnerables a fecha del 23 de octubre de 2026. Dataminr advirtió que muchas aplicaciones con servidores web y similares probablemente seguirán vulnerables hasta que sus respectivos proveedores corrijan estos elementos, lo que implica que muchas organizaciones podrían permanecer expuestas en cierta medida mucho más tiempo que cuando los parches se aplican directamente a las aplicaciones propias y gestionadas.
Deja una respuesta