Dos días después de que PHP publicara los parches de PHP2Shell (CVE-2026-109618 y CVE-2026-109619), los intentos de ataque se cuentan por millones, según Cloudflare, pero las firmas de seguridad consultadas no han confirmado ningún compromiso exitoso. Eso puede cambiar: VulnCheck ha demostrado un exploit que esquiva la protección ASLR en configuración de producción y se han encontrado herramientas de ataque en servidores de atacantes. Según Censys, más de 34,4 millones de servicios PHP seguían siendo vulnerables a 23 de octubre. La recomendación no cambia: actualizar PHP y reiniciarlo.

¿No sabes de informática? Hemos preparado una versión en lenguaje sencillo, con mensajes listos para copiar: el fallo de seguridad de PHP explicado fácil.

Dónde estamos a 23 de octubre

Este artículo recoge lo que ha cambiado desde la guía para actualizar PHP paso a paso. Allí se explica qué son las dos vulnerabilidades, a quién afectan y cómo corregirlas. Aquí, lo nuevo.

PreguntaRespuesta, según las fuentes
¿Hay intentos de ataque?Sí. Cloudflare habló de decenas de miles a los 45 minutos del anuncio, cientos de miles a las dos horas y millones a primera hora del 22 de octubre.
¿Se ha confirmado algún compromiso?No públicamente. Previdian no ha visto ejecución remota exitosa ni archivos PHP depositados; Wordfence no conoce compromisos, y Sophos y Hunt.io tampoco han observado ataques exitosos.
¿Existe un exploit que funcione?Sí. VulnCheck ha desarrollado uno que esquiva ASLR en sistemas x86-64, y SOCRadar halló herramientas de ataque para PHP 8.4.26 con Apache mod_php.
¿Cuántos servicios siguen expuestos?Más de 34,4 millones de servicios PHP, según Censys.
¿Qué hay que hacer?Actualizar PHP a la versión corregida de tu rama y reiniciarlo.

Los ataques que ya se ven

La mayor parte de la actividad es escaneo. Según Cisco Talos, hay además intentos descoordinados de entregar distintas cargas maliciosas, algo previsible: usar un código de prueba público exige mucho menos esfuerzo que integrar un fallo en las herramientas propias de un atacante. Beelzebub, Dataminr y Wordfence describen lo mismo: sondeos, identificación de servidores, intentos de comprobar que pueden ejecutar comandos, de robar credenciales y secretos guardados en variables de entorno, de instalar acceso persistente y de descargar y ejecutar una segunda fase. VulnCheck ha visto además una dirección de origen chino que intentaba depositar una web shell a través de un archivo de sesión del servidor.

También hay intentos de usar PHP2Shell para reclutar servidores en una variante de la botnet Mirai llamada Potassium. Según Sophos, la muestra es una versión ampliada de una variante de Mirai identificada a principios de 2026, con funciones de descarga y de ataques de denegación de servicio. Arctic Wolf señala que admite 24 comandos para ataques de inundación por ICMP, TCP, UDP y OpenVPN. Esos intentos fracasaron, y Sophos interpreta que la ausencia de ataques exitosos sugiere que los atacantes tienen dificultades para conseguir exploits fiables.

Por qué no hay compromisos masivos, y por qué no conviene relajarse

Los dos fallos afectan a la gestión de memoria y del estado interno de PHP, un tipo de vulnerabilidad difícil de convertir en un ataque fiable. Una de las mayores barreras es ASLR, una protección que cambia de forma aleatoria dónde se carga el código en memoria para que el atacante no pueda predecirlo.

Esa barrera ya se ha superado en laboratorio. Según Spencer McIntyre, de VulnCheck, su equipo ha desarrollado una técnica nueva que encadena las dos vulnerabilidades y usa una fuga de memoria para esquivar ASLR y conseguir ejecución remota de código en sistemas x86-64, incluso con el ajuste de producción que PHP recomienda para mostrar errores. McIntyre afirma que no conocen otro exploit público o comercial que lo consiga en esas condiciones y que el trabajo demuestra que una barrera importante puede superarse.

Por otro lado, SOCRadar encontró en un servidor de atacantes una herramienta de "un clic" para PHP 8.4.26 con Apache mod_php, que funciona con peticiones HTTP normales. En ese servidor no hay evidencia de acceso a ninguna de las webs que probó, que no cumplían los requisitos del exploit.

Qué significa un exploit en esas condiciones: quien ejecute código lo hace con los permisos de la aplicación web. No necesita ser administrador del servidor para causar daño: puede acceder a claves de API, conexiones con la base de datos y otros servicios internos que la aplicación alcance, según VulnCheck.

Un actor interesado en cripto y Web3

La valoración de SOCRadar sobre el atacante cuyo servidor encontró es que se trata de un actor con motivación económica centrado en objetivos cripto y Web3. Su herramienta comprobó unas veinte webs públicas (de Canadá, China, Finlandia, Francia, Polonia, Reino Unido y Estados Unidos) para ver si cumplían las condiciones del exploit. La operación incluía además extraer claves de API y direcciones de servicios de backend del código JavaScript de las webs, rastrear rutas en busca de accesos sin autenticación y usar proxies rotativos para repartir el tráfico.

