El fallo de PHP desencadenó una emergencia mundial para "desconectar" los cables de internet; no esperen que la IA salve internet
Internet está viviendo 48 horas aterradoras.
Anoche, varios sitios web gubernamentales de países europeos dejaron de funcionar simultáneamente. La Agencia Finlandesa de Transportes y Comunicaciones suspendió algunos de sus servicios en línea; el sistema de identidad electrónica DigiD de los Países Bajos, la plataforma de servicios personales del gobierno neerlandés MijnOverheid y todos los portales gubernamentales suspendieron sus servicios; incluso el sitio web del Centro Nacional de Ciberseguridad de los Países Bajos fue cerrado temporalmente…
En Japón, varias plataformas comunitarias de internet muy conocidas, entre ellas pixiv, la mayor comunidad japonesa para subir ilustraciones, cómics y novelas, Niconico, un sitio web de larga trayectoria para compartir vídeos, y BOOTH, la plataforma de comercio electrónico para creadores de pixiv, han anunciado tareas de mantenimiento de emergencia.
Desliza hacia la izquierda para ver más contenido.
Incluso Sushiro anunció en su plataforma oficial que su miniprograma quedaría suspendido temporalmente hoy debido a tareas de mantenimiento y actualización del sistema.
Lo que ha puesto en alerta máxima a tantas organizaciones son dos nuevos números de vulnerabilidad publicados: CVE-2026-109618 y CVE-2026-109619.
La comunidad de seguridad les ha dado un apodo directo: PHP2Shell. Esto significa que un atacante puede obtener acceso a la línea de comandos de su servidor simplemente enviando una solicitud a su sitio web, lo que le otorga control total.
El 21 de octubre, el equipo oficial de PHP publicó las actualizaciones de emergencia 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y confirmó que ambas vulnerabilidades tienen una puntuación CVSS de 9,2 sobre 10 y pueden ser explotadas de forma remota sin nombre de usuario ni contraseña.
Además, con Apache, el software de servidor web de código abierto más utilizado en el mundo, y PHP, que es el método de implementación más común, el ataque se activa incluso antes de que comience a ejecutarse el código del propio sitio web.
Resultó ser cierto el rumor sobre una "laguna legal para obtener la puntuación perfecta".
La tormenta comenzó de forma dramática.
Según el plan original, los detalles de la vulnerabilidad debían divulgarse de forma coordinada el 22 de octubre. Sin embargo, en la tarde del 20 de octubre, apareció una publicación en Hacker News que afirmaba que existían dos vulnerabilidades de ejecución remota de código en PHP con una puntuación de 10,0.
Aunque la publicación se eliminó rápidamente, las capturas de pantalla ya habían circulado. En cuestión de horas, la empresa de seguridad WatchTowr confirmó que la filtración era auténtica, que la vulnerabilidad era real y que ya habían reproducido una de las vulnerabilidades.
Esa misma tarde, el equipo de seguridad de PHP emitió una alerta de emergencia, adelantando la fecha de lanzamiento 24 horas y, de forma inusual, añadiendo la siguiente declaración: "Si se hacen públicos los detalles de la vulnerabilidad o aparecen pruebas de su explotación en la práctica, nos reservamos el derecho de adelantar aún más el lanzamiento".
El caos continuó. Esa misma noche, Calif, la empresa de seguridad que descubrió la vulnerabilidad, publicó por error un vídeo de demostración que mostraba su código de ataque funcionando correctamente en varios objetivos reales. Las copias del vídeo se viralizaron rápidamente en las redes sociales.
Desplázate hacia arriba y hacia abajo para ver más contenido.
A la mañana siguiente, Chainguard, la editorial que recibió el parche con antelación, rompió unilateralmente el acuerdo de confidencialidad y publicó la imagen con la corrección antes de tiempo. El parche en sí es un "mapa de vulnerabilidades". Los atacantes pueden deducir la ubicación y el principio de la vulnerabilidad comparando los archivos binarios antiguos y nuevos y viendo qué código se modificó.
En su revisión posterior, la Fundación PHP expresó su gran indignación por la forma en que se hizo pública la vulnerabilidad.
Cuando se descubre una vulnerabilidad de esta magnitud, el estándar de la industria es que investigadores, proveedores y editores acuerden un plazo unificado, y nadie puede revelar detalles con antelación. El objetivo es garantizar que los parches y la información sobre la vulnerabilidad lleguen al público simultáneamente: los usuarios pueden instalar los parches inmediatamente en cuanto tengan conocimiento de la vulnerabilidad, maximizando así el tiempo de acción para los responsables de la seguridad.
El partido en cuestión es la base de internet.
Para comprender por qué este incidente fue tan terrible, primero debemos entender qué es PHP.
Es la "cocina" de internet. Iniciamos sesión, buscamos, hacemos pedidos y comentamos en la interfaz, mientras que PHP procesa las solicitudes, lee y escribe en las bases de datos y envía los resultados al navegador en el servidor. WordPress, Drupal, Joomla, Magento y MediaWiki —la empresa detrás de Wikipedia— funcionan con PHP.
Según datos de W3Techs, entre los sitios web que pueden identificar tecnologías del lado del servidor, el 69,3% utiliza PHP; JavaScript ocupa el segundo lugar con solo un 8,1%.
También buscamos en todos los registros web que contenían WordPress en FOFA, un motor de búsqueda de mapeo de espacios web desarrollado por White Hat Hub. Podemos ver por qué regiones como Europa, América y Japón respondieron primero, ya que estas regiones tienen la mayor cantidad de entradas de activos que coinciden con las reglas de huella digital de WordPress.
Anteriormente, la mayoría de las noticias sobre "sitios web PHP hackeados" se centraban en un plugin o aplicación específica. Esta vez, la vulnerabilidad reside en el núcleo del intérprete de PHP, sin relación con las aplicaciones de nivel superior. En palabras de Wiz, uno de los descubridores: " Incluso si tu sitio web solo ejecuta un sencillo programa 'Hola Mundo', sigue estando afectado".
Los principios técnicos que subyacen a ambas vulnerabilidades no son nuevos; lo sorprendente es que se ha demostrado que "realmente funcionan".
CVE-2026-109618: PHP maneja el error "sin memoria" deteniéndose abruptamente (longjmp).
Si se aplican los frenos en un momento crítico, los datos internos solo se inicializan parcialmente. Sin embargo, el proceso de limpieza posterior tratará estos datos incompletos como datos normales, lo que permite a los atacantes hacer que el servidor ejecute su propio código.
La verificación oficial confirma que, con la configuración predeterminada, mediante la creación de solicitudes multipart especialmente diseñadas para agotar la memoria, se puede completar un ataque antes de que se ejecute el código de la aplicación.
CVE-2026-109619: Algunos estados globales no se borraron después de que se procesó una solicitud y se liberó la memoria.
Cuando el mismo proceso de trabajo gestiona la siguiente solicitud, puede reutilizar la memoria que ya ha caducado. Este comportamiento clásico de "uso después de su liberación" puede integrarse cuidadosamente en la ejecución del código y también puede filtrar contraseñas, tokens y claves API de otros usuarios almacenadas en la memoria.
Cabe destacar que la función session.upload_progress, que es una de las vías de explotación confirmadas, está habilitada por defecto, y la aplicación ni siquiera necesita llamar a session_start().
Actualmente, el parche solo cubre cuatro ramas de PHP: de la 8.2 a la 8.5. Sin embargo, los datos de W3Techs del mismo día muestran que el 27,0 % de todos los sitios web PHP todavía utilizan PHP 7.x y el 7,7 % utilizan PHP 5.x. Estas versiones, que hace tiempo que dejaron de recibir soporte, no pueden recibir parches oficiales.
El experto en informática forense Hal Pomeranz señaló: "Hay demasiadas instalaciones integradas que nunca se actualizarán, demasiadas aplicaciones olvidadas y sin mantenimiento. Esta vez, la cola larga será muy larga".
¿La encontró la IA? ¿En una semana o en meses?
Una vez que se hizo pública la vulnerabilidad, OpenAI publicó un artículo en el que enumeraba el incidente como uno de sus logros en seguridad de IA: investigadores de California utilizaron GPT-5.6 Sol para encontrar la falla crítica, y varios equipos colaboraron para completar la verificación y la respuesta.
Quienes estamos familiarizados con las tácticas de marketing de las empresas de IA podríamos preguntarnos inconscientemente: ¿El modelo realmente descubrió una vulnerabilidad, o es solo otro ejemplo de investigación humana etiquetada como IA?
El día de la revelación, Calif "reivindicó" públicamente a Ryan Austin en X, afirmando que fue la primera persona en descubrir y crear código de ataque utilizable, citando como prueba un tuit que publicó el 5 de agosto que contenía el hash del descubrimiento.
El informe técnico oficial redactado por la persona que descubrió la vulnerabilidad es también una de las fuentes de información primarias más importantes sobre este incidente.
En su artículo, Ryan subraya que el descubrimiento inicial no se basó en ningún marco de herramientas o modelo especial que no estuviera disponible públicamente. Su conocimiento del historial del objetivo determinó el rumbo de la investigación; las simples palabras clave no fueron suficientes para que el modelo descubriera todas las vulnerabilidades.
Su cadena de descubrimientos se remonta a la primera vulnerabilidad de límite de memoria de PHP encontrada por Stefan Esser en 2004, un informe de error que pasó desapercibido en 2020 y una auditoría en 2024 que no logró demostrar la posibilidad de explotación.
Esto implica que la IA solo reduce el tiempo de verificación, mientras que el sentido de la orientación sigue proviniendo de los humanos.
La revisión de la Fundación PHP también confirmó que el equipo OpenAI informó de forma independiente sobre la misma causa raíz el 11 de agosto, y posteriormente añadió detalles sobre la ruta del ataque. Su informe detalló cómo se descubrió y solucionó la vulnerabilidad, y reveló la historia completa de cómo se descontroló.
En 2024, PHP se sometió a su primera auditoría de seguridad externa en muchos años, y un desarrollador principal detectó una posible vulnerabilidad en el manejo del agotamiento de la memoria mientras solucionaba los problemas descubiertos durante la auditoría.
En aquel momento, nadie pudo demostrar que realmente se pudiera explotar la vulnerabilidad, y las distintas soluciones tenían sus propios inconvenientes, pudiendo provocar fallos de compatibilidad o introducir nuevos riesgos de denegación de servicio. El equipo no logró tomar una decisión y el problema quedó archivado. La Fundación PHP lo calificó posteriormente como un «fallo estructural».
En el verano de 2026, tres equipos, equipados con herramientas de IA, descubrieron este problema casi simultáneamente:
- El 1 de agosto, Ryan Austin, investigador de la empresa de seguridad Calif, descubrió la primera vulnerabilidad con la ayuda de GPT-5.6 Sol de OpenAI , y la comunicó al equipo de PHP el 11 de agosto; OpenAI informó de forma independiente sobre la misma causa raíz el mismo día.
- El 19 de agosto, Wiz, la herramienta de Google, utilizó su propia plataforma, Wiz Atlas, junto con Gemini 4 Argon y GPT-5.6 Sol, para descubrir la vulnerabilidad de forma independiente. En los dos días siguientes, verificó la ejecución remota de código sin necesidad de iniciar sesión en los servidores oficiales de Drupal y WordPress.
"Este tipo de riesgos en la gestión de la memoria se conocen desde hace mucho tiempo, pero durante mucho se ha considerado que eran demasiado difíciles de explotar", declaró Thai Duong, CEO de Calif, a The Wall Street Journal.
Convertir fallos teóricos en código de ataque útil requiere conectar múltiples etapas y depurar repetidamente la distribución de la memoria para cada objetivo. Lo que antes llevaba meses a equipos de élite, ahora puede ser realizado en una semana por un solo investigador con un modelo de vanguardia.
Ami Luttwak, cofundador de Wiz, la calificó como "la vulnerabilidad más grave jamás descubierta con la ayuda de la IA" y la comparó con vulnerabilidades legendarias como Heartbleed y Log4Shell, que también estaban profundamente arraigadas en los cimientos de Internet y permanecieron latentes durante muchos años antes de ser descubiertas.
Una reparación sin fin
En los dos meses posteriores a la confirmación de la vulnerabilidad, los responsables del mantenimiento de PHP lideraron la solución, con la participación de Calif, Wiz y OpenAI en la verificación. Proveedores como Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai y Vercel prepararon soluciones de mitigación con antelación, y las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron el parche antes de lo previsto.
Cloudflare anunció que sus reglas de protección WAF están activas por defecto para todos los clientes, incluida la versión gratuita. Para ello, lanzaron una nueva función llamada "Inspección completa de transacciones", que correlaciona las solicitudes y las respuestas del servidor de origen para determinar si un ataque ha tenido éxito.
Aun así, Cloudflare detectó tráfico de ataque dirigido a clientes ese día, así como atacantes que cambiaban constantemente las cargas útiles en un intento de eludir las reglas.
OpenAI también menciona que ha liberado el código fuente de una funcionalidad que se puede instalar en Codex, específicamente para detectar si un sitio web tiene una vulnerabilidad php2shell.
Para instalar, simplemente envía "$skill-installer install both skills from https://github.com/openai/php2shell-checker". Para comprobar, usa la habilidad correspondiente e incluye el enlace.
Utilice phpcheck-server cuando tenga acceso al servidor del sitio web y utilice phpcheck-url cuando solo tenga la URL.
Para los usuarios comunes, este incidente puede no tener ningún otro impacto, excepto que algunos sitios web podrían no permitir el inicio de sesión temporalmente debido a tareas de mantenimiento de emergencia.
Pero para cualquiera que gestione un sitio web o un servicio, actualizar a la versión parcheada requiere reiniciar todos los procesos PHP y organizar migraciones o cuarentenas para las versiones anteriores que no tengan el parche.
Para la gran cantidad de sitios web de nicho en China que funcionan con BT Panel, ThinkPHP y Discuz, las versiones anteriores de estos sitios web no recibirán parches oficiales en esta ocasión, y solo podrán recurrir a la migración o al aislamiento como último recurso.
Para la industria en su conjunto, PHP2Shell ha dejado una huella aún más profunda. En su análisis posterior al lanzamiento, OpenAI reconoció que la capacidad de ayudar a los investigadores a identificar vulnerabilidades graves también podría ayudar a los atacantes a crear herramientas de ataque con mayor rapidez.
En el momento en que se publica el parche, tanto el atacante como el defensor tienen el mismo registro de cambios en el código. La denominada "ventana de oportunidad del defensor" se está convirtiendo en un recurso que debe calcularse con precisión.
Hace más de una década, cuando estos fallos se introdujeron en el código PHP, nadie podía utilizarlos.
Ahora la IA los ha desenterrado, y esta vez, están en manos de los defensores.
▲ El desmoronamiento de internet
Tenemos motivos de sobra para reconocer la contribución de la IA a este evento. Gracias a la IA, los investigadores pudieron seguir investigando pistas, analizar las razones de los fallos e impulsar intentos que antes resultaban difíciles de completar.
Sin embargo, demostrar que una vulnerabilidad puede ser explotada a menudo implica crear un conjunto de código de ataque funcional. Las capacidades analíticas y de depuración que demuestra el modelo en este proceso también pueden utilizarse para mejorar las herramientas de ataque.
A medida que disminuyen las barreras de entrada para este tipo de trabajo, también aumentan las amenazas a las que deben enfrentarse los responsables del mantenimiento.
En esta ocasión, los investigadores presentaron su informe antes de lo previsto, lo que les dio un valioso tiempo para la restauración. Es difícil predecir cuánto tiempo más de preparación tendrán disponible en el futuro.
La IA puede identificar y verificar problemas cada vez más rápido, pero si toda Internet podrá seguir el ritmo de las actualizaciones es otra cuestión.