La crisis autoinducida de PHP – Un análisis real de una crisis que no existió

Idioma / Language: Español · English

PHP2Shell: veintitrés horas entre un rumor y un parche

Dos fallos críticos en el corazón de PHP, el lenguaje con el que funcionan siete de cada diez webs, llevaban semanas corrigiéndose en silencio. Veintitrés horas antes del parche, un mensaje en un foro lo echó todo a perder. Reconstruimos la historia, explicamos cómo funcionan los fallos y analizamos por qué la filtración convirtió un problema serio en una crisis que pudo haberse evitado.

José Fco. Alonso

Un martes cualquiera, a las tres de la tarde

El martes 20 de octubre de 2026, hacia las 15:00 en hora universal coordinada (UTC), apareció en Hacker News, el foro de noticias tecnológicas más leído por programadores y administradores de sistemas, un mensaje breve con el formato «Tell HN», el que se usa para contar algo a la comunidad. Su autor, que firmaba con un seudónimo, aseguraba tener la información de una «fuente fiable»: el jueves 22 de octubre, a las 18:00 hora de Europa central, el proyecto PHP anunciaría dos vulnerabilidades de ejecución remota de código con la máxima puntuación posible de gravedad, un 10,0 sobre 10. No daba detalles técnicos, ni pruebas, ni versiones afectadas. Daba, eso sí, una fecha, una hora y una cifra que bastaban para encender todas las alarmas.

El mensaje se borró poco después, pero ya era tarde. Las capturas de pantalla saltaron a X y a Mastodon, algunos perfiles añadieron los dos identificadores CVE reservados y afirmaron que el fallo afectaba a todas las versiones desde PHP 5, y en pocas horas la noticia estaba en todos los paneles de alerta del sector. Lo que debía haber sido un anuncio ordenado, preparado durante semanas entre los mantenedores de PHP, las distribuciones de Linux, los proveedores de alojamiento y los propios descubridores, se convirtió en una carrera contrarreloj en la que los defensores corrían a ciegas y los atacantes sabían exactamente dónde mirar.

Este artículo cuenta esa historia. Explica qué son los fallos bautizados como PHP2Shell, por qué tardaron tanto en corregirse y cómo funcionan por dentro, pero se detiene sobre todo en las veintitrés horas que separaron aquel mensaje del parche oficial, porque en ellas se concentra la lección más útil del caso: una vulnerabilidad grave es un problema técnico, y la forma de contarla puede convertirla, además, en un problema social. La segunda parte, en este caso, se podía haber evitado.

El lenguaje que sostiene media Internet

Para entender el alcance del susto conviene recordar qué es PHP. Nacido a mediados de los años noventa como un conjunto de herramientas personales de Rasmus Lerdorf para su página web, se convirtió en el lenguaje de programación del lado del servidor más extendido de la historia de la web. Con él están escritos WordPress, Drupal, Joomla, Moodle, Nextcloud, MediaWiki (el motor de la Wikipedia) y una cantidad incalculable de aplicaciones a medida. Según los datos de W3Techs que manejaban los analistas durante la crisis, PHP aparece en el 69,3 % de los sitios web cuyo lenguaje de servidor puede identificarse. Detrás de esa cifra hay tiendas en línea, periódicos, sedes electrónicas de ayuntamientos, intranets hospitalarias, plataformas educativas y, por supuesto, el portal donde se publica esta revista.

Esa ubicuidad tiene una contrapartida que los expertos en seguridad conocen bien: PHP es una infraestructura crítica mantenida con recursos de proyecto comunitario. La PHP Foundation, creada en 2021 para dar estabilidad al desarrollo del lenguaje, cuenta con un equipo de algo más de una decena de personas entre jornada completa y parcial y vive de patrocinios y donaciones. La mayor parte de las instalaciones del mundo, además, no usan la última versión. Una porción enorme de servidores sigue con ramas que el proyecto ya no mantiene, como PHP 7.4 (sin soporte oficial desde noviembre de 2022) o PHP 8.0 y 8.1, y depende de que alguien, ya sea una distribución de Linux, un proveedor comercial o un voluntario, aplique los arreglos por su cuenta. Los propios analistas de Hadrian estimaron que cerca de la mitad de los sitios en PHP funcionaban sobre ramas que difícilmente recibirían un parche oficial.

En ese ecosistema, un fallo que permita ejecutar código a distancia sin autenticarse, con independencia de la aplicación instalada, equivale a una llave maestra para buena parte de la web.

Una sospecha de 2024 que nadie supo cerrar

PHP2Shell no nació en octubre de 2026. Su raíz se detectó dos años antes, durante la primera auditoría externa de seguridad del núcleo de PHP en mucho tiempo. Aquel trabajo lo hizo la firma francesa Quarkslab, lo organizó la Open Source Technology Improvement Fund (OSTIF) y lo financió la Sovereign Tech Agency alemana, un organismo público que invierte en el software libre del que dependen las infraestructuras digitales. Mientras corregía uno de los problemas señalados por los auditores, un desarrollador del núcleo vio los primeros indicios de un fallo en la gestión de la memoria cuando una petición se queda sin ella.

Según el relato que la propia PHP Foundation publicó el 21 de octubre, en aquel momento alguien planteó que podría ser explotable, pero nadie encontró una vía concreta para hacerlo, y otros problemas con un impacto más claro pasaron por delante. El equipo de seguridad estudió varias soluciones y todas tenían un coste: una rompía la compatibilidad hacia atrás, otra introducía un nuevo riesgo de denegación de servicio y una tercera obligaba a modificar miles de extensiones de terceros. Las decisiones se tomaban por consenso, nadie quería equivocarse con un cambio tan delicado y el trabajo se paró y se reanudó varias veces durante meses.

La fundación lo ha reconocido con una franqueza poco habitual: el retraso fue un «fallo estructural», provocado a la vez por el proceso de decisión del equipo de seguridad y por su falta de recursos. Esa admisión importa para el resto de la historia, porque desmiente la tentación de presentar PHP2Shell como una sorpresa caída del cielo. El problema de fondo era conocido, aunque no se hubiera demostrado su gravedad, y llevaba dos años esperando una decisión.

El verano en que las máquinas encontraron el agujero

Lo que cambió en 2026 fue la llegada de herramientas de inteligencia artificial capaces de auditar código a gran escala. A finales de julio, la empresa de seguridad Calif empezó a revisar PHP dentro de «Patch the Planet», un programa de OpenAI que invitaba a equipos de investigación a usar sus modelos para encontrar y corregir fallos en software crítico de código abierto. Calif implicó desde el principio a la PHP Foundation a través de uno de sus responsables, Volker Dusch.

El investigador Ryan Austin, de Calif, encontró el 1 de agosto la primera forma de provocar un error fatal por falta de memoria en un punto delicado y, poco después, otras variantes. Su relato técnico, publicado tras el parche, atribuye el hallazgo a un método de trabajo en el que un asistente de IA le ayudaba a recorrer el código, y subraya que lo decisivo fue conocer bien el objetivo, más que la habilidad para formular instrucciones. La prensa ha identificado el modelo empleado como GPT-5.6 Sol, de OpenAI.

Hay un detalle de ese relato que conviene retener, porque ofrece el contrapunto exacto de lo que ocurriría en octubre. El 5 de agosto, Austin publicó en X el resumen criptográfico (hash) de uno de sus hallazgos. Es una práctica conocida entre investigadores: el hash no revela nada del fallo, pero permite demostrar más adelante que uno lo había descubierto en esa fecha. Es la manera discreta de reclamar la autoría sin dar a nadie una pista aprovechable.

El 11 de agosto, Calif comunicó el primer fallo al equipo de seguridad de PHP. Ese mismo día, OpenAI informó de forma independiente de la misma causa raíz. El 14 de agosto, Calif entregó una prueba de concepto de ejecución remota de código, que PHP confirmó al día siguiente, y el 21 de agosto comunicó el segundo fallo. Desde el 11 de agosto, según la fundación, arreglar el problema pasó a ser la máxima prioridad.

En paralelo, el equipo de investigación de Wiz, la empresa de seguridad en la nube integrada en Google, llegó a la misma zona del código por su cuenta. Encontró su primera vulnerabilidad el 19 de agosto con la ayuda de su herramienta Wiz Atlas y de los modelos Gemini 4 Argon y GPT-5.6 Sol, confirmó la ejecución remota sin autenticar contra Drupal el 20 y contra WordPress el 21, y lo notificó a PHP el 24 de agosto. Wiz acuñó el nombre de PHP2Shell y comparó la importancia del caso con Heartbleed, el fallo de OpenSSL de 2014 que reveló la fragilidad de las piezas compartidas de Internet.

Con tres equipos señalando el mismo punto, la decisión que llevaba dos años atascada se tomó por fin. Los desarrolladores Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka y Niels Dossche, que figuran como responsables de la corrección en los avisos oficiales, prepararon un cambio profundo en la forma en que PHP gestiona la falta de memoria. Se fijó la publicación coordinada para el jueves 22 de octubre y, como es habitual, se entregaron los parches por adelantado a las distribuciones de Linux y a los proveedores con soporte extendido para que tuvieran los paquetes listos ese día.

