PHP avisa de un tercer fallo RCE y Mirai prueba exploits de PHP2Shell

«Building a universal, reliable, one click exploit is quite difficult» (construir un exploit universal, fiable y de un clic es bastante difícil), escribió Bojan (@bojanz), de INFIGO IS, el 23 de octubre de 2026 en el diario del SANS Internet Storm Center tras desmontar las PoC públicas de PHP2Shell. Ese mismo día el proyecto PHP publicó un aviso informativo sobre un tercer vector de ejecución remota de código, CVE-2026-115560, que no recibirá parche de emergencia, mientras Sophos, Hunt.io y SOCRadar documentaban intentos de usar CVE-2026-109618 y CVE-2026-109619 para repartir una variante de Mirai sin que nadie haya confirmado todavía un servidor comprometido.

Esta noticia es la continuación de la cobertura del parche de emergencia que publicamos el 21 de octubre, y recoge lo que ha cambiado en los tres días siguientes: un fallo nuevo sin corregir, exploits que empiezan a saltarse ASLR, una botnet que ya incluye PHP2Shell en su kit de propagación y 32,6 millones de servicios que seguían en una versión afectada el 24 de octubre a las 12:15 UTC.

Un tercer vector en el progreso de subida que PHP corregirá sin prisa

El aviso informativo de PHP, fechado el 23 de octubre, pide fijar session.upload_progress.enabled=0 hasta la siguiente versión ordinaria de corrección de errores «to fully protect from an unlikely RCE vector» (para protegerse por completo de un vector de RCE improbable). El ajuste ya figuraba el 21 de octubre entre las mitigaciones de GHSA-6wmf-4rv5-p3rp para CVE-2026-109619, así que quien lo aplicó entonces y lo mantiene no tiene que hacer nada más.

El fallo solo aparece con una combinación concreta de configuración y código de aplicación. La aplicación tiene que fijar session.serialize_handler en php_binary o php_serialize en su configuración, cambiarlo a php en tiempo de ejecución con ini_set() antes de llamar a session_start() y mantener activo el progreso de subida de sesiones. Las aplicaciones que nunca cambian el serializador en ejecución pueden dejar la función encendida. Por eso el proyecto explica que «we are handling it in the regular release cycle» (lo estamos tratando en el ciclo ordinario de versiones) y que publicará el aviso completo con la próxima versión.

El aviso no da puntuación CVSS, ni versiones afectadas, ni descubridor, ni dice si comparte causa raíz con CVE-2026-109619. NVD no había publicado CVE-2026-115560 cuando consultamos su API el 24 de octubre. La actualización del 23 de octubre del blog de Cloudflare añade un dato que PHP omite, y es que el vector afecta a versiones completamente parcheadas, incluida la 8.5.12, y la regla de su WAF que lo cubre tiene un límite, porque «Customers who have changed session.upload_progress.name are not covered by the WAF rule» (los clientes que han cambiado session.upload_progress.name no están cubiertos por la regla del WAF). En su diario, Bojan apunta en la misma dirección al recomendar el ajuste «since there apparently is a way to bypass even the (currently) available fix» (porque al parecer hay una forma de saltarse incluso la corrección disponible ahora). El aviso de INCIBE-CERT del 21 de octubre seguía sin recoger el nuevo identificador cuando lo consultamos el día 24.

La configuración que PHP recomienda mientras no haya versión corregida se fija en php.ini o en el pool de PHP-FPM, nunca con ini_set() ni con .user.ini, y exige reiniciar todos los workers. La segunda directiva es la capa adicional que proponen Sansec y SOCRadar.

session.upload_progress.enabled = 0
session.use_strict_mode = 1

En PHP-FPM el equivalente por pool es php_admin_flag[session.upload_progress.enabled] = off, y la comprobación hay que hacerla con una petición servida por FPM o por mod_php, porque php -i en la consola describe otra configuración.

Por qué las PoC públicas de PHP2Shell fallan contra un servidor real

