La IA desentierra vulnerabilidades de PHP ocultas durante más de una década y la ciberseguridad ya no volverá a ser la misma

Autor: Kazk

Anoche, probablemente fue una pesadilla para la ciberseguridad.

Y también una noche en vela para muchos ingenieros.

Solo puedo decir que, con la aceleración de la IA, toda nuestra era y sociedad se están volviendo cada vez más abrumadoras.

La cosa fue así.

Primero, anteayer, es decir, la noche del 20 de octubre, pasadas las 11, apareció de repente un hilo en Hacker News.

El titular era aterrador: decía que dos vulnerabilidades de ejecución remota de código en PHP con CVSS 10.0 estaban a punto de hacerse públicas.

El autor escribió que, aparte de la "fuente: confía en mí" (trust me, bro), no tenía ninguna prueba, e incluso adjuntó los números de las vulnerabilidades.

Pero claro, este tipo de hilos se ven cientos al día en internet y nadie se los toma en serio.

Sin embargo, este fue confirmado unas horas después por una empresa de seguridad llamada watchTowr. Sus palabras textuales fueron: "Se suponía que todos debíamos esperar hasta el jueves".

Ahí la cosa se puso incómoda, porque esta vulnerabilidad es enorme y ya estaba en estado de filtración. Cualquiera con malas intenciones ya podía empezar a explotarla, pero la actualización de seguridad oficial de PHP todavía estaba empaquetándose. Estaba prevista para la noche del 22, pero de repente había una ventana de dos días. Si la vulnerabilidad se explotaba y se lograba un ataque en esos dos días, las consecuencias serían inimaginables.

Poco más de una hora después, el equipo oficial de PHP publicó apresuradamente un aviso: la actualización de seguridad prevista para el 22 de octubre se adelantaba a la noche del 21 a las 10 (hora de Pekín), para reducir el tiempo al máximo.

Y justo después de publicarse el aviso oficial, ocurrió algo aún más disparatado.

Una empresa de seguridad que participó en el descubrimiento de estas dos vulnerabilidades, llamada Calif, publicó sin querer un vídeo de demostración del ataque en internet, lo que demuestra que este mundo es un gran desastre.

En el vídeo mostraban cómo explotar estas vulnerabilidades para ejecutar con éxito programas de verificación de ataques en múltiples objetivos. Aunque el vídeo se eliminó rápidamente, no hubo forma: alguien con reflejos ya lo había guardado y empezó a difundirlo masivamente en las comunidades.

Y ya está.

Antes solo se sabía que había dos vulnerabilidades graves, sin saber siquiera cómo atacarlas. Ahora, hasta había un vídeo de demostración del ataque; solo faltaba un tutorial paso a paso.

Luego, con las aceleraciones disparatadas de la IA, los investigadores de seguridad empezaron a reproducir el ataque a toda velocidad, y en internet comenzaron a aparecer todo tipo de códigos que supuestamente podían explotar las vulnerabilidades.

Y en ese momento, faltaban 16 horas para que el parche que podía corregir las vulnerabilidades de seguridad estuviera disponible para su descarga oficial por parte de todos.

Dieciséis horas de vida o muerte. Antes, una persona malintencionada quizá no habría podido lanzar un ataque a gran escala en tan poco tiempo, pero ahora, en la era de la IA, 16 horas parece demasiado tiempo para quienes se han acelerado con IA.

Aún más disparatado: a las 3:41 de la tarde del 21, una empresa que hace imágenes de contenedores publicó la imagen ya parcheada más de 6 horas antes de la hora acordada. La Fundación PHP se puso a criticar directamente: "Ignoraron semanas de coordinación entre múltiples partes".

Porque hoy en día, alguien que entiende del tema puede coger el código antiguo y el nuevo y hacer que una IA los compare de forma bruta, y así saber directamente dónde está la vulnerabilidad. Usar IA para estudiar parches, usar IA para hacer ingeniería inversa de vulnerabilidades y usar IA para desarrollar programas de ataque.

Pero los administradores de una gran cantidad de sitios web normales todavía no tenían un paquete de actualización que pudieran instalar directamente, lo que significa que los atacantes tenían una ventaja injusta y salían con ventaja.

Entonces, llegó el colapso.

El día 21, el sistema de identidad digital de los Países Bajos, el sitio web del parlamento e incluso el sitio web del propio Centro Nacional de Ciberseguridad se cayeron uno tras otro.