Qué falla, explicado sin tecnicismos de más

PHP2Shell agrupa varias vulnerabilidades de seguridad de memoria repartidas en dos identificadores, CVE-2026-109618 y CVE-2026-109619. Los avisos oficiales describen con detalle las condiciones en que se producen; aquí nos quedamos a propósito en el nivel que necesita un administrador, un jurista o un perito para entender el riesgo y explicarlo, sin entrar en la receta que interesa a quien quiere aprovecharlo.

El fondo común: peticiones que terminan de golpe

PHP atiende cada petición web con su propio espacio de memoria y, cuando la petición termina, lo limpia para que la siguiente empiece de cero. Ese ciclo funciona bien mientras las peticiones acaban de forma ordenada. Los dos fallos aparecen cuando una petición se interrumpe bruscamente por un error fatal, como el agotamiento del límite de memoria que fija la directiva memory_limit, en un momento en que el intérprete tiene alguna de sus estructuras internas a medio preparar. La salida de emergencia que usa PHP en esos casos corta lo que se estaba haciendo y salta directamente a la limpieza, y esa limpieza puede encontrarse con datos que nadie terminó de ordenar.

En un programa escrito en C, como el intérprete de PHP, tratar como válidos datos que no lo son es una de las puertas clásicas a la corrupción de memoria, y la corrupción de memoria, en manos expertas, conduce a la ejecución de código.

CVE-2026-109618: datos a medias que se dan por buenos

El primer identificador, titulado «RCE via OOM corruption» (ejecución remota de código mediante corrupción por falta de memoria), cubre el caso en que la interrupción deja datos internos de la petición parcialmente inicializados y la rutina de cierre los trata como si estuvieran completos. Los avisos lo clasifican, entre otras categorías, como uso de memoria ya liberada (CWE-416), gestión incorrecta de condiciones excepcionales (CWE-755) y acceso a punteros sin inicializar (CWE-824).

CVE-2026-109619: el estado que sobrevive a su petición

El segundo, «RCE via stale global state» (ejecución remota de código mediante estado global obsoleto), es más sutil. Los procesos de PHP que sirven páginas no se crean y se destruyen con cada visita: un mismo proceso atiende muchas peticiones seguidas y guarda cierta información de forma persistente entre ellas, relacionada con los errores, las sesiones o las extensiones. Si una petición termina de forma abrupta, parte de esa información puede quedar apuntando a memoria que ya se ha liberado, y la petición siguiente que llegue al mismo proceso puede usarla antes de que la inicialización normal la ponga a cero. El resultado es, de nuevo, un uso de memoria liberada, que permite tanto leer datos ajenos como, en el peor caso, ejecutar código.

Wiz añadió un matiz que agrava el cuadro: una de las variantes permite leer memoria del proceso que contiene restos de otras peticiones, con contraseñas, tokens de autenticación o claves de API, aunque la aplicación no haga nada especial. Todas comparten, además, una característica que explica el pánico posterior: se producen antes de que se ejecute el código de la aplicación, de modo que una web en PHP vulnerable lo es aunque su programación sea impecable. Wiz llegó a afirmar que incluso un «Hola, mundo» servido con una versión afectada era atacable.

Quién está más expuesto

PHP se puede conectar al servidor web de varias maneras, llamadas SAPI. El aviso oficial considera afectadas todas las que sirven peticiones web: el módulo de Apache (mod_php), PHP-FPM, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto corresponde a mod_php, donde se demostró la ejecución remota con la configuración por defecto, porque el proceso sobrevive a una petición fallida y conserva el estado dañado para la siguiente.

Con PHP-FPM, la combinación habitual con el servidor Nginx y la que usan muchos alojamientos, las fuentes no coinciden del todo. El aviso técnico de CVE-2026-109618 indica que FPM limita la exposición porque descarta el proceso cuando falla el arranque de la petición, y que no se había demostrado un ataque completo. La PHP Foundation, en cambio, escribió en su análisis del mismo día que la ejecución remota también se había confirmado en FPM, y Calif mostró una demostración contra Nginx con PHP-FPM. Para el segundo identificador, FPM está expuesto en determinadas configuraciones. La conclusión práctica es la misma en todos los casos: ninguna SAPI puede considerarse a salvo sin el parche.

Por qué un 9,2 y no un 10

Los dos fallos tienen una puntuación CVSS 4.0 de 9,2, con el vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. Traducido: se atacan por la red, sin credenciales y sin intervención del usuario, con impacto alto en confidencialidad, integridad y disponibilidad. Dos factores impiden llegar al 10: la complejidad del ataque es alta (AC:H) y requiere que se den ciertas condiciones previas (AT:P), como que dos peticiones lleguen al mismo proceso. El matiz tiene su importancia, porque la cifra de 10,0 que difundió el mensaje filtrado era, sencillamente, falsa.

Qué cambia el parche

La corrección publicada el 21 de octubre en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 ataca la raíz del problema. Elimina la salida de emergencia para los casos de falta de memoria y la sustituye por una parada ordenada: cuando una petición supera su límite, el intérprete la detiene en el siguiente punto seguro de su máquina virtual, con las estructuras en un estado coherente. Si el consumo sigue creciendo hasta un segundo umbral, más alto, el proceso termina directamente, sin intentar limpiar nada. Además, el estado que se conserva entre peticiones se reinicia antes de liberar la memoria a la que apunta.

Es el tipo de cambio que se resistía desde 2024 por sus efectos en la compatibilidad y en las extensiones de terceros. Para las ramas sin soporte oficial (7.4, 8.0 y 8.1), el equipo de seguridad ofreció, dada la gravedad, adaptaciones mínimas del código fuente, y distribuciones, proveedores comerciales y mantenedores voluntarios, como Ondřej Surý, responsable de los paquetes de PHP más usados en Debian y Ubuntu, prepararon versiones instalables.

Mitigaciones mientras no se parchea

PHP fue tajante: actualizar es la única solución completa. Para quien no pudiera hacerlo de inmediato, el aviso propuso medidas que reducen la exposición a caminos concretos de ataque sin hacer segura la instalación. Entre ellas, fijar memory_limit=-1 desde una configuración que la aplicación no pueda modificar, mantener un post_max_size bajo y limitar en el servidor web o en el proxy el tamaño y la complejidad de las peticiones, y desactivar session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces, reiniciando siempre todos los procesos. El 23 de octubre, PHP añadió un aviso informativo sobre una tercera vía, de aparición muy improbable, identificada como CVE-2026-115560, y recomendó mantener desactivado el seguimiento del progreso de subida hasta la siguiente versión ordinaria.

Wiz, por su parte, señaló algunos síntomas que conviene vigilar en los registros: peticiones de formulario con varias partes poco habituales seguidas de errores de límite de memoria, ráfagas de respuestas HTTP 500, cookies de sesión PHPSESSID de tamaño o formato anómalo y reinicios inexplicables de los procesos de PHP.

Cómo se cuenta un fallo grave sin poner en peligro a nadie

Antes de entrar en lo que ocurrió el 20 de octubre, hay que explicar lo que debía ocurrir. Cuando alguien descubre una vulnerabilidad grave en un software usado por millones de sistemas, el sector sigue desde hace dos décadas un procedimiento llamado divulgación coordinada. Su lógica es sencilla. El descubridor informa en privado al responsable del software; este prepara la corrección y la entrega con antelación a quienes la empaquetan y distribuyen; y todos acuerdan una fecha y una hora, el fin del embargo, en la que se publican a la vez el aviso, el parche y los paquetes. Así, cuando los atacantes conocen el fallo, los defensores tienen ya la solución en la mano. Las normas ISO/IEC 29147 y 30111 recogen ese proceso, y la guía del CERT de la Universidad Carnegie Mellon lo describe con detalle.

El embargo tiene una debilidad conocida: cuantas más personas comparten el secreto, más probable es que se escape. Y cuando se escapa, el equilibrio se rompe en el peor sentido. La investigación académica lo ha medido muchas veces. Bilge y Dumitraş, en un estudio de referencia sobre ataques de día cero, comprobaron que la publicación de una vulnerabilidad dispara el volumen de ataques que la aprovechan, hasta en cinco órdenes de magnitud en algunos casos. Brumley y sus colegas demostraron en 2008 que, a partir de un parche, se puede generar de forma automática un ataque contra el fallo que corrige, a veces en cuestión de minutos. Y eso era antes de que existieran modelos de lenguaje capaces de leer código.

En el caso de PHP2Shell todo estaba preparado para el jueves 22 de octubre. Los distribuidores llevaban días con los parches y estaban terminando de construir sus paquetes. Solo hacía falta que nadie hablara.

Veintitrés horas que torcieron el embargo