El análisis de Bojan en el SANS ISC explica paso a paso por qué la única PoC con sentido entre «an unbelievable amount of AI generated» (una cantidad enorme de PoC generadas por IA) exige condiciones de laboratorio. El exploit envía un POST con 1.001 campos de 3.000 bytes para presionar el asignador de memoria, prepara PHPSESSID y PHP_SESSION_UPLOAD_PROGRESS y remata con un campo de 12 MB para forzar el fallo de emalloc, lo que solo funciona si memory_limit está en 8 MB cuando lo habitual en producción son 128 MB. Después necesita que la siguiente petición caiga en el mismo worker, algo garantizado en un Apache prefork de un solo worker y no en un servidor real, y en sus fases 1 y 2 filtra la base del chunk de Zend MM y la dirección de libphp.so para derrotar ASLR. Las PoC hacen trampa en ese punto, porque leen los offsets de zval_ptr_dtor y zif_system del propio libphp.so del servidor, algo que un atacante remoto tendría que conocer para cada combinación de distribución y versión. La fase final cambia pDestructor por zif_system y ejecuta un comando de 14 bytes como máximo.

LiveOverflow lo cuenta desde el otro lado en este vídeo en inglés: intenta redescubrir el fallo con Codex y las pistas de la demostración pública de Calif, y muestra la distancia que hay entre reproducir una corrupción de memoria y tener un exploit que funcione fuera de un laboratorio.

VulnCheck sostiene que esa distancia se está acortando. Su informe sobre PHP2Shell describe un exploit propio para CVE-2026-109618 que encadena una fuga de memoria descubierta por la propia firma con la ejecución de código en PHP 8.4.26 sobre x86-64 con ASLR activado y display_errors=off, que es la configuración recomendada en producción. A las 17:30 (hora del este de EE. UU.) del 23 de octubre el exploit cubría PHP 8.4.10 a 8.4.26 y 8.5.10 a 8.5.11 en AMD64 y ARM64 con configuración por defecto bajo mod_php, y la firma lo reserva para los clientes de su servicio Initial Access Intelligence. Sobre los cientos de repositorios aparecidos en GitHub, VulnCheck es tajante y dice que «Only a very small number have been legitimate exploits» (solo un número muy pequeño han sido exploits legítimos), y a las 19:00 del día 22 había identificado una PoC pública que sí saltaba ASLR en x86-64, aunque solo contra 8.4.26 con el heap por defecto.

El 22 de octubre SOCRadar encontró el otro extremo de esa carrera, el de los atacantes. Su informe sobre el servidor expuesto describe un directorio de trabajo abierto en 206.188.197[.]105:9999 con un exploit en Python (aslr_exploit.py) para PHP 8.4.26 bajo Apache mod_php, probado en laboratorio y anunciado por su autor como de un clic, más scripts para tomar la huella de una veintena de sitios y sondear once de ellos en Reino Unido, Finlandia, Polonia, Francia, Canadá, Estados Unidos y China. La firma concluye que «we have seen no evidence of shell access on any screened site» (no hemos visto evidencia de acceso a shell en ningún sitio cribado).

La tabla de SOCRadar resume lo que el exploit necesita frente a lo que tiene un servidor endurecido: errores visibles para el visitante, session.use_strict_mode desactivado, el progreso de subida activo, un memory_limit de 8 MB y un único worker prefork de mod_php. Ninguno de los once sitios cumplía las cinco condiciones, aunque seis ejecutaban versiones 8.4 anteriores al parche y cuatro de ellos la 8.4.26.

La segunda figura muestra el resultado del cribado: ninguno de los once mostraba errores, ninguno exponía phpinfo y en cinco la subida de prueba fue aceptada con un 200, en otros cinco bloqueada con un 403 y en uno devolvió un 500. Hunt.io analizó el mismo servidor y amplió la foto en su recorrido por los directorios abiertos: el operador lanzó diez rondas entre las 19:11 y las 20:23 UTC del 21 de octubre, amplió la lista de objetivos de 23 a 123 servidores alojados en nubes, hostings compartidos e ISP, de los que unos 57 ejecutaban PHP y diez rechazaron la petición, y su listener de callback solo recibió escáneres de Internet. Su conclusión, en una frase, es «Big exposure, clear intent, no confirmed working mass exploit yet.» (gran exposición, intención clara, ningún exploit en masa que funcione confirmado todavía).