El proveedor de servicios de TI del gobierno finlandés también cerró un lote de servicios. Una empresa estadounidense de software de recursos humanos, BambooHR, suspendió directamente el servicio y avisó a sus clientes de que las operaciones relacionadas con el pago de nóminas podrían verse afectadas. En Japón, niconico y pixiv entraron en mantenimiento de emergencia.

Como en Japón hay muchísimos sitios web en PHP, incluso Takaichi Sanae publicó en X recomendando una desconexión preventiva hasta la actualización de PHP de las 10 de la noche.

Una vulnerabilidad en un lenguaje de programación que hace que Takaichi Sanae tuitee en mitad de la noche y que los gobiernos de varios países desconecten el cable de red por iniciativa propia. Sinceramente, nunca había visto algo así.

Y así, el mundo fue dando tumbos y aguantó esas más de diez horas.

Nadie sabe qué obtuvo el lado oscuro durante esas horas.

A las 10 de la noche, se publicó la actualización de seguridad de PHP. Para estas dos vulnerabilidades graves, no había ninguna medida de mitigación completa; la actualización era la única opción segura.

Al mismo tiempo, OpenAI salió a reclamar el hallazgo: estas dos vulnerabilidades épicas de PHP fueron descubiertas con ayuda de GPT.

Y no las encontró un modelo nuevo, sino que se descubrieron hace unos meses con GPT-5.6 Sol. Así que ya os podéis imaginar que, si los modelos internos más potentes y aún no publicados de estas grandes empresas de modelos se pusieran a escanear, todas las infraestructuras de red del mundo probablemente tendrían problemas...

Además, OpenAI también publicó de urgencia una función para ayudarte a descubrir si tu sitio web podría verse afectado.

Aquí quiero que todos prestéis mucha atención: si tu propio sitio web usa PHP y aún no conoces estas noticias, en cuanto lo veas, actualiza la versión inmediatamente, inmediatamente, y espero que también lo difundas entre tus amigos.

Sé que mucha gente dirá: "¿No es solo una vulnerabilidad? ¿Por qué tanto alboroto?".

Pues creo que, para entender por qué esta vez se ha montado tanto revuelo y por qué la reacción mundial ha sido tan exagerada, primero hay que saber qué es PHP.

Yo tampoco soy ningún experto, solo puedo intentar explicarlo con el lenguaje que conozco.

Primero, probablemente todos sepamos que, cuando abres una página web en el navegador, el servidor tiene que calcular en el momento qué debe mostrar esa página, como quién eres, qué hay en el carrito de la compra, cuántos comentarios hay debajo de este artículo, etc. El programa que hace ese trabajo se llama backend.

Y PHP es uno de los lenguajes más utilizados para escribir backends.

Pero como es muy antiguo, muchas empresas ya no lo usan mucho en productos nuevos o stacks tecnológicos nuevos. Y, curiosamente, PHP siempre ha sido objeto de burla en los círculos de programadores: "PHP es el mejor lenguaje del mundo" lleva más de una década siendo un meme, y mucha gente piensa que es cosa del siglo pasado.

Pero a nivel mundial, los sitios web construidos con PHP siguen ocupando el 70%. Incluso en China, que es un poco más nuevo y donde Java es muy abundante, según datos de octubre de 2026, más de la mitad de los sitios web siguen estando construidos con PHP.

Todos se burlan de él, pero, sinceramente, todos dependen de él.

Los foros en los que te has registrado, la página de pago de una tienda pequeña, los sitios web de trámites de muchos gobiernos locales, el sistema de reembolso interno de una empresa y los paneles de administración de routers y NAS probablemente tengan algo funcionando con PHP.

Es como las viejas tuberías de agua bajo la ciudad: normalmente nadie se acuerda de ellas, pero en cuanto revientan, pueden causar un desastre.

Y esta vez, lo que ha reventado es el propio PHP.

Esta vulnerabilidad tiene un nombre: PHP2Shell. Shell es la línea de comandos del servidor; si la consigues, puedes considerar que prácticamente tienes el control de ese servidor. Así que el nombre es muy directo: de PHP, directo a tu servidor.

Incluye dos números: CVE-2026-109618 y CVE-2026-109619.

Un CVE se puede entender como el número de identidad de una vulnerabilidad, unificado a nivel mundial.