La secuencia que sigue procede sobre todo del análisis que publicó la PHP Foundation el 21 de octubre y de las reconstrucciones de Socket, Hadrian y Threat Landscape, con las horas en UTC.

Hacia las 15:00 del martes 20 de octubre, los dos identificadores CVE empezaron a circular por foros y redes sociales, con una hora de publicación equivocada y una puntuación de 10,0 que tampoco era la real. El primer rastro público conocido es el mensaje de Hacker News descrito al principio, que citaba una «fuente fiable» y que su autor retiró poco después. La filtración, insiste la fundación, no contenía detalles técnicos. Contenía algo casi igual de valioso para un atacante: la certeza de que en PHP había dos fallos de ejecución remota sin autenticar y el aviso de que en dos días se publicaría el parche.

La noticia corrió como la pólvora y esa misma tarde recibió una confirmación de peso. La empresa de seguridad watchTowr publicó en X que la información embargada se había filtrado, que las vulnerabilidades eran reales y que el embargo estaba fijado para el jueves a las 11:00 de la costa este de Estados Unidos. Aclaró que ellos no las habían descubierto y que el mérito era de los investigadores originales. Su consejero delegado, Benjamin Harris, lo repitió ante la prensa: podían confirmar que las vulnerabilidades eran reales. La empresa aseguró además haber reproducido una de ellas, aunque se guardó los detalles.

A las 19:30, el equipo de seguridad de PHP reaccionó. Publicó en php.net un aviso previo y adelantó la publicación un día, al miércoles 21 a las 14:00. No podía publicar de inmediato, porque los distribuidores seguían empaquetando y una publicación precipitada habría dejado a muchos usuarios sin una forma sencilla de actualizar. El aviso incluía una frase que, vista con perspectiva, era una advertencia: el proyecto se reservaba el derecho a publicar antes si se conocían detalles de los fallos o aparecían pruebas de explotación.

Media hora después, hacia las 20:00, Calif, uno de los equipos que había descubierto los fallos, publicó por error un vídeo en el que se veía su prueba de concepto funcionando contra objetivos reales. Lo borró, pero las copias ya circulaban por las redes. La fundación considera que el vídeo revelaba pocos detalles adicionales, aunque contribuyó a acelerar el desarrollo de ataques públicos al día siguiente. Hacia las 23:00, además, pudieron haberse filtrado las recomendaciones de mitigación que se habían entregado de forma reservada a algunos operadores de infraestructuras críticas.

La madrugada del 21 confirmó los temores. Según Amazon, hacia las 02:00 aparecieron las primeras pruebas de concepto públicas, y entre las 02:00 y las 08:00 su red de señuelos registró nuevos intentos de ataque procedentes de distintas infraestructuras de anonimato. A las 03:02, Cloudflare empezó a bloquear con su cortafuegos de aplicaciones los intentos de explotación contra sus clientes, unas nueve horas antes de la publicación oficial. A las 07:41, la empresa Chainguard, que había recibido el parche por adelantado como otros distribuidores, publicó imágenes de contenedores con PHP ya corregido, más de seis horas antes de la hora pactada. A media mañana, la firma Hadrian informaba de intentos de explotación a gran escala. Sansec, especialista en comercio electrónico, pronosticó que los ataques masivos empezarían en los quince minutos siguientes a la publicación.

A las 13:34 se hicieron públicos en GitHub los dos avisos técnicos, veintiséis minutos antes de lo anunciado. A las 14:00 llegaron las nuevas versiones. Habían pasado veintitrés horas desde el mensaje del foro, y el proceso ordenado que debía culminar el jueves se había convertido en una sucesión de reacciones a hechos consumados.

El bocazas y su caja de resonancia

Conviene detenerse en el primer eslabón, porque es el que desencadenó todo lo demás y el que menos justificación tiene. El autor del mensaje de Hacker News no aportó nada que sirviera para defenderse. No dijo qué componente fallaba, ni qué versiones estaban afectadas, ni qué medidas se podían tomar mientras tanto. Dio una puntuación de gravedad inflada y una fecha equivocada. Ningún administrador de sistemas del mundo pudo hacer nada útil con esa información, salvo inquietarse. Lo único que el mensaje transmitía con exactitud era lo que más convenía callar: que existía un fallo de enorme valor y que el reloj corría.

Para un atacante, ese tipo de dato tiene un valor que el profano tiende a subestimar. Saber que hay algo, y aproximadamente dónde, reduce de forma drástica el espacio de búsqueda. En 2026, además, ese espacio se recorre con herramientas de inteligencia artificial que analizan código a una velocidad que ningún equipo humano puede igualar, como demostraron precisamente Calif, OpenAI y Wiz al encontrar los fallos. El propio consejero delegado de Chainguard, Dan Lorenc, explicó después que su empresa había localizado el problema por su cuenta tras un primer aviso, con su banco de pruebas y un modelo de IA de última generación. Si un equipo defensivo podía hacerlo, cualquier grupo con medios y motivación podía hacerlo también. La filtración funcionó como el disparo de salida de una carrera en la que solo una de las partes sabía qué buscar.

Este artículo no da el nombre de la cuenta que publicó el mensaje. Un único blog lo ha atribuido a un usuario concreto, pero nadie más lo ha confirmado y la PHP Foundation, que es quien mejor conoce los hechos, ha evitado identificar a la persona que filtró la información inicial. Tampoco se sabe quién fue la «fuente fiable» de la que hablaba el mensaje, ni cómo le llegó a quien lo escribió. Señalar a alguien con nombre y apellidos sobre esa base sería repetir, en otra escala, el mismo error que se critica: difundir lo que no está comprobado.

Lo que sí puede afirmarse es que el mensaje solo tuvo el efecto que tuvo porque otros le dieron credibilidad. Un rumor anónimo en un foro, sin pruebas, borrado a los pocos minutos, puede quedar en nada. La confirmación pública de una empresa de seguridad reconocida lo transformó en un hecho. Las intenciones de watchTowr pueden discutirse: su mensaje parece pensado para que los administradores se prepararan y no se dejaran llevar por la cifra de 10,0 ni por los bulos. Pero el resultado práctico fue que, a partir de ese momento, nadie en el mundo tuvo dudas de que había algo real que buscar. En el lenguaje de la seguridad, se había confirmado la existencia del objetivo.

Después vinieron los errores de quienes sí tenían información técnica. El vídeo de Calif mostraba que el ataque funcionaba contra sistemas reales, lo que por sí solo orienta a quien intenta reproducirlo. Y las imágenes de Chainguard pusieron a disposición de cualquiera el parche ya compilado seis horas antes de lo previsto. Comparar el código antes y después de una corrección para deducir qué arregla, una técnica conocida como análisis diferencial de parches, es exactamente lo que Brumley y sus colegas automatizaron en 2008. La fundación lo resumió con dureza: cualquier atacante podía estudiar el arreglo mientras el resto de los usuarios de PHP seguían esperando, y aquella decisión despreció semanas de trabajo de muchas partes para coordinar la publicación. Lorenc, por su parte, defendió en un comentario en Hacker News que tomó la decisión de adelantarse cuando aparecieron ataques reales, y en LinkedIn pidió disculpas por la carga añadida a los mantenedores.

Ninguno de estos actores, conviene subrayarlo, actuó con la intención de facilitar ataques. Pero la cadena muestra cómo funciona un embargo roto: cada filtración posterior se justifica en la anterior. Si el secreto ya está fuera, ¿por qué no confirmar? Si los atacantes ya saben, ¿por qué no publicar las imágenes corregidas? Cada paso parece razonable visto de forma aislada, y el conjunto acaba entregando a los atacantes, en menos de un día, casi todo lo que el embargo debía protegerles de conocer.

¿Habría pasado lo mismo sin la filtración?

Un análisis honesto tiene que hacerse esa pregunta, porque hay datos que matizan la tesis de la crisis innecesaria.

El más importante lo aportó Amazon. Su servicio de inteligencia de amenazas detectó en MadPot, su red mundial de servidores señuelo, un intento de explotación de PHP2Shell fechado el 17 de octubre, cuatro días antes de la publicación y tres antes del mensaje de Hacker News. Venía de una dirección asociada a una red comercial de anonimato. Amazon no explica cómo obtuvo la información quien lanzó aquel intento, y advierte de que no puede saber si habría funcionado contra un sistema real, porque un señuelo no permite comprobarlo. Pero el dato sugiere que el secreto ya se había escapado por alguna vía antes del 20 de octubre, o que alguien había llegado a los fallos por su cuenta. Lorenc, por su parte, habla de un «primer aviso» recibido por su empresa el viernes 16, lo que indica que el círculo de personas al tanto era ya amplio.

