Si utilizas PHP en cualquier parte de tu pila y no has actualizado, deja de de leer esto y actualízala a una versión parcheada. Encontrarás más información al respecto en nuestro blog de avisos, y echa un vistazo a php2shell.aikido.io para comprobar si tu servicio podría ser vulnerable.
La semana pasada se vivieron unos días que, posiblemente, hayan sido los más importantes de todos los tiempos en materia de ciberseguridad, y no creo que esté exagerando. La avalancha comenzó con las vulnerabilidades, pero la noticia más destacada fue PHP2shell.
Muchos sitios web dejaron de estar disponibles para realizar actualizaciones, lo que nos sorprendió a muchos al ver la gran cantidad de sitios que aún funcionan con PHP (¡el 70 % según algunas fuentes!). El tema saltó a la palestra.
PHP2Shell permaneció oculta en el entorno de ejecución de PHP durante unos veinte años, pero este año varios grupos descubrieron la misma vulnerabilidad en un breve periodo de tiempo. Este mes, los atacantes intentaban aprovecharla días antes incluso de que PHP hubiera anunciado que se iba a publicar una corrección. La inteligencia artificial ha cambiado las reglas del juego, y cualquier filtración sobre una vulnerabilidad o sus parches es más peligrosa que antes. Esto significa que la próxima gran vulnerabilidad podría aparecer con menos antelación, y los equipos encargados de gestionarla deben estar preparados para reaccionar y aplicar los parches rápidamente.
Cómo se desarrollaron las revelaciones sobre PHP2Shell
Un resumen de la cronología de las revelaciones sobre PHP2Shell, para poner en contexto la situación.
El problema de falta de memoria que subyace a la primera de las dos vulnerabilidades PHP2Shell ya había salido a la luz en una auditoría realizada en 2024 por OSTIF y Quarkslab, pero no se corrigió porque nadie había demostrado que pudiera ser explotado. Se volvió a detectar en 2026, cuando Calif y Wiz descubrieron los fallos de forma independiente con pruebas de explotación (Calif lo notificó como parte de la iniciativa «Patch the Planet» de OpenAI). El equipo de seguridad de PHP confirmó los informes y dedicó las semanas siguientes a desarrollar correcciones para todas las ramas compatibles. Los detalles se mantuvieron bajo embargo a la espera de una publicación coordinada.
PHP tenía previsto inicialmente publicar las correcciones el 22 de octubre. Cuando se filtraron los identificadores CVE, CVE-2026-109618 y CVE-2026-109619, el 20 de octubre, PHP publicó su preanuncio a las 19:30 UTC de esa misma tarde y adelantó el lanzamiento un día, a las 14:00 UTC del 21 de octubre.
El Aikido formaba parte de un grupo de organizaciones a las que se les facilitó información anticipada, y el periodo previo al lanzamiento del parche fue caótico. Cada nueva filtración aumentaba la probabilidad de que los atacantes actuaran antes de que se publicaran los parches, y los miembros del grupo debatieron si compartir las medidas de mitigación antes de tiempo o ajustar sus propios plazos. Creemos que la divulgación coordinada merece nuestro apoyo, por lo que nuestras imágenes parcheadas se publicaron tras el anuncio de PHP del 21 de octubre.
En los días previos al lanzamiento y durante las horas posteriores, una gran parte de Internet entró en modo de mantenimiento mientras se apresuraban a aplicar los parches. Censys lleva realizando un seguimiento de la vulnerabilidad PHP2Shell desde el 21 de octubre. A fecha de 27 de octubre, unos 11,2 millones de servicios PHP habían actualizado a una versión corregida, lo que supone aproximadamente una cuarta parte de los que indicaban una versión, mientras que 32,5 millones seguían ejecutando una versión afectada. Más de 60 millones de servicios PHP no indican ninguna versión, por lo que es probable que la exposición real sea mayor. Sigue las cifras en tiempo real en la página de Censys dedicada a PHP2Shell.
Los intentos de explotación están ahora muy extendidos, y también se han producido algunos casos en los que se ha tenido éxito. En una prueba pública, el investigador de seguridad James Pavur configuró un servidor PHP 8.4.26 sin parches con unos 2.000 dólares en bitcoins como premio, y un participante logró acceder al sistema unas tres horas después de que el servidor comenzara a servir una página que ejecutaba PHP.
El análisis a posteriori de la Fundación PHP y el informe de Calif recogen la cronología completa, desde el descubrimiento hasta la publicación del parche.
La IA está detectando más vulnerabilidades con mayor rapidez
PHP ha sido la base de gran parte de la web durante tres décadas, por lo que quienes lo utilizan daban por hecho que ya se habían detectado todos sus fallos graves. «No sabemos de dónde va a surgir el próximo CVE. Y podría estar en un programa que a nadie se le hubiera ocurrido crear en los últimos 20 años», afirma Benji Kalman, vicepresidente sénior de Ingeniería de Aikido.
La vulnerabilidad PHP2shell también llevaba ya un par de décadas ahí, pero como un fantasma sin descubrir. El hecho de que Calif y Wiz la descubrieran con solo unas semanas de diferencia nos recuerda que la IA va a detectarlas cada vez más rápido.
Probamos a ver con qué rapidez podíamos detectar nosotros mismos estas vulnerabilidades de PHP. Tras la divulgación, dirigimos la herramienta « análisis de código con IA » de Aikido hacia PHP, y esta volvió a detectar PHP2Shell en unas pocas horas. La hemos estado ejecutando sobre bibliotecas de código abierto, pero aún no habíamos probado los lenguajes en los que se basan.
Investigar más sobre estas vulnerabilidades para sacarlas a la luz podría considerarse arriesgado, si ello llama la atención sobre una vulnerabilidad que nadie conocía desde hacía décadas. Pero si la herramienta de un defensor puede encontrar un fallo como este en una tarde, las herramientas de los atacantes no tardarán en hacerlo. Así que se trata de una especie de dilema del prisionero: los atacantes empezarán a buscar vulnerabilidades en todo lo que puedan encontrar y sus herramientas seguirán mejorando, por lo que los defensores no pueden quedarse a la zaga. Los hackers éticos también tendrán que seguir buscando vulnerabilidades en bibliotecas y lenguajes de código abierto. Los equipos de seguridad deberían prepararse para que el próximo parche urgente se publique de la noche a la mañana.
La divulgación coordinada tiene que acelerarse
Con la IA, los atacantes pueden empezar a actuar a partir de muy poca información, y eso es lo que hace que una revelación de esta gravedad sea difícil de gestionar. «Basta con una simple pista. Basta con decir que hay una vulnerabilidad en PHP. Ya puedo oír cómo se ponen en marcha todas las GPU del centro de datos», afirma Charlie Eriksen, investigador jefe de malware de Aikido. «Nos encontramos en una situación en la que el tiempo que transcurre entre el descubrimiento y la explotación se está reduciendo considerablemente, y hay muchísimas personas diferentes capaces de descubrir estas vulnerabilidades con gran rapidez».
La rapidez hace que la divulgación coordinada sea más valiosa que nunca, pero también más difícil de llevar a cabo correctamente. Las advertencias y los avisos previos, aunque ayudan a los usuarios a prepararse para aplicar parches o desconectar los servicios, también indican a los atacantes dónde deben buscar. «La advertencia también puede causarte daños. Es una dinámica realmente complicada», afirma Charlie.
En el caso de PHP2Shell, es posible que el anuncio previo se programara con demasiada antelación respecto al lanzamiento inicial. El equipo de PHP adelantó el lanzamiento un día en cuanto empezaron a aparecer los identificadores CVE y las pruebas de concepto (POC). Sin embargo, Amazon afirma que los primeros intentos de explotación comenzaron el sábado 17 de octubre, tres días antes del anuncio previo de PHP, que tuvo lugar el 20 de octubre (no podemos especular sobre los motivos).
Una vez que un parche se hace público, los atacantes disponen de muchos más recursos con los que trabajar que antes. Partiendo de los parches, Charlie calcula que alguien con los conocimientos necesarios podría crear un exploit con un modelo de lenguaje grande (LLM) en unas pocas horas. En el caso de PHP2Shell, Trail of Bits creó un exploit funcional en un día utilizando Codex.
En el caso de las vulnerabilidades que requieren una divulgación coordinada, el proceso debe ser más rápido y riguroso. Los embargos deben ser más cortos, y los detalles técnicos deben llegar al menor número posible de personas, ya que cada día adicional y cada parte implicada aumentan el riesgo de que se produzca una filtración.
Qué suponen los embargos más cortos para la mayoría
Los embargos más cortos y estrictos ayudan a los equipos al reducir el margen de tiempo para que se produzcan filtraciones y ataques prematuros, pero también dejan menos tiempo para que todos los que intervienen posteriormente puedan prepararse.
La corrección oficial y la que un equipo puede instalar realmente no siempre están disponibles al mismo tiempo. La tarde en que PHP publicó su parche, las actualizaciones de SUSE y Fedora aún se encontraban en fase de pruebas, y la versión «unstable» de Debian seguía distribuyendo la versión 8.4.26, que presentaba la vulnerabilidad. En el alojamiento compartido, los propietarios de los sitios web no pueden aplicar el parche a PHP por sí mismos, por lo que deben esperar a que lo haga su proveedor.
Las capas de protección también dependen de que se avise con antelación. Los proveedores de CDN y WAF que se enteran con antelación pueden implementar reglas de bloqueo desde el primer día, tal y como hizo Cloudflare al ampliar sus reglas de WAF a todos los planes, incluido el gratuito, antes de que se publicara el parche. Cuantos menos proveedores estén informados, más tarde se establece la red de seguridad. Las advertencias también pueden ser más breves y vagas para frenar a los hackers, lo que deja a los equipos menos tiempo para planificar el mantenimiento.
Si los plazos de aviso tienen que acortarse, los equipos de seguridad deben asegurarse de poder recibir las alertas a tiempo y estar preparados para aplicar los parches con rapidez, o bien disponer de herramientas de seguridad que lo hagan automáticamente.
Qué pueden hacer los equipos antes del próximo «internetbreaks2shell»
Lo primero son los fundamentos. Empieza por saber qué es lo que ejecutas. «Lo primero que, obviamente, tienes que saber es: ¿cuál es mi exposición potencial? Haz un inventario de todo», dice Charlie. Ese inventario debe abarcar todos los entornos de ejecución y dependencias que utilices, incluidas aquellas que no hayas instalado tú mismo. PHP2Shell es un buen ejemplo, ya que PHP suele aparecer en imágenes base de contenedores, imágenes de CI, paneles de alojamiento y software de proveedores.
A continuación, elige con cuidado tus fuentes de información. En las primeras horas tras un incidente, las fuentes más útiles mantienen su información actualizada a medida que la situación evoluciona, y van más allá de la mera descripción del problema para ofrecerte medidas de mitigación y, sobre todo, soluciones que puedas aplicar.
Consulta con tus proveedores de seguridad actuales o potenciales para ver cómo te ayudan y cómo se comunican este tipo de cuestiones:
- ¿Actualizan sus recomendaciones a medida que avanza la explotación?
- ¿Envían alertas en tiempo real sobre incidentes para que la persona adecuada se entere sin tener que estar revisando Twitter constantemente?
- ¿Te informan solo de los incidentes más importantes o te inundan con un montón de ruido irrelevante sobre vulnerabilidades de la IA?
- ¿Explican cómo reducir la exposición mientras se espera a que salga un parche?
- ¿Te dan las soluciones?
Durante el incidente de PHP2Shell, actualizamos nuestro aviso a medida que se desarrollaba el incidente y enviamos notificaciones por correo electrónico en tiempo real. Publicamos una herramienta de comprobación gratuita en php2shell.aikido.io para que los propietarios de sitios web pudieran comprobar si sus sitios presentaban el comportamiento de agotamiento de memoria de PHP2Shell.
También distribuimos correcciones retrocompatibles para PHP2Shell a través de Aikido Images. Las imágenes gratuitas disponibles en el ECR público de Aikido abarcan PHP 5.5, 5.6, la serie 7.x y las versiones 8.2 a 8.5, y se publicaron poco después del lanzamiento oficial de PHP. Los equipos podían (¡y aún pueden!) obtener una imagen corregida sin tener que realizar ellos mismos una actualización importante de PHP.
«Queremos asegurarnos de que estamos aplicando parches «in situ», como solemos decir. Eso significa que no os estamos pidiendo que cambiéis a un sistema operativo totalmente diferente ni nada por el estilo», explica Benji. «Es tan sencillo como descargar la imagen del ECR y sustituirla en vuestro Dockerfile».
No recomendamos el comportamiento tipo «bot» de Renovate, en el que todo se actualiza automáticamente a las últimas versiones. Esto provoca fallos constantes en la aplicación, por lo que, al final, los equipos acaban desactivándolo. Es necesario proteger a los equipos sin introducir vulnerabilidades, así que mantén la configuración actual mediante archivos de bloqueo y actualiza únicamente cuando surjan CVE.
«La red es inmensa e infinita»
Aunque PHP2Shell fue una experiencia estresante y algo caótica, los defensores aún pueden salir airosos.
«Creo que, por el momento, los defensores siguen teniendo ventaja. Aunque, claro está, hay que esforzarse», afirmó Willem Debare, director general de Aikido, la semana pasada al referirse a las vulnerabilidades.
Si empiezas a desarrollar resiliencia ahora, serás uno de los que sigan en pie cuando el polvo y los búferes de código se hayan asentado.
P.D.: Parte de la web no sobrevivirá a esto. Gran parte de ella sigue funcionando con versiones antiguas de PHP que ya no reciben mantenimiento. La revista The Atlantic advierte de que muchas páginas quedarán fuera de línea o serán hackeadas, y es posible que algunas nunca vuelvan. Descansa en paz, preciosa Internet de principios de la década de 2000.