La gravedad se puntúa con CVSS, con un máximo de 10. La versión filtrada inicialmente tenía la puntuación máxima, pero al final se le dio un 9,2.

Para explicar bien estas dos vulnerabilidades, primero hay que hablar de un concepto que a todos nos duele últimamente:

La memoria.

Es decir, cuando un programa se ejecuta, tiene que "pedir prestada" memoria al sistema continuamente para almacenar datos temporales y luego "devolverla" cuando termina. El intérprete de PHP está escrito en C. C es rápido, pero el préstamo y la devolución siguen dependiendo de que el programador lleve las cuentas él mismo; al sistema le da igual.

Así que, en cuanto se equivoca en las cuentas, hay problemas.

La primera vulnerabilidad, CVE-2026-109619, se llama técnicamente "uso después de liberar" (use-after-free).

Pongamos un ejemplo: abres un hotel. El primer cliente viene a dejar el equipaje y el recepcionista mete sus cosas en la taquilla 18 y lo anota en el cuaderno.

Luego el cliente se va, la taquilla se vacía y se le asigna a una segunda persona.

El problema es que el recepcionista olvidó borrar la anotación anterior del cuaderno.

En cuanto la segunda persona mete sus cosas, el recepcionista coge la anotación antigua, va y abre la taquilla 18, creyendo que dentro está el equipaje de la primera persona.

Ahí viene el problema: puede ver las cosas de la segunda persona e incluso podría estropear lo que hay dentro.

El problema de PHP esta vez está en un lugar parecido: una memoria que ya se había devuelto se vuelve a usar para almacenar datos nuevos, pero PHP conserva la anotación antigua que apunta a la posición original.

Entonces, cree que está procesando los datos anteriores, pero en realidad se encuentra con otros datos completamente distintos. Por eso, si un atacante puede manipular cuidadosamente este proceso, tiene la oportunidad de leer o alterar datos que no debería tocar e incluso controlar el servidor.

Esto se llama uso después de liberar, en inglés Use-After-Free.

En el mejor de los casos, puede leer contraseñas, tokens o claves API de otros usuarios en la memoria del servidor. En el peor, tras preparar cuidadosamente la memoria, puede usar tu servidor para ejecutar directamente su propio código, y las consecuencias serían inimaginables.

La segunda vulnerabilidad: la evacuación de emergencia cuando no hay suficiente memoria, que es CVE-2026-109618.

Esta es aún más interesante. Sigamos con el ejemplo del hotel.

Imagina que en el hotel hay un guardaequipajes. Cada vez que un cliente viene a dejar el equipaje, el recepcionista primero suma 1 en el libro de registro y luego mete el equipaje en la taquilla.

Las primeras 9 piezas van bien. Con la décima, justo cuando el recepcionista acaba de cambiar el número de 9 a 10 y se dispone a guardar el equipaje...

De repente, se va la luz, y el equipaje aún no se ha metido, pero todo el sistema se interrumpe forzosamente.

Y lo más disparatado viene ahora: el hotel activa el procedimiento de limpieza de emergencia. El personal de limpieza mira el libro de registro y ve: hoy se han guardado 10 piezas de equipaje.

Así que, siguiendo el número del libro, las revisa una por una.

Pero el problema es que la décima pieza nunca llegó a meterse. En esa posición puede que haya todavía cosas viejas y desordenadas.

Pero el personal de limpieza no lo sabe, ni le importa: siguiendo el libro, la trata como si fuera un equipaje normal.

Y ahí es donde todo el sistema puede fallar.

La segunda vulnerabilidad de PHP sigue un principio parecido.

Cuando organiza los datos, primero suma 1 a la cantidad y luego guarda los datos reales. Si justo entre esos dos pasos se agota la memoria, PHP interrumpe la operación de emergencia.

Pero el programa encargado de la limpieza posterior sigue procesando los datos según esa cantidad ya incrementada en 1.

Resultado: puede usar como datos normales memoria que no se ha inicializado correctamente.

Si un atacante puede crear cuidadosamente esta situación, tiene la oportunidad de controlar aún más el servidor.

Y lo más aterrador es que, en algunas configuraciones de servidor, este proceso puede ocurrir incluso antes de que empiece a ejecutarse el código de negocio del propio sitio web.

Por muy cuidadoso que sea el sitio web que has escrito, puede que ni siquiera tengas la oportunidad de intervenir.