Hunt.io resumió el hallazgo en X con la cifra de 683.922 IP que filtraban una versión de PHP en un solo día de escaneo. Su instantánea del 22 de octubre contaba 3.189.999 IP únicas que exponen PHP, 1.665.351 con la versión visible en cabeceras, y la rama 7.4 como la más expuesta con 300.930 direcciones. La firma pide leer esas cifras como un suelo, porque las distribuciones aplican parches sin cambiar el número de versión.

Potassium, la variante de Mirai que intenta colarse por PHP2Shell

Sophos vivió en 48 horas el ciclo completo de una alerta. A las 16:18 UTC del 22 de octubre su aviso sobre PHP2Shell informó de varios intentos y de una explotación con éxito desde 45[.]198[.]224[.]169, con un payload escrito en /tmp/nfs y ejecutado con ./nfs php. A las 21:21 UTC corrigió la valoración, porque su telemetría mostraba escaneos y un pequeño número de intentos fallidos, y «there is no evidence of a successful compromise due to these vulnerabilities» (no hay evidencia de un compromiso con éxito debido a estas vulnerabilidades). El payload nunca llegó al equipo porque las contramedidas de Sophos lo bloquearon.

Lo que sí pudo analizar es la muestra. Sophos la identifica como Potassium, una versión actualizada y ampliada de la variante de Mirai detectada a principios de 2026, con funciones de descarga y de interrupción de red. El binario resuelve una dirección de mando y control cifrada, conecta por TCP con 134[.]199[.]154[.]64, envía una petición HTTP, comprueba que la respuesta es un 200 y que el contenido empieza con la cabecera mágica de un ELF, y si falla la resolución normal recurre a 8.8.8.8, 1.1.1.1 y 1.0.0.1. Hunt.io atribuye el tráfico que observó a una botnet IoT del tipo Mirai activa al menos desde mayo de 2026 que ha añadido PHP2Shell a sus métodos de propagación, con un escáner que comparte red (VPSVAULT, AS215925) y huella de escaneo con hosts de su infraestructura de mando y control. SecurityWeek recoge que Arctic Wolf vinculó dos binarios de Potassium con los servidores que alojan los payloads de PHP2Shell, aunque sus datos no muestran que las peticiones descargaran ni ejecutaran el malware. Quien administre equipos embebidos con PHP encontrará en nuestras recomendaciones de ciberseguridad en IoT el contexto de por qué estas botnets siguen funcionando una década después de Mirai.

Los indicadores publicados por Sophos, Hunt.io y Amazon se reproducen aquí tal como los dan las fuentes, con el defang de las que lo usan. Amazon advierte de que sus direcciones incluyen infraestructura de anonimización compartida y pide investigarlas en lugar de bloquearlas sin más.

Hunt.io añade a la lista las redes 89.32.41[.]16, 89.32.41[.]50 y 45.198.224[.]88 como hosts de binarios de la botnet, y tres patrones de detección que no son indicadores atómicos: cualquier user-agent que contenga php2shell, un POST multipart con el campo PHP_SESSION_UPLOAD_PROGRESS y un cuerpo inusualmente grande, y ráfagas de Allowed memory size exhausted en los registros de PHP-FPM desde el 21 de octubre, que delatan un intento y no un compromiso.

Treinta y dos millones de servicios sin parche y 265.516 en España

El panel público de Censys ARC, capturado el 24 de octubre a las 12:15 UTC, cuenta 41.776.208 servicios PHP vistos en una versión afectada desde que empezó el seguimiento el 21 de octubre, 32.603.958 que seguían en una versión afectada en su último escaneo, 9.192.514 que han pasado a una versión corregida y 1.236.664 que lo hicieron en las últimas 24 horas. Otros 55.331.841 servicios, el 57 % de los detectados, no revelan versión y quedan fuera del recuento, y 567.760 que anuncian versiones que nunca existieron se excluyen como probables honeypots. El ritmo de parcheo diario según los datos del panel fue de 4.336.530 servicios el 22 de octubre y 4.300.406 el día 23.

