PHP2Shell: la vulnerabilidad que la IA encontró y que puso a Internet contra reloj
24 de octubre de 2026 | Hack the Hacker
Durante días, investigadores de seguridad, empresas tecnológicas y administradores de sistemas trabajaron para contener dos fallos críticos en PHP. La inteligencia artificial había ayudado a descubrirlos, pero había un problema: alguien ya estaba intentando explotarlos antes de que los parches fueran públicos.
El martes 20 de octubre, miles de personas en Irlanda intentaban acceder a Revolut sin éxito. Algunas no podían iniciar sesión; otras tenían problemas para realizar transferencias, retirar efectivo o pagar con tarjeta. En Reino Unido, clientes de Lloyds y HSBC también comunicaban dificultades. Incluso algunos servicios utilizados por los tribunales británicos dejaron de funcionar.
La explicación llegó desde Google. Un incidente eléctrico había afectado a parte de su infraestructura de Google Cloud en Londres. Revolut confirmó que sus servicios estaban sufriendo interrupciones, aunque aseguró que el dinero y los datos de sus clientes seguían a salvo.
La avería fue noticia durante buena parte del día. Sin embargo, mientras se recuperaban los servicios, en el sector de la ciberseguridad se estaba preparando una emergencia de naturaleza muy diferente.
Al día siguiente, el 21 de octubre, los responsables de PHP publicaron actualizaciones extraordinarias para corregir dos vulnerabilidades críticas en el propio lenguaje de programación. Los fallos se conocieron como PHP2Shell.
La proximidad de ambos incidentes alimentó las especulaciones. ¿Se trataba realmente de un fallo eléctrico? ¿Podía haber alguna conexión con la vulnerabilidad de PHP?
Por ahora no hay pruebas que permitan relacionarlos.
The Irish Times informó de que la caída de Revolut estuvo vinculada al incidente de Google Cloud, mientras que los problemas relacionados con PHP2Shell provocaron su propia respuesta de emergencia, incluida la desconexión preventiva de determinados servicios web.
Lo llamativo es que, en apenas 48 horas, quedaron expuestas dos formas muy distintas en las que Internet puede dejar de funcionar. Una, por un problema físico en un centro de datos. La otra, por errores de software que podían haber permanecido ocultos durante años.
Dos fallos en una tecnología que lleva décadas en Internet
PHP no suele aparecer en las noticias fuera del mundo tecnológico. Sin embargo, es una pieza fundamental de una enorme cantidad de páginas web, tiendas online, aplicaciones y sistemas empresariales. WordPress, por ejemplo, utiliza PHP para ejecutar buena parte de sus funciones.
Los fallos descubiertos, identificados como CVE-2026-109618 y CVE-2026-109619, afectan a la forma en que PHP maneja determinadas operaciones de memoria.
Ambos recibieron una puntuación de gravedad de 9,2 sobre 10. En determinadas condiciones, un atacante podía enviar una solicitud especialmente preparada a un servidor vulnerable y conseguir que ejecutara instrucciones que no formaban parte del funcionamiento normal de la aplicación.
Es lo que se conoce como ejecución remota de código, o RCE.
Para entender su importancia, pensemos en una web corporativa. Un visitante puede completar un formulario, buscar información o descargar documentos. El servidor recibe esas solicitudes y ejecuta determinadas instrucciones. Con una vulnerabilidad de este tipo, una petición manipulada podría conseguir que el servidor hiciera algo completamente distinto.
No hablamos necesariamente de robar una contraseña ni de convencer a un empleado para que abra un archivo malicioso. El problema está en el software que procesa las solicitudes.
Según el
análisis técnico de Datadog Security Labs, los errores se producen antes de que se ejecute el código habitual de la aplicación, por lo que sus mecanismos de autenticación no bastan para bloquearlos.
Esto no significa que todas las páginas web desarrolladas con PHP hayan sido hackeadas. La exposición depende de la versión utilizada y de las condiciones del sistema. Pero las consecuencias potenciales son lo suficientemente graves como para justificar una intervención urgente.
Y había algo que preocupaba especialmente a los investigadores: la vulnerabilidad ya estaba llamando la atención de posibles atacantes.
El 17 de octubre alguien ya estaba intentando aprovechar PHP2Shell
El dato más inquietante apareció en un informe de Amazon Threat Intelligence.
El equipo había identificado un intento de explotación el 17 de octubre, cuatro días antes de la publicación oficial de las vulnerabilidades. La actividad quedó registrada en MadPot, su red de sistemas preparados para detectar y estudiar comportamientos maliciosos.
La conexión procedía de una dirección asociada a un servicio comercial de anonimización. Amazon no pudo determinar cómo había obtenido aquella persona información sobre la vulnerabilidad ni si el intento habría funcionado en un entorno real.
Tampoco sabemos si se trataba de un ciberdelincuente que había descubierto el fallo por sus propios medios o de alguien que había conseguido información de otra fuente.
Pero el intento existió.
En la madrugada del 21 de octubre, antes de que se levantara el embargo informativo, Amazon también observó nuevas pruebas de explotación. Después de hacerse públicos los detalles, la actividad aumentó.
La compañía documentó estos acontecimientos en su
informe sobre los ataques detectados antes de la divulgación de PHP2Shell.
En seguridad informática, una vulnerabilidad desconocida para el fabricante y para quienes administran los sistemas puede proporcionar una ventaja considerable a quien consigue explotarla.
Por eso, cuando los investigadores descubren un problema crítico, normalmente no publican inmediatamente todos sus detalles. Primero avisan a los responsables del software, colaboran en las correcciones y coordinan una fecha de divulgación.
Con PHP2Shell, ese proceso llevaba semanas en marcha.
Sin embargo, el informe de Amazon demuestra que la fecha de publicación de un parche no marca necesariamente el inicio de los intentos de ataque.
Y esa diferencia importa. Una empresa que empezó a revisar sus registros el 21 de octubre podría haber pasado por alto actividad ocurrida varios días antes.
La inteligencia artificial y una investigación que duró meses
Buena parte de la atención sobre PHP2Shell se concentró en cómo fueron descubiertos los fallos.
OpenAI explicó que la empresa de investigación Calif había utilizado su modelo GPT-5.6 Sol para identificar una vulnerabilidad dentro del proyecto
Patch the Planet. Por separado, Wiz encontró y comunicó los dos problemas. Después comenzó un trabajo coordinado con los responsables de PHP y otras organizaciones para preparar las correcciones.
La investigación no consistió en pedirle a un chatbot que buscara errores y aceptar su respuesta.
Hubo que comprobar los resultados, reproducir los fallos, entender por qué ocurrían y desarrollar cambios que corrigieran el problema sin romper aplicaciones que llevan años funcionando.
La colaboración incluyó a empresas como Cloudflare, que preparó reglas de protección antes de la divulgación pública.
OpenAI publicó los detalles de esta coordinación el 21 de octubre.
En Hack the Hacker ya habíamos analizado
el impacto de la inteligencia artificial en la ciberseguridad. Este caso permite verlo desde una perspectiva más concreta.
PHP lleva más de treinta años en desarrollo. Su código ha sido revisado, modificado y probado por innumerables profesionales. Aun así, determinadas combinaciones de errores pueden pasar inadvertidas o resultar especialmente difíciles de investigar.
La IA puede ayudar a examinar grandes cantidades de código, plantear hipótesis y detectar comportamientos que merecen una revisión más profunda. No sustituye el criterio técnico, pero permite acelerar parte del trabajo.
Para quienes defienden los sistemas, esto supone una oportunidad enorme.
El problema es que las herramientas de inteligencia artificial no preguntan por las intenciones de quien las utiliza.
Cuando la ventaja tecnológica cambia de manos
Hasta hace relativamente poco, descubrir una vulnerabilidad compleja en un proyecto como PHP exigía conocimientos especializados, experiencia en análisis de memoria y mucho tiempo de investigación.
Esas habilidades siguen siendo necesarias, pero la inteligencia artificial está cambiando el trabajo.
La misma capacidad que ayuda a un investigador a localizar un fallo puede ser utilizada por alguien que no quiera comunicarlo.
No es algo completamente nuevo. Los ciberdelincuentes ya emplean automatización desde hace años y, como hemos explicado al analizar
el uso de inteligencia artificial para cometer fraudes, también están incorporando estas herramientas a otras actividades.
Lo que cambia ahora es el nivel de complejidad de las tareas que pueden automatizarse.
Hay una diferencia importante entre generar un correo de phishing convincente y encontrar un error de memoria capaz de comprometer un servidor. Este segundo escenario requiere muchas más capacidades técnicas, pero PHP2Shell demuestra que la IA ya puede contribuir a investigaciones de ese nivel.
Y los tiempos favorecen a quien actúa primero.
Un administrador necesita identificar todos los servidores afectados, comprobar compatibilidades, realizar copias de seguridad, aprobar cambios, instalar parches y verificar que los servicios funcionan correctamente.
Para un atacante, el objetivo puede ser mucho más sencillo: encontrar un servidor vulnerable antes de que su propietario tenga oportunidad de actualizarlo.
No todos los intentos tendrán éxito. Las defensas y las configuraciones importan. Sin embargo, el margen de reacción puede reducirse considerablemente cuando los fallos se descubren y se investigan con mayor rapidez.
Qué deberían revisar las empresas
Lo primero es comprobar si sus servidores utilizan una versión vulnerable de PHP. No basta con mirar la versión de WordPress o confirmar que los plugins están actualizados.
Las correcciones de PHP2Shell se publicaron en las siguientes versiones:
| Rama de PHP |
Versión corregida |
| 8.2 |
8.2.35 |
| 8.3 |
8.3.36 |
| 8.4 |
8.4.27 |
| 8.5 |
8.5.12 |
Las instalaciones que utilizan versiones antiguas requieren una revisión específica. Algunas distribuciones ofrecen actualizaciones de seguridad propias para versiones anteriores, mientras que otras instalaciones necesitarán migrar a una rama mantenida.
Para quien administra su propia web, la actualización debe planificarse comprobando la compatibilidad de la aplicación. Y si la página está gestionada por una empresa externa, conviene pedir una confirmación por escrito de que se ha revisado y corregido la exposición.
Los proveedores de seguridad han publicado medidas temporales. Por ejemplo,
AWS explica cómo reducir determinados riesgos mediante su firewall de aplicaciones web. Pero advierte que ninguna de esas medidas sustituye la instalación del parche.
También es importante revisar los registros del servidor desde el 17 de octubre, especialmente si la web estaba expuesta a Internet y utilizaba una versión afectada.
Una actualización puede cerrar la vulnerabilidad, pero no deshacer un posible ataque anterior.
Si aparecen indicios de actividad sospechosa, corresponde investigar posibles cambios no autorizados, procesos inesperados o accesos a información sensible. Para complementar esa investigación, puede ser útil
comprobar si los datos de la empresa aparecen en filtraciones conocidas, aunque la ausencia de resultados no demuestra que un servidor esté limpio.
En muchas pequeñas empresas, el verdadero obstáculo aparece incluso antes: nadie sabe exactamente qué versión de PHP utiliza la web, quién administra el hosting o cuándo fue la última actualización importante.
Es un problema frecuente, relacionado con
errores de ciberseguridad que pueden evitarse con una gestión más cuidadosa.
Durante esta misma semana se publicaron además nuevas advertencias sobre otras condiciones vulnerables en PHP, lo que refuerza la necesidad de seguir los avisos oficiales y no limitar la revisión a los primeros parches.
La próxima vulnerabilidad puede descubrirse en silencio
Hay una parte de esta historia que resulta alentadora.
Investigadores humanos, modelos avanzados de IA, empresas de seguridad y responsables de software consiguieron coordinarse para corregir dos fallos de enorme alcance. Las protecciones comenzaron a prepararse antes de la divulgación pública y muchas organizaciones tuvieron la oportunidad de actuar.
Eso es exactamente lo que debería ocurrir cuando se descubre una vulnerabilidad crítica.
Pero el incidente también dejó una advertencia.
Los investigadores no fueron los únicos que mostraron interés por PHP2Shell. Al menos desde el 17 de octubre ya existían intentos de explotación, y todavía no sabemos cómo obtuvieron la información quienes realizaron aquellas pruebas.
No se puede afirmar que los atacantes hubieran descubierto los fallos antes que los investigadores. La investigación defensiva llevaba meses en marcha. Lo que sabemos es que hubo actividad sospechosa antes de que el público conociera el problema y antes de que estuvieran disponibles los parches.
Esta vez, la IA ayudó a encontrar las vulnerabilidades y a preparar una respuesta.
Ahora imaginemos otro escenario.
Un grupo criminal utiliza modelos avanzados para investigar software ampliamente utilizado. Encuentra un fallo crítico, comprueba que puede explotarlo y decide no comunicarlo.
No hay aviso de seguridad. No hay comunicado del fabricante. Los administradores siguen trabajando normalmente porque, desde su perspectiva, sus sistemas están actualizados.
El atacante dispone de tiempo para buscar objetivos y actuar.
Solo cuando comienzan a aparecer incidentes alguien empieza a investigar qué está ocurriendo.
No sabemos cuándo se producirá una situación así, ni hasta qué punto la inteligencia artificial facilitará ese proceso. Pero la posibilidad resulta cada vez más relevante.
Durante años hemos tratado de reducir el tiempo que transcurre entre la publicación de una vulnerabilidad y la instalación del parche.
Tal vez ahora debamos prestar tanta atención a otro período mucho más difícil de medir: el que transcurre entre el momento en que alguien descubre un fallo y el momento en que el resto del mundo se entera.
PHP2Shell dejó una lección importante: la inteligencia artificial puede ayudarnos a descubrir las amenazas antes de que causen daños. Pero también puede acortar la ventaja de quienes intentan defenderse.
Esta vez hubo investigadores dispuestos a comunicar lo que habían encontrado.
La próxima vez, ¿y si quien lo descubre primero decide guardar silencio?
Fuentes y documentación