También hay que tener presente la otra cara de la moneda. La filtración obligó a acelerar una publicación que llevaba dos años de retraso en su raíz. Hay quien defiende, con argumentos atendibles, que la presión pública es a veces la única forma de que un problema conocido se resuelva, y la propia fundación ha admitido que su proceso de decisión falló durante mucho tiempo. La literatura económica sobre la divulgación ha documentado ese efecto: Arora y sus colegas comprobaron en 2010 que la divulgación pública acelera la publicación de parches por parte de los fabricantes, y Cavusoglu y sus coautores analizaron cómo distintos mecanismos de divulgación reparten los costes entre fabricantes, usuarios y atacantes.

Con todo, el argumento no se sostiene en este caso concreto. En octubre de 2026 el parche ya existía, estaba en manos de los distribuidores y tenía fecha. Lo único que la filtración aceleró fue la exposición, porque la corrección ya estaba hecha. El equipo de seguridad de PHP declaró que, tras la filtración, había vigilado los ataques que circulaban y que en el momento de la publicación no había identificado ninguno que funcionara de verdad. Si eso es así, el adelanto de un día no protegió a nadie y dejó a muchos administradores con menos margen para prepararse. Que el secreto se hubiera escapado antes por otra vía, como sugiere el dato de Amazon, explica que hubiera un riesgo previo, pero en ningún caso justifica multiplicarlo.

La conclusión más ajustada es, por tanto, doble. El fallo era grave y su retraso, un problema serio y reconocido. La crisis social de los días 20 y 21 de octubre, con su ruido, sus cifras falsas y sus apagones preventivos, fue en buena medida evitable.

El precio del pánico

Las consecuencias de esas veintitrés horas se midieron en servicios desconectados. Ante la combinación de un fallo crítico confirmado, ataques en marcha y un parche que todavía no existía, varias administraciones optaron por la medida más drástica. En Finlandia, Valtori, el centro de servicios informáticos del Estado, empezó a desconectar los servicios web públicos de la administración estatal antes del parche, y aclaró que no se debía a ninguna brecha. Organismos y universidades de los Países Bajos y de Austria hicieron lo mismo, y en Francia se desconectaron temporalmente sedes electrónicas de la administración local. En Luxemburgo, el centro de informática del Estado retiró algunos servicios como medida de precaución, y el equipo nacional de respuesta, CIRCL, recomendó considerar la desconexión cuando el riesgo no pudiera reducirse lo suficiente. En el Reino Unido, tras una alerta del Centro Nacional de Ciberseguridad, quedaron fuera de servicio webs de ayuntamientos como los de Edimburgo y Oxford y de la Policía Metropolitana de Londres. En Estados Unidos, la NSA difundió en X una recomendación en la misma línea.

Fuera del sector público, la Fundación Wikimedia apagó buena parte de sus servicios auxiliares, el Internet Archive estuvo brevemente fuera de línea y varios juegos y tiendas en línea japonesas entraron en mantenimiento. Cada una de esas desconexiones tiene un coste: trámites que no se pueden hacer, información pública inaccesible, ventas perdidas y horas de trabajo de equipos técnicos en plena madrugada.

Algunas de esas decisiones habrían sido igual de prudentes con un calendario ordenado, porque no todos los sistemas pueden actualizarse en el mismo momento en que sale el parche. Pero la diferencia entre una publicación coordinada y una filtrada está en el orden de los acontecimientos. Con el embargo intacto, el aviso, el parche y los paquetes habrían llegado juntos, y la ventana de exposición habría empezado a cerrarse en el mismo instante en que se abría. Con la filtración, el mundo supo del peligro un día antes de tener el remedio, y durante ese día lo único que podía hacer quien no quisiera arriesgarse era apagar.

Lo que dice el derecho sobre irse de la lengua

Desde el punto de vista jurídico, el caso plantea preguntas que interesan a quienes trabajan en el ámbito forense y del derecho tecnológico, aunque las respuestas no sean siempre nítidas.

La primera es si quien difunde información embargada sobre una vulnerabilidad incurre en algún tipo de responsabilidad. En el derecho español, la vía penal más próxima sería la revelación de secretos de empresa de los artículos 278 y 279 del Código Penal, que castiga con especial dureza la difusión por parte de quien tenía obligación legal o contractual de guardar reserva. Su encaje en un caso como este es más que dudoso. La Ley 1/2019, de Secretos Empresariales, exige que la información tenga valor empresarial y que su titular haya adoptado medidas razonables para mantenerla en secreto, y aquí hablamos de un proyecto de software libre, de información que iba a hacerse pública dos días después y de un autor que quizá no tenía ningún deber de reserva. Para quien sí lo tenía, como un distribuidor o un proveedor que recibió el parche por adelantado, la vía realista es la contractual: incumplimiento de los acuerdos de confidencialidad que acompañan a estos procesos. En la práctica, la sanción más habitual en el sector es la exclusión de las listas de notificación previa, que deja al infractor fuera del círculo de confianza en futuras crisis.

La segunda pregunta mira al futuro inmediato. Desde el 11 de septiembre de 2026 son aplicables las obligaciones de notificación del Reglamento (UE) 2024/2847, conocido como Ley de Ciberresiliencia. Los fabricantes de productos con elementos digitales comercializados en la Unión deben notificar las vulnerabilidades explotadas activamente que afecten a sus productos con una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en un plazo de catorce días desde que exista una medida correctora. El reglamento prevé un régimen más ligero para los llamados administradores de software libre, como podría ser una fundación como la de PHP, pero las miles de empresas que integran PHP en sus productos sí son fabricantes a estos efectos. Una filtración que provoca explotación antes del parche activa, previsiblemente, una cascada de notificaciones simultáneas hacia los equipos de respuesta nacionales y hacia ENISA. PHP2Shell es probablemente uno de los primeros grandes casos en que esa maquinaria se pone a prueba. La Directiva NIS2, por su parte, encomienda a los equipos nacionales de respuesta el papel de coordinadores en la divulgación de vulnerabilidades, una figura pensada precisamente para que estos procesos no dependan solo de la buena voluntad de las partes.

La tercera pregunta es la que más interesa al perito. Cuando una organización sufre una intrusión a través de PHP2Shell y el asunto llega a un juzgado o a una autoridad de protección de datos, una de las primeras cuestiones será si actuó con la diligencia debida. El artículo 32 del Reglamento General de Protección de Datos exige medidas técnicas apropiadas al estado de la técnica, y valorar esa diligencia obliga a reconstruir con precisión cuándo pudo conocerse el riesgo y cuándo existió un remedio. En este caso, esa reconstrucción es inusualmente compleja. ¿Empieza el reloj con el mensaje de Hacker News, que era anónimo y contenía datos falsos? ¿Con la confirmación de watchTowr? ¿Con el aviso de php.net de las 19:30 del día 20, que no ofrecía ninguna medida concreta? ¿O con la publicación del parche y de las mitigaciones a las 14:00 del día 21? No parece razonable exigir a un responsable que actuara sobre un rumor anónimo, y sí que aplicara las mitigaciones en cuanto se publicaron y el parche en cuanto su distribución lo empaquetó. La cronología detallada de las filtraciones se convierte así en una pieza probatoria de primer orden.

Pautas para administradores y peritos

De todo lo anterior se desprenden algunas pautas prácticas, pensadas para quien administra servidores y para quien tiene que examinar uno después de un incidente.

Lo primero es comprobar la versión en uso, que no siempre coincide con la que uno cree tener. En línea de comandos basta con php -v, aunque la versión que sirve las páginas puede ser otra; en sistemas Debian o Ubuntu, dpkg -l | grep php muestra los paquetes instalados y su revisión exacta, que es la que hay que contrastar con los avisos de la distribución. En alojamientos compartidos, la versión se elige en el panel del proveedor, y conviene confirmar con él que la rama configurada incluye la corrección. Quien siga en una rama antigua, como PHP 7.4, debe asegurarse de que su fuente de paquetes ha incorporado la adaptación del parche, porque el número de versión principal no cambia.

En segundo lugar, las mitigaciones publicadas por PHP no deben retirarse con prisa tras actualizar. El propio proyecto recomienda mantener desactivado el seguimiento del progreso de subida si la aplicación no lo usa, y esa recomendación sigue vigente mientras no llegue la siguiente versión ordinaria.

En tercer lugar, quien deba examinar un servidor expuesto tiene que asumir que la ventana de riesgo empezó antes de lo que dicen los avisos. El dato de Amazon obliga a revisar, como mínimo, los registros desde el 17 de octubre. Las señales que conviene buscar son las que describieron Wiz y Amazon: picos de errores de agotamiento de memoria, ráfagas de respuestas 500, peticiones de formulario de varias partes anómalas, cookies de sesión extrañas y reinicios de procesos sin causa aparente. Amazon publicó además una lista de direcciones IP observadas, aunque advirtió de que pertenecen a redes de anonimato compartidas y deben investigarse, no bloquearse sin más. Como siempre en el análisis forense, lo primero es preservar los registros del servidor web y de PHP antes de que la rotación automática los borre, con su correspondiente cadena de custodia, y documentar la hora exacta en que se aplicó cada medida.