¿Afecta a la gente normal? Claro que sí. Tu ordenador y tu móvil no se verán afectados; lo que se ve afectado son los sitios web que has usado. Si hackean un sitio pequeño que nadie mantiene, la cuenta, la contraseña, el número de teléfono y toda la información que dejaste allí podrían filtrarse.

Por eso muchos ingenieros vuelven a decir estos días que C, donde la memoria depende totalmente de las personas, tarde o temprano iba a provocar algo así. Lenguajes con seguridad de memoria como Rust no te dejan cometer este tipo de errores en la fase de compilación. Por eso OpenAI ha patrocinado específicamente la Fundación Rust, y no es casualidad.

Volviendo a estas dos vulnerabilidades, si rebuscamos en la historia, veremos que no son nada nuevo.

En 2004, el investigador de seguridad alemán Stefan Esser descubrió la primera vulnerabilidad remota de PHP relacionada con el límite de memoria. En aquel momento, los métodos de explotación de este tipo de ataques no se hicieron públicos y solo circulaban en secreto entre unas pocas empresas de seguridad.

Ese problema sí se corrigió, pero sus hermanos siguen ahí.

En 2024, la Fundación PHP recibió financiación de la agencia alemana Sovereign Tech Agency y, coordinada por OSTIF, encargó a la empresa de seguridad francesa Quarkslab una auditoría de seguridad externa de PHP que no se hacía desde hacía años.

Al corregir uno de los problemas, un desarrollador principal contratado por la fundación descubrió una vulnerabilidad similar. En teoría pensaba que podía explotarse, pero, sinceramente, tampoco encontraba una ruta de ataque concreta.

Y la solución se fue retrasando. El equipo de seguridad estuvo dando vueltas entre varias opciones, parando y retomando, retomando y parando. Más tarde, la Fundación PHP reconoció en su retrospectiva que se trataba de un "fallo estructural" causado por el proceso de decisión del equipo de seguridad y la falta de personal.

Y llegamos a 2026.

En mayo de este año, la empresa de seguridad Calif, la del principio, montó una serie llamada "Mes de vulnerabilidades descubiertas por IA". En uno de los artículos usaron Claude para encontrar en PHP una vulnerabilidad de memoria de hacía 21 años.

Y la IA siguió acelerando, imparable.

El 30 de julio, Calif empezó a auditar PHP dentro del programa de seguridad de OpenAI "Patch the Planet".

En solo 2 días, el 1 de agosto, encontraron la primera entrada capaz de provocar el "agotamiento de memoria".

El 11 de agosto, Calif informó de la vulnerabilidad a PHP. Ese mismo día, los propios investigadores de OpenAI también informaron de forma independiente del mismo problema.

El 15 de agosto, PHP confirmó que la demostración de ataque entregada por Calif realmente funcionaba.

El 24 de agosto y el 18 de septiembre, las empresas de seguridad Wiz y OpenAI informaron sucesivamente de más rutas de ataque.

Como estas dos vulnerabilidades tenían un impacto enorme y afectaban a las capas bajas de PHP, se empezó a organizar a socios de todo el mundo para coordinar la corrección. Los proveedores de nube, los distribuidores de sistemas y las empresas de seguridad tenían que prepararse con antelación; de lo contrario, hacer públicas las vulnerabilidades podría dar oportunidades a los atacantes.

Esta es una comparación sangrante: en 2024, un desarrollador principal buscó durante mucho tiempo sin encontrar cómo explotar esta vulnerabilidad. En 2026, desde el inicio de la auditoría hasta encontrar la primera entrada, solo pasaron dos días.

Y lo más disparatado es que...

Todo internet se sostiene sobre un montón de código que nadie paga y que muy poca gente lee con atención.

Esta vez también. La propia Fundación PHP reconoce que este problema de memoria ya daba señales en 2024 y que una razón importante de que se haya arrastrado hasta hoy es la falta de personal. Al final de la retrospectiva, casi están pidiendo ayuda, esperando que empresas, proveedores de hosting y gobiernos patrocinen.

En Hacker News alguien rescató la página de patrocinio del mantenedor encargado de empaquetar PHP en Debian y comentó con sorna: ¿ni siquiera 700 dólares al mes?

Y los servidores de todo el mundo, de verdad, están esperando a que esta gente se levante en mitad de la noche para publicar versiones.

Pero si estos programas básicos son tan frágiles, ¿por qué internet ha funcionado más o menos bien durante tantos años?