El mapa de hosts por país que Censys publicó el 23 de octubre lo encabezan Estados Unidos, Alemania y China. En servicios afectados, el panel sitúa a Estados Unidos con 10.369.745, Alemania con 4.047.124, Francia con 2.201.498, Países Bajos con 1.679.114 y Rusia con 1.485.588. España ocupa el puesto 25 de 236 países, con 903.510 servicios PHP detectados, 430.454 con versión visible, 265.516 todavía en una versión afectada, 164.938 en una versión corregida, 158.370 que han pasado de afectada a corregida desde el 21 de octubre y 11.431 solo en las últimas 24 horas. La versión más repetida en todo el mundo es la 7.4.33, con 6.671.776 servicios que no recibirán una versión oficial.

La telemetría de Qualys, actualizada el 23 de octubre a partir de datos anonimizados de más de 10.000 clientes, apunta al mismo problema desde dentro de las organizaciones: de 167 millones de instalaciones del paquete PHP, 156 millones con versión conocida, 110 millones (el 71 %) corren ramas fuera de soporte entre la 5.4 y la 8.1 que no recibirán parche del proyecto, 44 millones (el 28 %) están en ramas 8.2 a 8.5 con parche disponible y sin aplicar, y solo 199.000 se habían parcheado en las primeras doce horas tras la divulgación.

El gráfico de Qualys resume ese reparto. SecurityWeek cifra la muestra en 12.000 clientes, pero el informe de la propia firma habla de más de 10.000, y nos quedamos con el dato de la fuente. Las señales de explotación real siguen siendo indirectas. El Nationaal Cyber Security Centrum neerlandés dijo a NOS el 22 de octubre que «we krijgen de eerste signalen binnen dat dat met succes gebeurt» (nos llegan las primeras señales de que está ocurriendo con éxito), señales que proceden de organizaciones con las que trabaja dentro y fuera del país, sin detallar en qué consisten y con una investigación que puede durar meses. En Reino Unido, la ministra Baroness Lloyd of Effra informó el 22 de octubre a la Cámara de los Lores de que 32 servicios del Gobierno estaban fuera de línea y cuatro parcialmente, casi todos por precaución mientras se aplicaban las actualizaciones, y sin compromiso confirmado, según recogen SecurityWeek y The Register. En Países Bajos NOS calcula que al menos 113.000 webs ya muestran una versión corregida. Censys anunció su panel en X el 22 de octubre con el reparto por país, red y versión, y es la fuente más cómoda para seguir cómo evolucionan esas cifras.

El informe de Amazon Threat Intelligence del 21 de octubre, firmado por CJ Moses, CISO de Amazon Integrated Security, fija la fecha que debe abrir cualquier investigación, un intento de explotación registrado en la red de honeypots MadPot el 17 de octubre, cuatro días antes de la divulgación, desde una dirección asociada a una red comercial de anonimización. Moses aconseja «Start investigations from the earliest known exploitation, not from the disclosure date.» (empieza las investigaciones desde la explotación conocida más temprana, no desde la fecha de divulgación). Cloudflare activó sus reglas de WAF a las 03:02 UTC del 21 de octubre y describe atacantes que mutaban el payload para esquivarlas, y Sansec, que el día 21 esperaba explotación a gran escala el mismo día del parche, revisó su postura el 22 y escribió que «The public exploits do not work against a default PHP installation.» (los exploits públicos no funcionan contra una instalación de PHP por defecto). CISA no había incluido ninguno de los tres CVE en su catálogo KEV en el feed del 23 de octubre a las 19:30 UTC, aunque la alerta del 21 de octubre se revisó el día 23 con una regla Sigma, y el FBI publicó ese mismo día la PSA 261023 pidiendo aislar los sistemas con indicios de compromiso, conservar los registros del servidor web y de PHP y denunciarlo en IC3.

Qué revisar en tu PHP antes del siguiente parche ordinario

Arctic Wolf lo deja escrito para quien confíe en los ajustes, «Configuration changes such as memory_limit or session.upload_progress.enabled are not remediation.» (los cambios de configuración como memory_limit o session.upload_progress.enabled no son remediación). Antes de la lista, conviene tener claro qué versión corresponde a cada rama y qué ramas no tienen salida.

Estas son las acciones por orden de urgencia.