Hunt.io, que ha identificado al mismo servidor, cifra en 123 los servidores que ese actor atacó. Unos 57 ejecutaban PHP, muchos con versiones sin soporte (de la 5.x a la 7.x). Diez rechazaron la petición de plano, entre ellos tres de los cinco que estaban detrás de Cloudflare, y ninguno resultó explotado.

Es una valoración de una empresa de seguridad, no un hecho cerrado. Pero tiene una lectura práctica evidente para quien gestione una web, un panel o una API ligados a cripto: es un objetivo atractivo.

Una sonda cuatro días antes de la divulgación

El equipo de inteligencia de amenazas de Amazon detectó un intento de explotar PHP2Shell el 17 de octubre contra su servicio de señuelos MadPot, cuatro días antes de la publicación de los parches. Procedía de una dirección asociada a una red de anonimización comercial. CJ Moses, director de seguridad de Amazon, señaló que, estando la vulnerabilidad bajo embargo, apunta a un actor, aunque no está claro cómo obtuvo la información. Amazon describió la actividad como una sonda aislada en su mayor parte.

Quién lo descubrió y qué antigüedad tiene

Según The Hacker News, los fallos los encontraron Wiz Research, Calif y el equipo Codex Security de OpenAI, que trabajaron con el equipo de seguridad de PHP y con el equipo Gemini de Google en la corrección. El código vulnerable lleva más de una década en PHP: Sysdig sitúa su origen en PHP 5.4, de 2012. Como los fallos están en el motor y no en las aplicaciones, cualquier WordPress, Drupal o Joomla con código limpio sigue expuesto si el PHP del servidor no está corregido.

Cuántos siguen expuestos y qué efecto ha tenido

Censys detecta más de 3,08 millones de servidores y 56,6 millones de propiedades web con PHP, y estima que más de 34,4 millones de servicios PHP seguían siendo vulnerables a 23 de octubre. Dataminr advierte de que muchas aplicaciones con servidores web seguirán vulnerables hasta que sus fabricantes las corrijan, mucho después de que los administradores hayan parcheado lo suyo. Se espera, según recoge The Hacker News, una cola larga como la de Log4Shell, sobre todo porque no hay corrección oficial para las ramas de PHP anteriores a la 8.2.

El efecto ya se ha notado en el mundo real. Varias webs de gobiernos, escuelas y hospitales de Asia, Europa y Norteamérica se desconectaron por precaución. El Gobierno británico confirmó que 32 servicios digitales estaban no disponibles y cuatro parcialmente, en su mayoría por esos cierres preventivos, y su centro nacional de ciberseguridad, el NCSC, envió unos 50.000 avisos a empresas y organizaciones.

Qué hacer ahora

El cortafuegos web de Cloudflare es una capa útil, pero su propio equipo lo calificó de medida provisional y pidió actualizar. Hunt.io observó que tres de los cinco servidores que estaban detrás de Cloudflare rechazaron la petición de plano, pero eso no es una garantía: un atacante que alcance el servidor directamente puede saltarse esa protección.

Preguntas frecuentes

¿Ya hay webs hackeadas por PHP2Shell?

Hay millones de intentos, pero las firmas de seguridad consultadas (Previdian, Wordfence, Sophos, Hunt.io) no han confirmado compromisos exitosos a 22 y 23 de octubre. Que no haya casos confirmados no significa que no vaya a haberlos.

Si es tan grave, ¿por qué es difícil de explotar?

Porque son fallos de gestión de memoria, y las protecciones como ASLR dificultan convertirlos en un ataque fiable. Aun así, VulnCheck ha demostrado que se puede esquivar ASLR en configuración de producción.

¿Qué es Potassium?

Una variante de la botnet Mirai, señalada desde marzo de 2026, que se ha intentado desplegar con PHP2Shell para lanzar ataques de denegación de servicio. Hasta ahora, esos intentos no han tenido éxito.

¿Cuántos servidores siguen sin parchear?

Más de 34,4 millones de servicios PHP seguían vulnerables a 23 de octubre de 2026, según Censys.

¿Basta con tener Cloudflare?

No. Es una capa de protección y no sustituye a actualizar PHP, como el propio Cloudflare ha dicho.

Conclusión

La situación es de calma tensa. Hay intentos masivos, ningún compromiso confirmado y un camino técnico que ya se ha demostrado: se ha esquivado ASLR en laboratorio y circulan herramientas de ataque. Nadie sabe cuánto tardarán los atacantes en perfeccionar sus herramientas, y los servidores sin actualizar no tienen otra defensa que la que hayas puesto tú.

Fuentes: The Hacker News (21, 22 y 23 de octubre de 2026), Cloudflare, Sophos, Arctic Wolf, VulnCheck, SOCRadar, Hunt.io, Previdian, Wordfence, Cisco Talos, Amazon, Sysdig, Censys y Dataminr, según los recoge la prensa especializada. Información a 23 de octubre de 2026. Este artículo es informativo y no sustituye a un profesional.