La razón es muy sencilla, igual que con la ingeniería inversa de REA que se puso tan de moda hace poco.

Porque encontrar vulnerabilidades es demasiado caro.

Igual que mucha gente no quiere hacer ingeniería inversa de software comercial, la protección de mucho software comercial se basa en que los demás no lo entienden y no se molestan en dedicar tiempo a estudiarlo.

Encontrar vulnerabilidades también. Las personas capaces de encontrar y explotar vulnerabilidades de memoria en sitios como el núcleo de PHP u OpenSSL quizá sean solo unos cientos en todo el mundo.

Su tiempo es muy caro y una vulnerabilidad puede llevar meses de trabajo. Por eso muchas bombas pueden permanecer enterradas tranquilamente durante veinte años: porque de verdad nadie quiere ocuparse de ellas, el coste es demasiado alto.

Pero la IA ha hecho que todo lo que antes era "caro" en el mundo se haya quedado en nada.

Anthropic acaba de anunciar este mes que, desde noviembre del año pasado hasta principios de octubre de este año, sus modelos han encontrado en proyectos de código abierto un total de 29.439 pistas de vulnerabilidades candidatas.

OpenAI también dijo en su largo artículo de esta noche que estas dos vulnerabilidades de PHP son solo una de las varias vulnerabilidades importantes que ya han descubierto y están corrigiendo, y que en los próximos meses "descubrimientos similares aumentarán drásticamente".

PHP2Shell no es el final, solo el principio. Este tipo de cosas van a ir a más, seguro que sí.

Pero aquí aparece el bug más importante. Como en las matemáticas: las demostraciones y los descubrimientos matemáticos son cada vez más rápidos, pero el cuello de botella principal está en la verificación. Hace poco OpenAI publicó más de 700 artículos; si los matemáticos de todo el mundo tuvieran que verificar si son correctos, harían falta como mínimo varios meses o incluso un año.

Con la ciberseguridad pasa lo mismo. Descubrir esta vulnerabilidad de PHP solo llevó 2 días.

Pero corregirla llevó dos meses enteros.

Los descubrimientos de vulnerabilidades serán cada vez más numerosos, pero las personas capaces de corregir estas vulnerabilidades de bajo nivel no son tantas.

Es como dice nuestro refrán antiguo.

"Solo hay quien roba durante mil días, no hay quien se proteja durante mil días".

De repente me vino a la cabeza una historia.

En 1871, Carroll, el autor de "Alicia en el país de las maravillas", publicó la continuación "Alicia a través del espejo". En el libro hay una Reina Roja que arrastra a Alicia a correr sin parar. Después de correr un buen rato, Alicia descubre que el paisaje de alrededor no ha cambiado nada.

La Reina Roja le dice: "Aquí, tienes que correr con todas tus fuerzas para quedarte en el mismo sitio".

Ese parece ser el dilema que la IA trae hoy a la sociedad.

Y no solo en seguridad. Los descubrimientos científicos se aceleran, escribir código se acelera, copiar software se acelera, atacar se acelera, defender también se acelera. Las cosas buenas y las malas se aceleran todas a la vez, como locas.

Y todos nosotros estamos en esta carrera de la Reina Roja.

El precio de pararse son esos sitios web viejos que nadie recuerda, los paneles de administración que se montaron hace 15 años y a los que no se ha vuelto a entrar, los sistemas de empresa que todavía corren PHP 5. En el mundo lento podían estar tranquilos durante muchos años, pero en el mundo rápido son blancos fáciles.

Creedme, en este mundo tiene que haber innumerables proyectos viejos de PHP que ya no se mantienen. Ahora mismo, todos son blancos.

Que las personas no pueden ganar a la IA ya no es un debate.

Pero en toda esta historia, en cada nodo de decisión clave, siguen habiendo personas.

Con buenas intenciones y con malas intenciones.

Ahora, esta herramienta todopoderosa está en manos de todos.

¿Vencerá la justicia al mal?

La IA puede hacer que la humanidad tenga de la noche a la mañana un poder difícil de imaginar en el pasado, pero no puede hacer que la humanidad aprenda de la noche a la mañana la moderación que corresponde a ese poder.

Cuando la velocidad del progreso tecnológico

supera con creces la velocidad de maduración de la naturaleza humana,

¿estamos corriendo hacia un mundo mejor o acelerando hacia nuestro propio abismo?

Sinceramente, ahora ya no lo sé.