Por último, la lectura de un caso como este debe incluir la propia cronología pública. En un informe pericial, la diferencia entre «el fallo se conocía» y «el fallo se rumoreaba» puede ser decisiva, y las fuentes primarias, como los avisos de php.net, los avisos técnicos de GitHub y el análisis de la fundación, permiten fijar con precisión qué se sabía, quién lo sabía y desde cuándo.

Saber callar a tiempo

PHP2Shell pasará a la historia por varias razones. Es uno de los primeros fallos críticos de alcance mundial descubiertos con la ayuda decisiva de la inteligencia artificial, y su gestión ha obligado a la PHP Foundation a un ejercicio de autocrítica poco frecuente: ha reconocido el fallo estructural de 2024, ha pasado del consenso a las decisiones por mayoría en su equipo de seguridad, ha contratado a dos ingenieros más y ha pedido a empresas, proveedores de alojamiento y gobiernos que financien el trabajo del que todos dependen. Desde comienzos de julio, ese pequeño equipo ha publicado quince CVE y ha descartado más de cien informes inválidos o duplicados, muchos de ellos generados con las mismas herramientas que encontraron PHP2Shell.

Pero la lección que más interesa a quien se dedica a la seguridad, al derecho o a la investigación forense está en el 20 de octubre. Un proceso de divulgación coordinada es un pacto de discreción entre muchas personas que no se conocen, y solo funciona si cada una de ellas entiende que su silencio protege a millones de usuarios que nunca sabrán su nombre. Bastó con que una persona quisiera ser la primera en dar la noticia, y con que otras le dieran crédito con la mejor de las intenciones, para que el mundo conociera el peligro un día antes de tener el remedio.

Ryan Austin demostró en agosto que se puede reclamar el mérito de un hallazgo sin poner a nadie en riesgo: publicó un hash que no decía nada y esperó dos meses y medio. El autor del mensaje de octubre hizo exactamente lo contrario, y su información ni siquiera era correcta. Entre esos dos gestos cabe toda la ética de la divulgación de vulnerabilidades. En seguridad, como en tantos otros oficios, a veces la aportación más valiosa es saber callar a tiempo.

PHP’s self-inflicted crisis – A real analysis of a crisis that never was

Leer en español

Two critical flaws at the heart of PHP, the language that powers seven out of ten websites, had spent weeks being fixed quietly. Twenty-three hours before the patch, a forum post blew it all open. We reconstruct the story, explain how the flaws work and examine why the leak turned a serious problem into a crisis that could have been avoided.

An ordinary Tuesday, three in the afternoon

On Tuesday 20 October 2026, at around 15:00 Coordinated Universal Time (UTC), a short post appeared on Hacker News, the technology forum most widely read by programmers and system administrators. It used the «Tell HN» format, meant for telling the community something. Its pseudonymous author claimed to have it from a «reliable source»: on Thursday 22 October, at 18:00 Central European time, the PHP project would announce two remote code execution vulnerabilities with the highest possible severity score, 10.0 out of 10. There were no technical details, no evidence and no affected versions. There was, however, a date, a time and a number, and they were enough to set off every alarm.

The post was deleted shortly afterwards, but it was too late. Screenshots jumped to X and Mastodon, some accounts added the two reserved CVE identifiers and claimed that every version since PHP 5 was affected, and within hours the news was on every alert dashboard in the industry. What should have been an orderly announcement, prepared over weeks by the PHP maintainers, the Linux distributions, the hosting providers and the researchers themselves, became a race against the clock in which defenders were running blind and attackers knew exactly where to look.

This article tells that story. It explains what the flaws known as PHP2Shell are, why they took so long to fix and how they work, but it dwells above all on the twenty-three hours between that post and the official patch, because they hold the most useful lesson of the case: a serious vulnerability is a technical problem, and the way it is disclosed can also turn it into a social one. In this case, the second part could have been avoided.

The language that holds up half the Internet

To grasp the scale of the scare, it helps to recall what PHP is. Born in the mid-1990s as a set of personal tools Rasmus Lerdorf wrote for his own home page, it became the most widely used server-side programming language in the history of the web. WordPress, Drupal, Joomla, Moodle, Nextcloud and MediaWiki (the engine behind Wikipedia) are written in it, along with countless bespoke applications. According to the W3Techs figures analysts were quoting during the crisis, PHP runs 69.3% of the websites whose server-side language can be identified. Behind that figure are online shops, newspapers, local government portals, hospital intranets, learning platforms and, of course, the site on which this magazine is published.

That ubiquity comes at a price that security specialists know well: PHP is critical infrastructure maintained with the resources of a community project. The PHP Foundation, set up in 2021 to give the language’s development some stability, has a team of just over a dozen full- and part-time staff and lives on sponsorship and donations. Most installations in the world, moreover, do not run the latest version. A huge share of servers still run branches the project no longer maintains, such as PHP 7.4 (out of official support since November 2022) or PHP 8.0 and 8.1, and depend on someone else, whether a Linux distribution, a commercial vendor or a volunteer, to apply fixes. Hadrian’s analysts estimated that close to half of all PHP sites ran on branches unlikely ever to receive an official patch.

In that ecosystem, a flaw that allows unauthenticated remote code execution regardless of the application installed amounts to a master key to a large part of the web.

A 2024 suspicion nobody managed to close

PHP2Shell was not born in October 2026. Its root was spotted two years earlier, during the first external security audit of the PHP core in a long time. The work was carried out by the French firm Quarkslab, organised by the Open Source Technology Improvement Fund (OSTIF) and funded by Germany’s Sovereign Tech Agency, a public body that invests in the open-source software on which digital infrastructure depends. While fixing one of the issues the auditors had reported, a core developer noticed the first signs of a flaw in how memory was handled when a request runs out of it.

According to the account the PHP Foundation itself published on 21 October, someone suggested at the time that it might be exploitable, but nobody found a concrete way to do it, and other issues with a clearer impact took priority. The security team weighed several fixes, and every one of them had a cost: one broke backward compatibility, another introduced a new denial-of-service risk and a third required changes to thousands of third-party extensions. Decisions were made by consensus, nobody wanted to get such a delicate change wrong, and the work stalled and restarted several times over the following months.

The foundation has acknowledged this with unusual candour: the delay was a «structural failure», caused both by the security team’s decision-making process and by its lack of resources. That admission matters for the rest of the story, because it rules out any temptation to present PHP2Shell as a bolt from the blue. The underlying problem was known, even if its severity had not been demonstrated, and it had been waiting two years for a decision.

The summer the machines found the hole

What changed in 2026 was the arrival of artificial intelligence tools capable of auditing code at scale. At the end of July, the security company Calif began reviewing PHP under «Patch the Planet», an OpenAI programme that invited research teams to use its models to find and fix flaws in critical open-source software. Calif brought the PHP Foundation in from the outset through one of its leads, Volker Dusch.

Calif researcher Ryan Austin found the first way of triggering a fatal out-of-memory error at a sensitive point on 1 August, and other variants soon after. His technical write-up, published after the patch, credits the finding to a way of working in which an AI assistant helped him navigate the code, and stresses that knowing the target well mattered more than any skill at prompting. Press reports have identified the model as OpenAI’s GPT-5.6 Sol.

One detail of that account is worth keeping in mind, because it is the exact counterpoint to what would happen in October. On 5 August, Austin posted on X the cryptographic hash of one of his findings. It is a well-known practice among researchers: the hash reveals nothing about the flaw, but it allows one to prove later that one had found it by that date. It is the discreet way to claim credit without handing anyone a usable clue.

On 11 August, Calif reported the first flaw to the PHP security team. That same day, OpenAI independently reported the same root cause. On 14 August, Calif delivered a remote code execution proof of concept, which PHP confirmed the next day, and on 21 August it reported the second flaw. From 11 August onwards, according to the foundation, fixing the problem became the top priority.

In parallel, the research team at Wiz, the cloud security company that is now part of Google, reached the same area of the code on its own. It found its first vulnerability on 19 August with the help of its Wiz Atlas tool and the Gemini 4 Argon and GPT-5.6 Sol models, confirmed unauthenticated remote execution against Drupal on the 20th and against WordPress on the 21st, and reported it to PHP on 24 August. Wiz coined the name PHP2Shell and compared the case to Heartbleed, the 2014 OpenSSL flaw that exposed the fragility of the Internet’s shared building blocks.

With three teams pointing at the same spot, the decision that had been stuck for two years was finally taken. The developers Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Niels Dossche, credited with the fix in the official advisories, prepared a far-reaching change to the way PHP handles running out of memory. A coordinated release was set for Thursday 22 October and, as usual, the patches were shared in advance with the Linux distributions and the long-term support vendors so that their packages would be ready on the day.

What breaks, explained without too much jargon

PHP2Shell groups several memory-safety vulnerabilities under two identifiers, CVE-2026-109618 and CVE-2026-109619. The official advisories describe in detail the conditions under which they occur; here we deliberately stay at the level an administrator, a lawyer or a forensic examiner needs to understand the risk and explain it, without going into the recipe that interests those who want to exploit it.

