Hay vulnerabilidades que pueden permanecer ocultas durante años y, cuando finalmente alguien las encuentra, todavía no se hacen públicas de inmediato. Comienza entonces una carrera discreta: entender qué permiten hacer, preparar una corrección y coordinar su divulgación antes de que la información llegue a quien pueda aprovecharla. Es un equilibrio delicado y bastante habitual en ciberseguridad. Lo que resulta mucho menos habitual es descubrir después que alguien ya estaba probando suerte cuando, en teoría, casi nadie fuera de ese círculo debía saber lo suficiente.
Eso es precisamente lo que Amazon Threat Intelligence asegura haber observado con PHP2Shell. Su red MadPot registró el 17 de octubre un intento de aprovechar estas vulnerabilidades, cuatro días antes de la divulgación pública coordinada y de la publicación de los parches el día 21. Amazon considera que las características de aquella actividad apuntan a un actor malicioso, pero hay una pieza que sigue sin encajar: no sabe cómo obtuvo información sobre el exploit antes de que fuera pública.
MadPot no es un servidor de producción comprometido, sino una red de honeypots, sistemas señuelo que Amazon expone para atraer actividad maliciosa y observar cómo se comportan quienes intentan atacarlos. El intento procedía además de una IP asociada a una red comercial de anonimización, uno de los indicios por los que la compañía considera probable que detrás hubiera un actor malicioso. Esa telemetría demuestra que el intento existió, pero no que una web real llegara a ser vulnerada. Para Amazon, la consecuencia práctica está en otro lugar: las organizaciones deberían revisar sus registros al menos desde el 17 de octubre, no únicamente desde la publicación del aviso.
Alguien llegó antes que todos
Para entender cómo hemos llegado hasta aquí hay que retroceder hasta agosto. El 11 de ese mes, Calif notificó al equipo de PHP una vía de ejecución remota de código vinculada a un problema que los mantenedores ya habían observado en 2024, y OpenAI llegó de forma independiente a la misma causa. Wiz comenzó su investigación independiente el 19 de agosto y comunicó sus hallazgos al equipo de PHP el día 24. La inteligencia artificial tuvo un papel relevante en varias de esas investigaciones, tanto en el descubrimiento como en el desarrollo y la validación de vías de explotación extremadamente complejas, pero no tenemos ninguna prueba de que explique lo ocurrido el 17 de octubre. La cronología completa está recogida también por la PHP Foundation.
PHP2Shell agrupa dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, ambas calificadas con un 9,2 sobre 10. El problema está en partes centrales de PHP relacionadas con la gestión de memoria y los errores, no en un plugin o una aplicación concreta. Según explica Cloudflare, bajo determinadas condiciones, una petición HTTP especialmente preparada puede provocar que el servidor utilice datos internos en un estado inseguro y llegar a ejecutar código sin autenticación. Que los fallos estén en el propio runtime amplía su alcance y obliga a revisar y actualizar las instalaciones afectadas, una recomendación que también hace directamente PHP.
La divulgación coordinada empezó a torcerse el 20 de octubre. Según reconstruye la PHP Foundation, alrededor de las 15:00 UTC comenzaron a circular los identificadores de los dos CVE, aunque sin detalles técnicos y acompañados de información incorrecta, lo que llevó al proyecto a adelantar un día la publicación prevista. Después apareció por error un vídeo de Calif con una demostración limitada y, ya el 21 a las 07:41 UTC, Chainguard publicó imágenes que incorporaban la corrección antes de terminar el embargo. Ninguno de esos episodios conocidos explica, sin embargo, lo ocurrido cuatro días antes.
Lo que vino después sí resulta mucho más fácil de seguir. Cloudflare pasó de registrar miles de intentos de explotación durante las diez horas anteriores al anuncio a decenas de miles en los primeros 45 minutos, cientos de miles en dos horas y finalmente millones, según detalló su CEO, Matthew Prince, en unas cifras recogidas por Reuters. La compañía observó además cómo los atacantes modificaban sus cargas para intentar esquivar las protecciones desplegadas. Amazon observó en paralelo una rápida proliferación de los exploits: aparecieron nuevos ejemplos de prueba de concepto y, una vez levantado el embargo, empezaron a utilizarse contra sus sensores prácticamente de inmediato.
A estas alturas podemos reconstruir casi toda la secuencia: sabemos cuándo se descubrieron los fallos, cómo se trabajó en sus correcciones, cuándo empezó a deteriorarse el embargo y con qué rapidez se multiplicaron los intentos en cuanto circularon más detalles. Lo que sigue faltando está precisamente al principio de esa historia. Amazon vio actividad compatible con un intento de explotación el 17 de octubre, cuando todavía no existía una explicación pública suficiente para llegar hasta ahí. Quién estaba detrás y, sobre todo, cómo obtuvo ese conocimiento siguen siendo preguntas abiertas.
Imagen | Mohammad Rahmani
–
La noticia
Los fallos críticos de PHP acaban de hacerse públicos. Lo misterioso es que alguien ya intentaba explotarlos cuatro días antes
fue publicada originalmente en
Xataka
por
Javier Marquez
.
