Los fallos críticos de PHP acaban de hacerse públicos. Lo misterioso es que alguien ya intentaba explotarlos cuatro días antes

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.