The common ground: requests that end abruptly

PHP serves each web request with its own memory space and, when the request ends, clears it so that the next one starts from scratch. That cycle works well as long as requests end in an orderly way. Both flaws appear when a request is cut short by a fatal error, such as exhausting the memory limit set by the memory_limit directive, at a moment when the interpreter has one of its internal structures half-built. The emergency exit PHP uses in such cases stops whatever was under way and jumps straight to clean-up, and that clean-up may run into data nobody finished putting in order.

In a program written in C, such as the PHP interpreter, treating invalid data as valid is one of the classic gateways to memory corruption, and memory corruption, in expert hands, leads to code execution.

CVE-2026-109618: half-finished data taken at face value

The first identifier, titled «RCE via OOM corruption» (remote code execution through out-of-memory corruption), covers the case in which the interruption leaves internal request data partially initialised and the clean-up routine treats it as complete. Among other categories, the advisories classify it as use after free (CWE-416), improper handling of exceptional conditions (CWE-755) and access of uninitialised pointer (CWE-824).

CVE-2026-109619: state that outlives its request

The second, «RCE via stale global state», is subtler. The PHP processes that serve pages are not created and destroyed with every visit: the same process handles many requests in a row and keeps some information persistently between them, related to errors, sessions or extensions. If a request ends abruptly, part of that information may be left pointing to memory that has already been freed, and the next request reaching the same process may use it before normal initialisation resets it. The result is, once again, a use after free, which can allow both reading other people’s data and, in the worst case, running code.

Wiz added a detail that makes the picture worse: one of the variants allows reading process memory holding leftovers from other requests, including passwords, authentication tokens or API keys, even if the application does nothing special. All of them also share a feature that explains the later panic: they occur before any application code runs, so a website on a vulnerable PHP build is exposed however well it is programmed. Wiz went as far as saying that even a «Hello, world» page served by an affected version could be attacked.

Who is most exposed

PHP can be attached to a web server in several ways, known as SAPIs. The official advisory considers every one that serves web requests to be affected: the Apache module (mod_php), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The highest risk lies with mod_php, where remote execution was demonstrated with default settings, because the process survives a failed request and keeps the damaged state for the next one.

With PHP-FPM, the usual pairing with the Nginx server and the one used by many hosting providers, the sources do not fully agree. The technical advisory for CVE-2026-109618 says FPM limits exposure because it discards the process when request start-up fails, and that no complete attack had been demonstrated. The PHP Foundation, by contrast, wrote in its analysis that same day that remote execution had also been confirmed on FPM, and Calif showed a demonstration against Nginx with PHP-FPM. For the second identifier, FPM is exposed in certain configurations. The practical conclusion is the same in every case: no SAPI can be considered safe without the patch.

Why 9.2 and not 10

Both flaws have a CVSS 4.0 score of 9.2, with the vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. In plain words: they can be attacked over the network, with no credentials and no user interaction, with high impact on confidentiality, integrity and availability. Two factors keep the score below 10: attack complexity is high (AC:H) and certain preconditions must be met (AT:P), such as two requests reaching the same process. The nuance matters, because the 10.0 figure spread by the leaked post was simply false.

What the patch changes

The fix released on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 goes to the root of the problem. It removes the emergency exit for out-of-memory cases and replaces it with an orderly stop: when a request exceeds its limit, the interpreter halts it at the next safe point of its virtual machine, with its structures in a consistent state. If consumption keeps growing up to a second, higher threshold, the process simply terminates without attempting any clean-up. In addition, the state kept between requests is reset before the memory it points to is released.

This is the kind of change that had been resisted since 2024 because of its effects on compatibility and on third-party extensions. For the branches without official support (7.4, 8.0 and 8.1), the security team offered, given the severity, minimal source backports, and distributions, commercial vendors and volunteer maintainers such as Ondřej Surý, who looks after the most widely used PHP packages for Debian and Ubuntu, prepared installable builds.

Mitigations until the patch is applied

PHP was blunt: updating is the only complete solution. For those unable to do so immediately, the advisory proposed measures that reduce exposure to specific attack paths without making the installation safe. They include setting memory_limit=-1 through configuration the application cannot override, keeping post_max_size low and limiting the size and complexity of requests at the web server or proxy, and disabling session.upload_progress.enabled and, on PHP 8.5, fatal_error_backtraces, always restarting every worker. On 23 October, PHP added an informational advisory about a third, very unlikely path, identified as CVE-2026-115560, and recommended keeping upload progress tracking disabled until the next regular release.

Wiz, for its part, flagged some symptoms worth watching for in the logs: unusual multipart form requests followed by memory-limit errors, bursts of HTTP 500 responses, PHPSESSID session cookies of abnormal size or format, and unexplained restarts of PHP processes.

How to disclose a serious flaw without putting anyone at risk

Before turning to what happened on 20 October, it is worth explaining what was supposed to happen. When someone finds a serious vulnerability in software used by millions of systems, the industry has followed for two decades a procedure known as coordinated disclosure. Its logic is simple. The finder reports privately to whoever is responsible for the software; they prepare the fix and share it in advance with those who package and distribute it; and everyone agrees on a date and time, the end of the embargo, when the advisory, the patch and the packages are published together. That way, by the time attackers learn of the flaw, defenders already have the remedy in hand. The ISO/IEC 29147 and 30111 standards set out the process, and the CERT guide from Carnegie Mellon University describes it in detail.

The embargo has a well-known weakness: the more people share the secret, the more likely it is to escape. And when it escapes, the balance tips the worst way. Academic research has measured this many times. Bilge and Dumitraş, in a landmark study of zero-day attacks, found that public disclosure of a vulnerability drives up the volume of attacks exploiting it by as much as five orders of magnitude in some cases. Brumley and colleagues showed in 2008 that an exploit for a flaw can be generated automatically from the patch that fixes it, sometimes within minutes. And that was before language models able to read code existed.

In the case of PHP2Shell, everything was ready for Thursday 22 October. The distributors had had the patches for days and were finishing their packages. All that was needed was for nobody to talk.

Twenty-three hours that bent the embargo

The sequence below draws mainly on the analysis the PHP Foundation published on 21 October and on the reconstructions by Socket, Hadrian and Threat Landscape, with times in UTC.

At around 15:00 on Tuesday 20 October, the two CVE identifiers began circulating on forums and social media, with a wrong release time and a 10.0 score that was not real either. The earliest known public trace is the Hacker News post described at the start, which cited a «reliable source» and was withdrawn by its author soon afterwards. The leak, the foundation stresses, contained no technical details. It contained something almost as valuable to an attacker: the certainty that PHP had two unauthenticated remote execution flaws, and notice that the patch would be out in two days.

The news spread like wildfire and that same afternoon received a weighty confirmation. The security company watchTowr posted on X that the embargoed information had leaked, that the vulnerabilities were real and that the embargo was set for Thursday at 11:00 US Eastern time. It made clear that it had not found them and that the credit belonged to the original researchers. Its chief executive, Benjamin Harris, repeated to the press that they could confirm the vulnerabilities were real. The company also said it had reproduced one of them, although it kept the details to itself.

At 19:30 the PHP security team responded. It published a pre-announcement on php.net and brought the release forward by a day, to Wednesday 21 at 14:00. It could not publish immediately, because distributors were still packaging and a rushed release would have left many users without an easy way to update. The notice included a sentence that, with hindsight, was a warning: the project reserved the right to release earlier if details of the flaws became public or evidence of exploitation appeared.

Half an hour later, at around 20:00, Calif, one of the teams that had found the flaws, mistakenly posted a video showing its proof of concept working against real targets. It deleted the video, but copies were already circulating. The foundation considers that it revealed few additional details, although it helped speed up the development of public exploits the next day. At around 23:00, mitigation advice shared confidentially with some critical infrastructure operators may also have leaked.

The early hours of the 21st confirmed the fears. According to Amazon, the first public proofs of concept appeared at about 02:00, and between 02:00 and 08:00 its honeypot network logged new attack attempts from various anonymisation services. At 03:02, Cloudflare began blocking exploitation attempts against its customers with its web application firewall, some nine hours before the official release. At 07:41, Chainguard, which like other distributors had received the patch in advance, published container images with PHP already fixed, more than six hours before the agreed time. By mid-morning, Hadrian was reporting large-scale exploitation attempts. Sansec, an e-commerce security specialist, predicted that mass attacks would begin within fifteen minutes of the release.

At 13:34 the two technical advisories went public on GitHub, twenty-six minutes ahead of schedule. At 14:00 the new versions arrived. Twenty-three hours had passed since the forum post, and the orderly process that was meant to culminate on Thursday had turned into a string of reactions to accomplished facts.

The loudmouth and the echo chamber