1. Confirma que cada servidor web sirve PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 con una petición real, no con php -v en la consola, y reinicia todos los workers de FPM o Apache después de actualizar. En Debian, Ubuntu y RHEL la versión puede no cambiar: busca los CVE en el changelog del paquete.
2. Fija session.upload_progress.enabled=0 en php.ini o en cada pool de FPM, salvo que una aplicación dependa de la barra de progreso nativa, y añade session.use_strict_mode=1. Es la única medida que cubre CVE-2026-115560 hasta la siguiente versión.
3. Si tu aplicación cambia session.serialize_handler con ini_set() antes de session_start(), identifícala y trátala como expuesta al nuevo vector aunque tenga la 8.5.12.
4. Inventaría las instalaciones en ramas 7.4, 8.0 y 8.1 y pide a tu distribución o a tu proveedor de soporte extendido el retroporte de los parches de código fuente que PHP publicó para ellas. Las ramas 5.x a 7.3 no tienen arreglo, así que aíslalas o migra.
5. Busca en los registros desde el 17 de octubre, no desde el 21, en busca de POST multipart con PHP_SESSION_UPLOAD_PROGRESS y cuerpos anormales, user-agents que contengan php2shell, ráfagas de Allowed memory size exhausted en PHP-FPM, procesos hijos de php-fpm, httpd o apache2 que lancen shells o wget, y las direcciones de la tabla de indicadores.
6. Revisa que el WAF que tengas delante aplique las reglas de PHP2Shell a todo el tráfico y recuerda el límite que Cloudflare reconoce si cambiaste session.upload_progress.name. Un WAF compra tiempo, como explicamos en la guía para proteger APIs, pero no sustituye al parche.
7. Si encuentras indicios de compromiso, aísla el servidor, conserva los registros y notifícalo a INCIBE-CERT si eres empresa o ciudadano y al CCN-CERT si perteneces al sector público.

Para los pasos 1 y 5 sirven estos comandos, que combinan las comprobaciones de inventario que propone Arctic Wolf con las búsquedas en registros de Hunt.io.

# Debian/Ubuntu: ¿incluye el paquete los parches aunque la versión no cambie?
apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"
# RHEL, Rocky, AlmaLinux
rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"
# Intentos en los registros de acceso desde el 17 de octubre
grep -iE "php2shell|PHP_SESSION_UPLOAD_PROGRESS" /var/log/apache2/access.log /var/log/nginx/access.log
# Rastro de intentos en PHP-FPM (no prueba compromiso)
grep -c "Allowed memory size" /var/log/php*-fpm.log

Lo que la segunda semana de PHP2Shell deja sobre la mesa

Johannes B. Ullrich, Dean of Research de SANS.edu, devolvió el Infocon a verde el 23 de octubre con una frase que resume la situación, «Treat the time you have now as a gift» (trata el tiempo que tienes ahora como un regalo). Que no haya un compromiso confirmado tres días después del parche es una buena noticia para quien administra PHP y una mala pista para quien decida esperar. VulnCheck ya ejecuta código en producción contra dos ramas completas, el operador de 206.188.197[.]105 tenía un exploit y un pipeline de cribado el mismo día del parche, y la experiencia con Node2Shell y con el fallo de GitLab de esta misma semana es que las PoC fiables llegan cuando la atención ya ha bajado.

El aviso de CVE-2026-115560 nos deja más dudas que respuestas. PHP no dice qué versiones afecta, no le asigna puntuación y no aclara si es un rodeo al parche de CVE-2026-109619, que es la lectura que hacen Bojan en el SANS ISC y Cloudflare al confirmar que afecta a la 8.5.12. Tratar el ajuste como una recomendación opcional porque el proyecto lo califica de improbable es apostar a que ninguna de las aplicaciones de la organización toca el serializador de sesiones en ejecución, y en un parque con WordPress, Drupal, Magento y aplicaciones a medida nadie tiene ese inventario.

El problema de fondo lo dibujan Qualys y Censys con cifras distintas y la misma forma, 110 millones de instalaciones y 23 millones de servicios expuestos en ramas que nunca tendrán versión oficial. En España, a las 12:15 UTC del 24 de octubre, eran 265.516 servicios en versión afectada y 11.431 corregidos en el último día.