Mil cuatrocientas horas, y los sitios ya a oscuras
La cita era precisa, y no es así como suelen anunciarse las emergencias. El miércoles 21 de octubre de 2026, a las 14:00 UTC, PHP publicaría una actualización de seguridad para dos vulnerabilidades críticas. La hora se colgó en la propia lista de anuncios del lenguaje, la recogieron investigadores, quedó anotada en un mensaje de Dane Knecht y la repitieron medios que pedían a los administradores que se prepararan. Huntress, en una nota de respuesta rápida, habló de fallos críticos filtrados y les puso número: CVE-2026-109618 y CVE-2026-109619. PC Gamer, un cronista improbable para una crisis de runtime, dijo a los administradores web que aguantaran y que esperaran actualizaciones de emergencia capaces de taponar exploits filtrados.
Cuando llegó esa hora, una parte de la web ya había elegido la oscuridad. Varios sitios importantes habían sido sacados de línea por una vulnerabilidad crítica en PHP. La BBC informó de webs retiradas en todo el mundo mientras se emitía la actualización de ciberseguridad. No son exactamente la misma afirmación que el consejo que viajó con ellas, y la diferencia conviene conservarla. Las autoridades de Estados Unidos, Europa y el Reino Unido recomendaron que los sitios se desconectaran de forma temporal hasta poder corregirse. Una recomendación no es una caída. Una caída, en el relato del Brussels Times y en el de la BBC, ya era el hecho del día: sitios fuera de línea en medio del miedo a la seguridad, sitios retirados mientras salía la actualización. Desde fuera, el cuadro era un parche con cita previa y una web que había empezado a apagarse antes de que pudiera decirse que los paquetes habían aterrizado.
En Japón el apagón tenía nombres. Gigazine informó de que NicoNico, pixiv y otros sitios y aplicaciones habían entrado en mantenimiento para llegar al parche de emergencia. ITmedia registró mantenimiento de urgencia en CoDMon, Shadowverse: Worlds Beyond, el servidor de alquiler de Sakura, BASE, pictSQUARE, 킴블, X Server y つなぐ. Nada en esos avisos, con el material que hay aquí, es una confesión de que un intruso ya estaba dentro. Se leen como un juicio: ser alcanzable, en las horas alrededor de la corrección, se había convertido en el estado más arriesgado. El equipo de seguridad de PHP había advertido a los administradores el día anterior de que se prepararan para actualizaciones de emergencia que abordaban dos vulnerabilidades críticas. El equipo anunció el hallazgo de dos fallos graves, y los parches quedaron fijados para el 21 de octubre. Los mantenedores los planearon para vulnerabilidades con una gravedad de 9,2 sobre 10.
Cuando se publicaron los paquetes, tenían versión. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación. El National Cyber Security Centre y la BBC enmarcaron la actualización en los términos más amplios disponibles: un problema crítico que puede permitir a los atacantes ejecutar órdenes en cualquier servidor web que corra PHP. El episodio ya tenía nombre, PHP2Shell, y el nombre hacía el trabajo de un titular. Lo usó Watchtowr. Lo usó Huntress. Lo usó Amazon para un intento de explotación. Lo usó Wiz para un hallazgo de investigación en el núcleo del lenguaje.
La historia pública era una publicación controlada a una hora anunciada. La historia de la telemetría era un intento que no esperó al anuncio.
Amazon Threat Intelligence identificó un intento de explotación de PHP2Shell en la telemetría de MadPot fechado el 17 de octubre de 2026, cuatro días antes de la divulgación pública de esas dos CVE. Entre la lista de anuncios y esa telemetría cabe la inquietud de la semana. Quienes responden del lenguaje habían puesto un reloj. No era el único que corría.
Dos caminos, y un desacuerdo sobre la anchura
Las vulnerabilidades, tal como las identificó el propio archivo de noticias de PHP, no son un mismo fallo descrito dos veces. CVE-2026-109618 es ejecución remota de código mediante corrupción por falta de memoria. CVE-2026-109619 es ejecución remota de código mediante estado global obsoleto. El impacto confirmado, en el relato que examinó el problema de falta de memoria, es la ejecución remota de código sin autenticación como la cuenta del worker web. Esa última cláusula hace un trabajo silencioso. No es una afirmación documentada de control total de una máquina. Es la afirmación de que el código se ejecuta, sin inicio de sesión, como la cuenta que el servidor web ya usa para hacer su trabajo. En muchísimos sitios, esa cuenta es el trabajo.
El fallo de estado obsoleto tiene una forma que puede enunciarse sin convertirla en un procedimiento. PHP contiene diversos estados globales —de error, de sesión, de objeto y de extensión— que retiene un worker pero que apuntan a memoria propiedad de una sola petición. Un worker, en este arreglo, sobrevive a la petición que lo llenó. La memoria, no. Lo que la vulnerabilidad hace de ese desajuste es, en los términos del archivo, ejecución remota de código. El otro fallo llega a un destino parecido por la vía llamada corrupción por falta de memoria. Dos mecanismos, una clase de resultado y una sola publicación de emergencia pensada para cerrar ambos.
El riesgo, dijo el archivo, es máximo para mod_php, con un exploit demostrado en el que una petición no autenticada puede disparar el ataque antes de que se ejecute código alguno de la aplicación. Esa es la frase que un operador lee dos veces. Un fallo que espera a un rincón concreto de una aplicación puede triarse. Un fallo alcanzable por una petición no autenticada, antes de que la aplicación tenga ocasión de ser cuidadosa, es otra cola. Por eso una cifra de gravedad de 9,2 sobre 10, que Ars Technica señaló como la calificación de las dos vulnerabilidades que los mantenedores iban a parchear, no está en la página de adorno. Por eso el mensaje del equipo de seguridad fue prepararse para actualizaciones de emergencia al día siguiente, no buscar una ventana cómoda.
Hay una diferencia real en hasta dónde empujan las fuentes el radio de explosión, y conviene nombrarla en lugar de alisarla.
De un lado, la BBC y el National Cyber Security Centre enmarcaron la actualización como la respuesta a un problema crítico que puede permitir a los atacantes ejecutar órdenes en cualquier servidor web que corra PHP. «Cualquier» es una palabra grande. Es la palabra que convierte un fallo de runtime en algo más cercano a una contingencia civil. Del otro, el propio archivo del lenguaje fue más concreto sobre dónde se situaba el peligro demostrado: máximo para mod_php y alcanzable, en ese caso demostrado, antes de que corra el código de la aplicación. No son sinónimos corteses. Un lector puede sostener ambas cosas —una advertencia oficial amplia sobre servidores que ejecutan PHP y una declaración técnica más estrecha sobre dónde se ha demostrado que el riesgo es máximo— sin fingir que dicen lo mismo. El impacto confirmado sigue siendo la ejecución remota de código sin autenticación como la cuenta del worker web. Hasta dónde viaja esa confirmación, más allá de la configuración en la que se demostró, es la discusión que los avisos del día no se detuvieron a zanjar. Parchearon, y dijeron a la gente que considerara desconectarse mientras lo hacían.
La pregunta de las versiones tiene un borde igual de inacabado. Se cree que las vulnerabilidades afectan a PHP 5, 6, 7 y 8: se cree, no se confirma con ceremonia en cada línea, y esa creencia la sostienen Watchtowr, BleepingComputer, la propia nota de publicación de seguridad de PHP y Huntress. Las versiones nombradas como corrección de los dos fallos críticos son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las fuentes reunidas aquí no trazan un mapa completo de lo que, el 21 de octubre, estaba disponible para cada línea antigua que los investigadores creen afectada. Lo que sí trazan es un hueco en el papeleo: una creencia sobre el alcance que se remonta a 5, 6 y 7, y una lista de correcciones que, en el archivo y en la nota de distribución, es una lista de versiones puntuales de 8.x. Para un administrador en un 8.2, 8.3, 8.4 u 8.5 actuales, la instrucción era concreta. Para quien siguiera más atrás, el registro público de este episodio es una advertencia sin, en estas fuentes, un número de versión que le corresponda.
Wiz Research destapó múltiples vulnerabilidades críticas en el núcleo de PHP y cifró la exposición en el 70 por ciento de todos los sitios web del mundo. El Australian Financial Review, al informar de que la inteligencia artificial había destapado fallos críticos en el lenguaje que usan la mayoría de los servidores web, empleó la misma proporción: el 70 por ciento de los sitios del mundo en riesgo. Este relato no tiene censo propio. La cifra pertenece a esos dos relatos, y es la cifra frente a la cual el comportamiento del día se vuelve inteligible. Si siquiera una fracción seria de esa cuota fuera cierta, un camino no autenticado hacia la ejecución de código en el worker no sería una historia de especialistas. Sería motivo para que un departamento gubernamental pasara la mañana al teléfono, que es lo que describe la información australiana.
Un fallo de 2024, un acuerdo de 2026
La emergencia tiene una prehistoria, y es la parte menos favorecedora del expediente.
La PHP Foundation encontró un fallo crítico en 2024, pero no logró acordar una corrección hasta 2026. El relato de The Next Web es concreto sobre la estrechez de esa frase: PHP conocía uno de los fallos en 2024, y el obstáculo no era la ignorancia. Era el acuerdo. Las fuentes no dicen cuál de las dos CVE de octubre era ese hallazgo, ni quién defendió qué remedio, ni qué habría costado una corrección rechazada. Dicen que se encontró un fallo crítico, que no pudo acordarse una corrección y que el acuerdo tardó hasta 2026.
Dos años es mucho tiempo para dejar un fallo crítico en un lenguaje que Wiz y el Australian Financial Review asocian ambos con unos siete de cada diez sitios web. Es más cuando la publicación final no es una versión puntual programada con quince días de aviso, sino un parche de emergencia, anunciado para un miércoles por la tarde en UTC, con los administradores avisados el día anterior de que estuvieran listos. La distancia entre «lo hemos encontrado» y «hemos acordado cómo cerrarlo» es, en el software ordinario, una discusión de taller. En un runtime tan incrustado, según esos relatos, la misma distancia es una ventana de exposición pública. El expediente de octubre no prueba qué atravesó esa ventana. Sí muestra que la ventana era real y que, a mediados de mes, ya no era solo un asunto de gobernanza.
Hay la tentación de tratar la falta de acuerdo como una moraleja. El material no sostiene la moraleja en detalle. Sí sostiene una cronología. Un fallo crítico, conocido por la Foundation en 2024. Ninguna corrección acordada hasta 2026. Luego, en unos días de octubre, un racimo de cosas que suelen llegar en secuencia llegó casi encima unas de otras: una divulgación de investigación asociada a Wiz, y a informaciones que atribuían el mérito a la inteligencia artificial; un aviso del equipo de seguridad; una hora publicada; parches para cuatro líneas de versión vigentes; y, ya en la telemetría de un proveedor de nube, un intento de explotación fechado el 17 de octubre, antes de la divulgación pública de los dos números CVE.
La filtración, si esa es la palabra, es en sí un encuadre documentado y no un mecanismo zanjado. Huntress tituló vulnerabilidades críticas filtradas. PC Gamer escribió de exploits filtrados y de administradores preparándose para las actualizaciones que los taponarían. El anuncio oficial era el de una próxima publicación crítica de seguridad, fijada para el 21 de octubre a las 14:00 UTC. Nada en estas fuentes describe cómo se produjo filtración alguna, quién tenía los detalles o si el intento del 17 de octubre usó la misma información que investigadores y titulares llamarían después filtrada. Lo que las fuentes permiten es una afirmación más dura y más pequeña. El intento precede a la divulgación pública. La divulgación pública se gestionó como una emergencia con reloj. Y al menos uno de los fallos de fondo estaba dentro del conocimiento de la Foundation, sin resolver por acuerdo, desde 2024.
No es que no lo vieran. En uno de los fallos, no lograron acordar una corrección: de 2024 a 2026.
Esa distinción cambia el tipo de tranquilidad que puede ofrecer un parche. Un fallo hallado el lunes y corregido el miércoles es un proceso que trabaja a velocidad. Un fallo hallado en 2024 y publicado, en condiciones de emergencia, en octubre de 2026 es un proceso que acabó funcionando, después de un retraso que, según el relato de The Next Web, el consenso no pudo cerrar. Los parches del 21 de octubre no borran el retraso. Lo terminan.
Conviene fijarse en qué clase de publicación fue esta, una vez que por fin llegó el acuerdo. No un commit discreto. Una actualización de seguridad con hora publicada, anunciada en la lista, lo bastante grave como para que el equipo de seguridad dedicara el día anterior a decir a los administradores que se prepararan, y lo bastante grave como para que las calificaciones de los dos fallos se situaran en 9,2 sobre 10. La propia nota de PHP de ese día lleva, en el título, la promesa de explicar cómo el proyecto está reforzando su seguridad. El contenido de cualquier reforma más larga queda fuera de estas fuentes. El hecho de la emergencia, no. Lo visible, en el material que de verdad se tiene a mano, es la decisión de publicar, a una hora con nombre, correcciones para dos fallos que el proyecto ya no estaba dispuesto a dejar hasta una versión conveniente.
El día en que la web ordinaria se apagó sola
Las caídas suelen narrarse desde fuera: un sitio falla, un usuario lo nota, una página de estado se pone al día. Esta, en varios lugares, se narró como una elección.
El Brussels Times informó de que sitios importantes se desconectaban mientras la vulnerabilidad disparaba temores de seguridad, y la afirmación de fondo es directa. Varios sitios importantes fueron sacados de línea por una vulnerabilidad crítica en el lenguaje. La escala de la BBC era aún más amplia: webs retiradas en todo el mundo mientras se emitía la actualización de ciberseguridad. Ninguno de los dos relatos detalla el método —qué se detuvo, quién lo hizo, durante cuánto tiempo— y sería ficción suplir las operaciones que faltan. Fijan la causa en el problema de PHP. Fijan la respuesta, en la información de más de un país, como ausencia y no como un hotfix aplicado en silencio.
El consejo oficial dio a esa elección un patrocinador. Las autoridades de Estados Unidos, Europa y el Reino Unido recomendaron que los sitios se desconectaran de forma temporal hasta poder corregirse. Cuesta exagerar lo rara que es esa frase como la responsable. Sacar un sitio de línea es, en tiempos ordinarios, el resultado que quiere un atacante y teme un operador. Aquí, tres conjuntos de autoridades trataron la ausencia temporal como el estado más seguro, mientras la corrección no estuviera aplicada. El aviso del National Cyber Security Centre sobre un problema crítico de seguridad que afecta a PHP está en el mismo clima, aunque este expediente no cite al Centre como emisor de la recomendación de desconexión en esas palabras. Aquello para lo que se cita al Centre, junto a la BBC, es la sustancia: un problema crítico que puede permitir a los atacantes ejecutar órdenes en cualquier servidor web que corra PHP, y una actualización de seguridad publicada para abordarlo.
La versión australiana de la mañana fue una carrera por parchear. El Australian Financial Review informó de que la inteligencia artificial había destapado fallos críticos en el lenguaje de programación que usan la mayoría de los servidores web, y de que organismos del Gobierno se afanaban en parchear vulnerabilidades en sitios web. Ese detalle saca la historia del teatro habitual de las caídas de consumo. Que servicios con nombre pasen a mantenimiento es un tipo de daño: un público que no puede llegar a algo que usa sin pensarlo. Que un organismo público parchee a toda prisa es otro. El mismo lenguaje, incrustado en sitios que no son opcionales del mismo modo. El marco del AFR era la cifra del 70 por ciento, y el descubrimiento. El marco operativo era más simple. El fallo estaba en el lenguaje. El lenguaje estaba en los sitios. Los sitios tenían que moverse.
Japón aporta la lista más concreta y, por tanto, el correctivo más útil a la abstracción. Es fácil decir «la web» y referirse a un diagrama. Es más difícil descartar un aviso de mantenimiento que nombra CoDMon, Shadowverse: Worlds Beyond, el servidor de alquiler de Sakura, BASE, pictSQUARE, 킴블, X Server y つなぐ. Súmense NicoNico y pixiv, como hizo Gigazine, y la lista deja de ser una metáfora. El alojamiento es el multiplicador que se esconde en esos nombres. Una vulnerabilidad en una sola aplicación es una vulnerabilidad en esa aplicación. Una vulnerabilidad en el lenguaje, en un servidor de alquiler o en X Server, es una cola de clientes que no eligieron el fallo y que no pueden, en ningún sentido significativo, parchearlo por su cuenta. Estas fuentes no cuentan a esos clientes. Muestran a los anfitriones tratando el parche como lo bastante urgente para llevar el servicio a un mantenimiento de emergencia.
El equipo de seguridad había pedido preparación, y los tiempos muestran la forma de lo que se pedía. El aviso era prepararse para actualizaciones de emergencia al día siguiente. La publicación quedó fijada para las 14:00 UTC del día 21. Los parches, una vez distribuidos, fueron las cuatro versiones puntuales ya nombradas. Lo que llenó las horas alrededor de esa cita no fue, en este expediente, un apagón único y coordinado. Fue un mosaico: unos sitios fuera de línea en medio del miedo a la seguridad, otros retirados mientras salía la actualización, otros puestos en un mantenimiento con nombre, otros recorridos a toda prisa por organismos del Gobierno australiano cuyo problema era el propio parche. El elemento común es el lenguaje, y el juicio de que esperar a una tarde conveniente ya no era la opción conservadora.
La gravedad ayuda a explicar el juicio sin disolverlo. Dos vulnerabilidades, cada una con una calificación de 9,2 sobre 10, no es un emparejamiento que invite a un despliegue escalonado en un fin de semana tranquilo. Un alcance no autenticado, en el caso demostrado de mod_php, antes de que corra el código de la aplicación, no es un emparejamiento que invite a confiar en las comprobaciones que una aplicación pudiera hacer después. Póngase eso junto a un aviso de que el problema puede permitir la ejecución de órdenes en cualquier servidor web que corra PHP, y el consejo de desconectarse hasta corregirlo deja de parecer teatro. Parece la opción residual, una vez entendido que el fallo está en el runtime y no en un rincón que un operador pueda simplemente apagar.
Nada de esto exigía que las vulnerabilidades fueran nuevas para todo el mundo. Exigía que fueran de pronto innegables. El conocimiento de la Foundation en 2024, y su incapacidad para acordar una corrección hasta 2026, pertenece al mismo aliento que los avisos de mantenimiento. Los sitios que se apagaron el 21 de octubre vivían dentro de un retraso sobre el que no votaron. Ese es el hecho político dentro de un hecho de ingeniería de versiones. Un lenguaje usado, según el relato de Wiz y del AFR, por algo así como el 70 por ciento de los sitios del mundo no es una base de código privada, aunque su gobernanza sea una discusión privada. El coste de una corrección no acordada lo pagan quienes no asisten a la reunión.
Quién lo sabía, y quién ya lo intentaba
Hay dos primeros en esta historia, y responden a preguntas distintas.
Wiz Research destapó múltiples vulnerabilidades críticas en el núcleo de PHP. El relato de la compañía, y el del Australian Financial Review, sitúan ambos a la inteligencia artificial en el descubrimiento. Wiz enmarcó el hallazgo como una IA que destapa vulnerabilidades críticas de ejecución remota de código que afectan al 70 por ciento de internet. El AFR informó de que la IA había descubierto un fallo que ponía en riesgo al 70 por ciento de los sitios del mundo, y de que organismos del Gobierno australiano se afanaban. Cómo se usó modelo alguno, qué se le mostró, qué tuvo aún que demostrar un investigador humano: nada de eso está en el material de aquí, y sería ficción suplirlo. Lo que sí está es la atribución. Un esfuerzo de investigación asociado a Wiz, y descrito en más de un lugar como obra de la IA, sacó a la luz múltiples fallos críticos en el núcleo del lenguaje. Según ese relato, no era una mala configuración en una extensión popular. Era PHP mismo.
El otro primero no es un descubrimiento. Es un intento. Amazon Threat Intelligence identificó un intento de explotación de PHP2Shell fechado el 17 de octubre de 2026, en la telemetría de MadPot, cuatro días antes de la divulgación pública de CVE-2026-109618 y CVE-2026-109619. Un intento no es un censo de intrusiones. Estas fuentes no dicen cuántos servidores respondieron, qué se llevó ni si el intento tuvo éxito de forma duradera. Dicen que se identificó, que se fechó el día 17 y que la divulgación pública de las dos CVE llegó cuatro días después. En una semana de afirmaciones grandes —cualquier servidor web, el 70 por ciento de los sitios, retiradas en todo el mundo— la frase de Amazon es casi austera, y es la que más cambia la temperatura. Alguien no esperaba a las preguntas frecuentes.
Puesta en plano, la secuencia es esta. Un fallo crítico conocido por la Foundation desde 2024, sin corrección acordada. Un intento de explotación el 17 de octubre de 2026, visto en la telemetría MadPot de Amazon. Un aviso del equipo de seguridad de PHP para prepararse para actualizaciones de emergencia al día siguiente. Una publicación anunciada a las 14:00 UTC del 21 de octubre, recogida en php.announce y corroborada por Huntress, por el relato de PC Gamer sobre administradores que se preparaban y por el mensaje de Dane Knecht. Parches distribuidos el mismo día, como 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que cierran dos vulnerabilidades críticas que permiten la ejecución remota de código sin autenticación. Alrededor de esa distribución: sitios fuera de línea, sitios en mantenimiento, organismos afanándose, autoridades que recomendaban la oscuridad como control temporal.
Lo que esta cronología no sostiene es una sola trama que vaya de un desacuerdo de 2024 a una sonda del 17 de octubre. Nada aquí conecta el fracaso inédito de la Foundation para acordar con el intento de MadPot, ni ese intento con la divulgación de la investigación, ni la divulgación con un operador con nombre. El cuadro honesto es el de varios relojes, no el de una conspiración. Un reloj de gobernanza que corrió dos años. Un reloj de investigación que terminó en un destape público atribuido a Wiz y a la IA. Un reloj defensivo puesto, muy a propósito, a las 14:00 UTC de un miércoles. Y un reloj ofensivo que, según el relato de Amazon, ya había sonado el día 17.
El encuadre del exploit filtrado se sienta con torpeza entre esos relojes, y la torpeza debe quedar a la vista. Si Huntress y PC Gamer tienen razón en que las vulnerabilidades, o los exploits, se habían filtrado, entonces la publicación de emergencia es en parte una respuesta a la pérdida de control sobre la información, no solo una respuesta a un fallo. Si la lista de anuncios se lee sola, la publicación es una actualización crítica de seguridad planificada, con hora de inicio. Ambas cosas pueden ser ciertas: un plan, y un plan conducido allí donde otros ya describían una filtración. Las fuentes no arbitran. Muestran a un proyecto eligiendo una hora pública, a investigadores describiendo fallos filtrados y a los sensores de un proveedor de nube registrando un intento antes de que los números CVE fueran públicos. Basta para rechazar la versión reconfortante, en la que lo primero que oyó alguien de fuera sobre los fallos fue un aviso pulido y un juego de paquetes.
También basta para ser cuidadoso con el éxito. «Intento de explotación» es la frase que sostiene el relato de Amazon. «Puede permitir» es la frase unida a la ejecución de órdenes en cualquier servidor web que corra PHP. «Demostrado» es la palabra que usa el archivo de PHP para la vía de mod_php, donde una petición no autenticada puede disparar el ataque antes de que corra el código de la aplicación. El «impacto confirmado» es la ejecución remota de código sin autenticación como la cuenta del worker web. Apiladas sin cuidado, esas frases se convierten en la sensación de un compromiso general ya consumado. Leídas como están escritas, son más precisas, y la precisión es la noticia. Hay una vía demostrada. Hay una clase confirmada de impacto. Hay un intento registrado antes de la divulgación. Hay una advertencia lo bastante amplia para cubrir cualquier servidor que ejecute el lenguaje. No hay, en este material, un recuento publicado de intrusiones.
Lo que pueden cerrar cuatro números de versión
Los paquetes son la parte de la historia con números de versión, y los números de versión son una merced. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código sin autenticación. Cuatro ramas, cuatro versiones puntuales, una tarde. Para los operadores de esas ramas, la emergencia tenía un final que podía descargarse. La actualización de seguridad no solo se prometió a las 14:00 UTC. Se publicó, para abordar un problema crítico que puede permitir a los atacantes ejecutar órdenes en cualquier servidor web que corra PHP. Esa es la frase que el National Cyber Security Centre y la BBC dejan en el expediente, y es la frase frente a la cual se abrieron las ventanas de mantenimiento, y frente a la cual pueden cerrarse.
Lo que los paquetes no cierran de forma automática es la discusión sobre el alcance.
No responden, a la vista de estas fuentes, al administrador cuyo PHP es 7, o 5, o 6, todos ellos dentro del conjunto de versiones que se cree afectadas. Una creencia no es un parche. La creencia está bien atestiguada: cuatro fuentes, entre ellas la propia escritura de publicación de seguridad del proyecto y unas preguntas frecuentes especializadas de Watchtowr. Las correcciones que se nombran no son un conjunto equivalente. Fingir lo contrario, por el bien de un final limpio, sería inventar un backport que estos racimos no contienen. El enunciado limpio es el desordenado. Los 8.2, 8.3, 8.4 y 8.5 actuales tienen correcciones con nombre. Las líneas más antiguas están, a juicio de esas cuatro fuentes, dentro del radio de explosión que se cree, y este expediente se detiene ahí.
Tampoco disuelven los paquetes la diferencia entre «cualquier servidor web que corra PHP» y «máximo para mod_php». Un operador cuya instalación no es la que el archivo marcó como de máximo riesgo puede leer la advertencia oficial y la nota técnica y no saber cuál gobierna la noche. El caso demostrado del archivo es aquel en el que una petición no autenticada dispara el ataque antes de que se ejecute código alguno de la aplicación, y une esa demostración a mod_php como el riesgo máximo. La advertencia más amplia no espera a la distinción. Las autoridades de Estados Unidos, Europa y el Reino Unido recomendaron un estado temporal fuera de línea hasta que los sitios pudieran corregirse, y esa recomendación no se lee como limitada a un solo módulo de servidor. Si hay una disputa en este episodio, no es un cruce de gritos entre proveedores. Es esta: una descripción institucional amplia de quién está expuesto, y una descripción técnica más estrecha de dónde se ha mostrado el peligro en su punto máximo, publicadas en la misma semana, sobre las mismas dos CVE. Ambas están en el expediente. Ninguna anula a la otra.
El enunciado de impacto tiene su propio límite, y el límite conviene conservarlo. El impacto confirmado es la ejecución remota de código sin autenticación como la cuenta del worker web. Eso es grave, y es específico. La ejecución de órdenes, en la formulación de la BBC y del NCSC, es el poder del que se advierte. La cuenta nombrada en la confirmación del impacto es la del worker. Un lector cuidadoso no cambia una por la otra al alza. La ejecución de código como el worker basta, en la afirmación documentada, para importar enormemente: son las propias manos del sitio. No es, con esta evidencia, una afirmación documentada de control automático más allá de esa cuenta. El miedo del día estaba calibrado a la afirmación que las fuentes hacen de verdad, y esa afirmación ya bastaba para vaciar portadas y para justificar, a juicio de tres conjuntos de autoridades, una desaparición temporal.
Hay un límite más alrededor de la palabra «intento». Amazon vio un intento de explotación de PHP2Shell el 17 de octubre, antes de la divulgación. Los parches del día 21 no pueden dejar de verlo. Pueden cerrar los fallos que un intento así habría necesitado, en las versiones que cubren, para los operadores que los apliquen. No pueden decir cuántos intentos de ese tipo no se vieron nunca, ni cuántos tuvieron éxito en lugares sin una telemetría del tipo de MadPot. La ausencia de una lista de víctimas en estas fuentes no es prueba de una semana tranquila. Es prueba de que este expediente trata del fallo, de la corrección, del consejo y de un intento identificado, no de una contabilidad acabada del daño.
Y está el límite alrededor de 2024. Los parches acuerdan una corrección. No explican el desacuerdo que retrasó una. El hallazgo de The Next Web permanece como la estática bajo las notas de publicación: uno de los fallos se conocía en 2024; no pudo acordarse una corrección hasta 2026; el acuerdo, cuando llegó, llegó como una emergencia, anunciada el día anterior y calificada con 9,2 sobre 10. Quien quiera una historia de sprint desde el descubrimiento hasta el parche tendrá que poner en marcha el reloj en octubre. Quien lo ponga donde lo pone The Next Web verá una discusión de dos años, y después un miércoles.
PHP2Shell es un nombre bastante bueno para una semana. Es un mal nombre para la condición que la semana dejó al descubierto. La condición es que un fallo en este lenguaje puede ser conocido, y no acordado, y de pronto de todos; que el parche, cuando llega, puede ser real y aun así no cubrir, en las fuentes que tenemos, cada versión que los investigadores creen dentro del alcance; que la advertencia oficial y la nota técnica pueden ser ambas cuidadosas y aun así no decir lo mismo. La instrucción sensata, durante un día, no era ser más listo que el fallo. Era estar fuera de línea hasta que los paquetes con esos cuatro números dejaran de ser una promesa para las 14:00 UTC y fueran un archivo que de verdad se había distribuido.
La web, en los relatos de aquel miércoles, no se cayó sola. Partes de ella se pusieron a dormir a propósito, por operadores y anfitriones que habían leído el aviso y preferían una página de mantenimiento a un worker ejecutando las órdenes de otro. No es una historia pequeña sobre una versión puntual. Es la historia de cuánta vida ordinaria cabe ya dentro de un proceso PHP —una cuota que Wiz y el Australian Financial Review sitúan ambos cerca del 70 por ciento de los sitios del mundo— y de lo poco que queda de margen cuando un worker ya no puede confiarse para impedir que la memoria de una petición persista como el estado de la siguiente. La corrección, en las líneas que cubre, son cuatro números de versión y una tarde. El retraso que convirtió la tarde en emergencia duró dos años.