Tecnología

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

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.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.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 inmediatoA 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

Related posts

«Sueño de la humanidad»: China desarrolla un sistema para obtener agua potable de la atmósfera

Manuel Cotillo

El A20 Pro del iPhone 18 Pro demuestra el enorme salto al bajar a 2 nm. Buenas noticias de cara a un MacBook Neo 2

Alba Rueda

Meta lanza nuevas funciones de seguridad para adolescentes y elimina 635.000 cuentas que sexualizaban a menores

Alba Rueda

Leave a Comment

Este sitio web utiliza cookies para mejorar tu experiencia. Damos por sentado que estás de acuerdo, pero puedes desactivarlas si lo deseas. Acceptar Read More

Privacy & Cookies Policy