The first link deserves closer attention, because it set everything else in motion and has the least justification. The author of the Hacker News post offered nothing that could be used for defence. They did not say which component was flawed, which versions were affected or what could be done in the meantime. They gave an inflated severity score and a wrong date. No system administrator anywhere could do anything useful with that information, other than worry. The only thing the post conveyed accurately was precisely what should have been kept quiet: that a flaw of enormous value existed and that the clock was ticking.

For an attacker, that kind of information is worth more than a layperson might think. Knowing that something exists, and roughly where, shrinks the search space drastically. In 2026, moreover, that space is explored with artificial intelligence tools that analyse code faster than any human team, as Calif, OpenAI and Wiz had shown by finding the flaws in the first place. Chainguard’s chief executive, Dan Lorenc, later explained that his company had located the problem on its own after an initial warning, using its testing harness and a frontier AI model. If a defensive team could do it, so could any group with the means and the motivation. The leak worked like a starting pistol in a race where only one side knew what to look for.

This article does not name the account that published the post. A single blog has attributed it to a specific user, but nobody else has confirmed it, and the PHP Foundation, which knows the facts best, has avoided identifying whoever leaked the initial information. Nor is it known who the «reliable source» mentioned in the post was, or how the information reached its author. Pointing at someone by name on that basis would repeat, on a different scale, the very mistake under criticism: spreading what has not been verified.

What can be said is that the post only had the effect it did because others lent it credibility. An anonymous rumour on a forum, with no evidence and deleted within minutes, can come to nothing. Public confirmation by a well-known security company turned it into a fact. watchTowr’s intentions are open to debate: its message seems designed to help administrators prepare and to steer them away from the 10.0 figure and the hoaxes. But the practical result was that, from that moment on, nobody in the world doubted there was something real to look for. In security terms, the existence of the target had been confirmed.

Then came the mistakes of those who did hold technical information. Calif’s video showed that the attack worked against real systems, which in itself guides anyone trying to reproduce it. And Chainguard’s images made the compiled patch available to anyone six hours early. Comparing code before and after a fix to work out what it repairs, a technique known as patch diffing, is exactly what Brumley and colleagues automated in 2008. The foundation put it harshly: any attacker could study the fix while every other PHP user was still waiting, and the decision disregarded weeks of work by many parties to coordinate the release. Lorenc, for his part, argued in a Hacker News comment that he made the call to ship early once real attacks appeared, and apologised on LinkedIn for the extra burden on the maintainers.

None of these actors, it should be stressed, intended to help attackers. But the chain shows how a broken embargo works: each further leak is justified by the previous one. If the secret is already out, why not confirm it? If attackers already know, why not publish the fixed images? Each step looks reasonable in isolation, and together they end up handing attackers, in less than a day, almost everything the embargo was meant to keep from them.

Would it have happened anyway?

An honest analysis has to ask this question, because some facts qualify the argument that the crisis was unnecessary.

The most important came from Amazon. Its threat intelligence service detected in MadPot, its worldwide network of decoy servers, a PHP2Shell exploitation attempt dated 17 October, four days before disclosure and three before the Hacker News post. It came from an address linked to a commercial anonymisation network. Amazon does not explain how whoever launched it obtained the information, and warns that it cannot tell whether it would have worked against a real system, since a honeypot cannot show that. But the finding suggests the secret had already slipped out by some route before 20 October, or that someone had reached the flaws independently. Lorenc, too, mentions an «initial warning» his company received on Friday the 16th, which indicates that the circle of people in the know was already wide.

The other side of the coin must also be kept in mind. The leak forced the acceleration of a release whose root cause had been delayed for two years. Some argue, with reasonable grounds, that public pressure is sometimes the only way to get a known problem fixed, and the foundation itself has admitted that its decision process failed for a long time. The economic literature on disclosure has documented that effect: Arora and colleagues found in 2010 that public disclosure speeds up vendors’ patch releases, and Cavusoglu and co-authors analysed how different disclosure mechanisms share costs among vendors, users and attackers.

Even so, the argument does not hold in this particular case. In October 2026 the patch already existed, was in the hands of the distributors and had a date. The only thing the leak sped up was exposure, because the fix was already done. The PHP security team said that after the leak it had monitored the attacks in circulation and that, at release time, it had not identified any that actually worked. If so, bringing the release forward by a day protected nobody and left many administrators with less time to prepare. That the secret may have escaped earlier by another route, as Amazon’s finding suggests, explains a prior risk, but in no way justifies multiplying it.

The fairest conclusion is therefore twofold. The flaw was serious and its delay a real, acknowledged problem. The social crisis of 20 and 21 October, with its noise, its false figures and its precautionary shutdowns, was to a large extent avoidable.

The price of panic

The consequences of those twenty-three hours were measured in services switched off. Faced with a confirmed critical flaw, attacks under way and a patch that did not yet exist, several administrations chose the most drastic option. In Finland, Valtori, the state IT services centre, began taking the state administration’s public web services offline before the patch, making clear that no breach was involved. Agencies and universities in the Netherlands and Austria did the same, and in France local government websites were temporarily disconnected. In Luxembourg, the state IT centre took some services offline as a precaution, and the national response team, CIRCL, advised considering disconnection where the risk could not be sufficiently reduced. In the United Kingdom, following an alert from the National Cyber Security Centre, websites of councils such as Edinburgh and Oxford and of the Metropolitan Police went down. In the United States, the NSA posted similar advice on X.

Outside the public sector, the Wikimedia Foundation shut down many of its supporting services, the Internet Archive went briefly offline and several Japanese games and online shops went into maintenance. Every one of those shutdowns has a cost: procedures that cannot be completed, public information that cannot be reached, lost sales and hours of work by technical teams in the middle of the night.

Some of those decisions would have been equally prudent under an orderly timetable, because not every system can be updated the moment a patch comes out. But the difference between a coordinated release and a leaked one lies in the order of events. With the embargo intact, the advisory, the patch and the packages would have arrived together, and the exposure window would have started closing the moment it opened. With the leak, the world learned of the danger a day before it had the remedy, and during that day the only option for anyone unwilling to take the risk was to switch off.

What the law says about loose lips

From a legal point of view, the case raises questions of interest to those working in forensics and technology law, even if the answers are not always clear-cut.

The first is whether someone who spreads embargoed information about a vulnerability incurs any liability. Under Spanish law, the closest criminal provision would be the disclosure of trade secrets in Articles 278 and 279 of the Criminal Code, which punishes particularly harshly disclosure by someone under a legal or contractual duty of confidentiality. Its fit with a case like this is highly doubtful. Spain’s Trade Secrets Act (Law 1/2019) requires the information to have business value and its holder to have taken reasonable steps to keep it secret, and here we are dealing with an open-source project, with information due to be made public two days later and with an author who may have had no duty of confidentiality at all. For those who did have one, such as a distributor or vendor that received the patch in advance, the realistic route is contractual: breach of the non-disclosure agreements that accompany these processes. In practice, the most common sanction in the industry is removal from pre-notification lists, which leaves the offender outside the circle of trust in future crises.

The second question looks to the immediate future. Since 11 September 2026, the reporting obligations of Regulation (EU) 2024/2847, known as the Cyber Resilience Act, have applied. Manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities affecting their products with an early warning within 24 hours, a notification within 72 hours and a final report within fourteen days of a corrective measure becoming available. The regulation provides a lighter regime for so-called open-source software stewards, such as a foundation like PHP’s, but the thousands of companies that build PHP into their products are manufacturers for these purposes. A leak that leads to exploitation before the patch will foreseeably trigger a cascade of simultaneous notifications to national response teams and to ENISA. PHP2Shell is probably one of the first major cases to put that machinery to the test. The NIS2 Directive, for its part, gives national response teams the role of coordinators in vulnerability disclosure, a role designed precisely so that these processes do not rely solely on the goodwill of the parties.

The third question is the one that matters most to the forensic expert. When an organisation suffers an intrusion through PHP2Shell and the matter reaches a court or a data protection authority, one of the first issues will be whether it acted with due diligence. Article 32 of the General Data Protection Regulation requires technical measures appropriate to the state of the art, and assessing that diligence means reconstructing precisely when the risk could have been known and when a remedy existed. In this case, that reconstruction is unusually complex. Does the clock start with the Hacker News post, which was anonymous and contained false data? With watchTowr’s confirmation? With the php.net notice at 19:30 on the 20th, which offered no concrete measures? Or with the release of the patch and mitigations at 14:00 on the 21st? It does not seem reasonable to expect a controller to act on an anonymous rumour; it does seem reasonable to expect the mitigations to be applied as soon as they were published and the patch as soon as the distribution packaged it. The detailed timeline of the leaks thus becomes a key piece of evidence.

Guidance for administrators and forensic examiners

Some practical guidance follows from all of the above, aimed at those who run servers and at those who have to examine one after an incident.

The first step is to check the version actually in use, which does not always match the one people think they have. On the command line, php -v is enough, although the version serving web pages may differ; on Debian or Ubuntu systems, dpkg -l | grep php lists the installed packages and their exact revision, which is what must be checked against the distribution’s advisories. On shared hosting, the version is chosen in the provider’s control panel, and it is worth confirming with the provider that the configured branch includes the fix. Anyone still on an old branch such as PHP 7.4 must make sure their package source has incorporated the backport, because the main version number does not change.

Second, the mitigations published by PHP should not be hastily removed after updating. The project itself recommends keeping upload progress tracking disabled if the application does not use it, and that advice stands until the next regular release.

Third, anyone examining an exposed server must assume that the risk window opened earlier than the advisories say. Amazon’s finding means reviewing logs at least from 17 October. The signs to look for are those described by Wiz and Amazon: spikes in memory exhaustion errors, bursts of 500 responses, anomalous multipart form requests, odd session cookies and process restarts with no apparent cause. Amazon also published a list of observed IP addresses, while warning that they belong to shared anonymisation networks and should be investigated rather than blocked outright. As always in forensic analysis, the first step is to preserve the web server and PHP logs before automatic rotation deletes them, with the appropriate chain of custody, and to record the exact time each measure was applied.

Finally, reading a case like this should include the public timeline itself. In an expert report, the difference between «the flaw was known» and «the flaw was rumoured» can be decisive, and the primary sources, such as the php.net notices, the GitHub technical advisories and the foundation’s analysis, make it possible to establish precisely what was known, who knew it and since when.

Knowing when to keep quiet

PHP2Shell will go down in history for several reasons. It is one of the first critical flaws of global reach found with the decisive help of artificial intelligence, and its handling has forced the PHP Foundation into an uncommon exercise in self-criticism: it has acknowledged the structural failure of 2024, moved its security team from consensus to majority decisions, hired two more engineers and asked companies, hosting providers and governments to fund the work everyone depends on. Since early July, that small team has published fifteen CVEs and dismissed more than a hundred invalid or duplicate reports, many of them generated with the same tools that found PHP2Shell.

But the lesson of most interest to those working in security, law or forensic investigation lies in 20 October. A coordinated disclosure process is a pact of discretion among many people who do not know one another, and it only works if each of them understands that their silence protects millions of users who will never know their name. It took one person wanting to be first with the news, and others lending them credibility with the best of intentions, for the world to learn of the danger a day before it had the remedy.

Ryan Austin showed in August that one can claim credit for a finding without putting anyone at risk: he published a hash that said nothing and waited two and a half months. The author of the October post did exactly the opposite, and their information was not even correct. The whole ethics of vulnerability disclosure fits between those two gestures. In security, as in so many other trades, the most valuable contribution is sometimes knowing when to keep quiet.

Bibliografía y fuentes · References

Arghire, I. (2026, 21 de octubre). PHP2Shell: Mass exploitation looms for leaked critical PHP flaws. SecurityWeek. https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/

Arora, A., Krishnan, R., Telang, R., & Yang, Y. (2010). An empirical analysis of software vendors’ patch release behavior: Impact of vulnerability disclosure. Information Systems Research, 21(1), 115-132. https://doi.org/10.1287/isre.1080.0226

Austin, R. (2026). PHP2Shell. Calif. https://calif.io/php2shell

Bilge, L., & Dumitraş, T. (2012). Before we knew it: An empirical study of zero-day attacks in the real world. En Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS ’12) (pp. 833-844). ACM. https://doi.org/10.1145/2382196.2382284

Brumley, D., Poosankam, P., Song, D., & Zheng, J. (2008). Automatic patch-based exploit generation is possible: Techniques and implications. En 2008 IEEE Symposium on Security and Privacy (pp. 143-157). IEEE. https://doi.org/10.1109/SP.2008.17

Cavusoglu, H., Cavusoglu, H., & Raghunathan, S. (2007). Efficiency of vulnerability disclosure mechanisms to disseminate vulnerability knowledge. IEEE Transactions on Software Engineering, 33(3), 171-185. https://doi.org/10.1109/TSE.2007.26

Constantin, A. M. (2026, 21 de octubre). PHP knew about one of the flaws in 2024 but could not agree a fix. The Next Web. https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak

Durumeric, Z., Li, F., Kasten, J., Amann, J., Beekman, J., Payer, M., Weaver, N., Adrian, D., Paxson, V., Bailey, M., & Halderman, J. A. (2014). The matter of Heartbleed. En Proceedings of the 2014 Conference on Internet Measurement Conference (IMC ’14) (pp. 475-488). ACM. https://doi.org/10.1145/2663716.2663755

Gooding, S. (2026, 21 de octubre). PHP Foundation says Chainguard broke security embargo ahead of emergency patches. Socket. https://socket.dev/blog/php-embargo-dispute

Hadrian. (2026, 21 de octubre). php2shell: Leaked critical PHP RCEs (CVE-2026-109618, -109619). https://hadrian.io/vulnerability-alerts/php2shell-leaked-critical-php-rce-cve-2026-109618-cve-2026-109619

Householder, A. D., Wassermann, G., Manion, A., & King, C. (2017). The CERT guide to coordinated vulnerability disclosure (CMU/SEI-2017-SR-022). Software Engineering Institute, Carnegie Mellon University. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330

Insurance Business. (2026, 21 de octubre). UK councils and Met Police among sites pulled offline after NCSC alert. https://www.insurancebusinessmag.com/uk/news/cyber/uk-councils-and-met-police-among-sites-pulled-offline-after-ncsc-alert-594424.aspx

International Organization for Standardization. (2018). ISO/IEC 29147:2018. Information technology. Security techniques. Vulnerability disclosure. ISO.

Li, F., & Paxson, V. (2017). A large-scale empirical study of security patches. En Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS ’17) (pp. 2201-2215). ACM. https://doi.org/10.1145/3133956.3134072

Moses, C. J. (2026, 21 de octubre). Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

Paperjam. (2026, 21 de octubre). PHP2Shell: Thousands of websites exposed in Luxembourg. https://en.paperjam.lu/article/php2shell-thousands-of-websites-exposed-in-luxembourg

PHP Group. (2026a, 20 de octubre). Upcoming critical PHP security release. https://www.php.net/archive/2026.php

PHP Group. (2026b, 21 de octubre). Security advisory: Critical remote code execution vulnerabilities, update now. https://www.php.net/archive/2026.php

PHP Group. (2026c, 23 de octubre). Informational advisory: Session upload progress. https://www.php.net/archive/2026.php

PHP Security Team. (2026a). RCE via OOM corruption (CVE-2026-109618, GHSA-w8hw-w9fx-j79w). GitHub. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

PHP Security Team. (2026b). RCE via stale global state (CVE-2026-109619, GHSA-6wmf-4rv5-p3rp). GitHub. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

Pillitteri, P. (2026, 21 de octubre). PHP2Shell, Netherlands and Finland switch off government sites before the patch. https://pasqualepillitteri.it/en/news/26110/php2shell-netherlands-finland-switch-off-government-sites-before-patch

Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales (Reglamento de Ciberresiliencia). Diario Oficial de la Unión Europea, L, 20 de noviembre de 2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

Directiva (UE) 2022/2555 del Parlamento Europeo y del Consejo, de 14 de diciembre de 2022, relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión (Directiva SRI 2). Diario Oficial de la Unión Europea, L 333, 80-152. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Ley 1/2019, de 20 de febrero, de Secretos Empresariales. Boletín Oficial del Estado, 45, de 21 de febrero de 2019. https://www.boe.es/eli/es/l/2019/02/20/1/con

Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal. Boletín Oficial del Estado, 281, de 24 de noviembre de 1995. https://www.boe.es/eli/es/lo/1995/11/23/10/con

The PHP Foundation. (2026, 21 de octubre). Today’s PHP security release, and how we’re strengthening PHP security. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

Threat Landscape. (2026, 20 de octubre). PHP core RCEs CVE-2026-109618 and CVE-2026-109619 leak early. https://threatlandscape.io/blog/php-core-rce-cve-2026-109618-109619-leak-ahead-of-embargo

Tzadik, S., Tamari, S., Ohfeld, N., & Schwartz, T. (2026, 21 de octubre). PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. Wiz Blog. https://www.wiz.io/blog/php2shell-php-rce

Créditos de las imágenes · Image credits

Portada / Cover: Blue Open Goodies ElePHPant. Fotografía de Atomic Taco (Seattle, EE. UU.), CC BY-SA 2.0, vía Wikimedia Commons. Recortada a 850 × 478 px. https://commons.wikimedia.org/wiki/File:Blue_Open_Goodies_ElePHPant_(23626304652).jpg

Logotipo de PHP / PHP logo: Colin Viebrock, dominio público, vía Wikimedia Commons. https://commons.wikimedia.org/wiki/File:PHP-logo.svg

Código PHP / PHP code: lmonk72, CC0, vía Wikimedia Commons. https://commons.wikimedia.org/wiki/File:Codigo_php.jpg

Cronología / Timeline: esquema propio de Actum Forense Press / own diagram by Actum Forense Press.