# Amazon detectó un intento previo al anuncio de fallos en PHP > La red MadPot registró actividad sospechosa cuatro días antes de la divulgación de dos fallos críticos en PHP. El caso dejó al descubierto una carrera de explotación que se adelantó al aviso público. Por Deivimar G.S. · 22 de octubre de 2026 · Tecnología ![La pantalla de una computadora portátil muestra un editor de código con código de programación visible en un entorno con poca luz.](https://cdn.panorama.onl/uploads/c86e21dbebef19a3.webp) Amazon Threat Intelligence asegura haber detectado el 17 de octubre un intento de explotación vinculado a dos vulnerabilidades críticas de PHP, cuatro días antes de que se hiciera pública la divulgación coordinada y de que se publicaran los parches el 21. La compañía sostiene que la actividad apuntaba a un actor malicioso, pero todavía queda una incógnita central: cómo obtuvo información suficiente para intentar explotar los fallos antes de su anuncio. La observación salió de MadPot, la red de honeypots de Amazon diseñada para atraer tráfico hostil y estudiar su comportamiento. Según la empresa, el intento procedía además desde una dirección IP asociada a una red comercial de anonimización, un indicio que refuerza su sospecha sobre el origen de la actividad. Esa telemetría demuestra que el intento existió, pero no que una web real fuera comprometida. Claves - Amazon dice que registró el intento el 17 de octubre, antes de la divulgación pública de los fallos. - El caso involucra dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, ambas con 9,2 sobre 10. - MadPot detectó tráfico desde una IP asociada a una red comercial de anonimización. - La PHP Foundation adelantó su publicación prevista tras circular identificadores de los CVE con información incorrecta. ## La carrera empezó antes del anuncio PHP2Shell agrupa [CVE-2026-109618](https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/CVE-2026-109618) y [CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619), dos fallos críticos calificados con 9,2 sobre 10. El problema afecta partes centrales del propio entorno de ejecución de PHP, no a un complemento o una aplicación concreta. Según [Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection), bajo ciertas condiciones una petición HTTP preparada de forma específica puede llevar a que el servidor use datos internos en un estado inseguro y termine ejecutando código sin autenticación. La cronología previa también muestra una secuencia estrecha de investigaciones. El 11 de agosto, Calif notificó al equipo de PHP una vía de ejecución remota de código asociada a un problema que los mantenedores ya habían observado en 2024, y [OpenAI](https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/?from=bd_signal&utm_) llegó de forma independiente a la misma causa. [Wiz](https://www.wiz.io/blog/php2shell-php-rce) inició su propia investigación el 19 de agosto y la comunicó al equipo de PHP el día 24. La inteligencia artificial tuvo un papel relevante en varias de esas indagaciones, tanto en el descubrimiento como en la validación de técnicas de explotación complejas. ## El embargo se rompió y los ataques se multiplicaron La divulgación coordinada empezó a desordenarse el 20 de octubre. La [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) reconstruyó que alrededor de las 15:00 UTC comenzaron a circular los identificadores de los dos CVE, pero sin detalles técnicos y con información incorrecta, lo que llevó al proyecto a adelantar un día la publicación prevista. Después apareció por error un video 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 que terminara el embargo. Tras el anuncio, el volumen de intentos creció con rapidez. Matthew Prince, citado por Reuters, dijo que Cloudflare pasó de registrar miles de intentos en las diez horas previas al anuncio a decenas de miles en los primeros 45 minutos, cientos de miles en dos horas y después millones. La empresa también observó cómo los atacantes ajustaban sus cargas para intentar esquivar las protecciones desplegadas. Amazon, por su parte, señaló que tras levantarse el embargo comenzaron a aparecer nuevos ejemplos de prueba de concepto y que los sensores de MadPot los vieron circular casi de inmediato. Lo que sigue sin respuesta es el punto de partida de todo el episodio: quién estaba detrás del intento del 17 de octubre y, sobre todo, cómo logró acceder antes que el resto a información suficiente para actuar. Amazon sostiene que la telemetría apunta a una intención clara de explotación, pero la cadena completa de acceso previo al anuncio todavía no está explicada. La cronología completa fue recogida también por la [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), mientras que Amazon describió el funcionamiento de [MadPot](https://www.aboutamazon.com/news/aws/amazon-madpot-stops-cybersecurity-crime) como una red de señuelos para observar actividad maliciosa y [Amazon Threat Intelligence](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) detalló el hallazgo previo a la divulgación pública. --- **Fuente:** https://panorama.onl/tecnologia/amazon-detecto-un-intento-previo-al-anuncio-de-fallos-en-php-20261022-1525.html Publicado por Panorama Online — contenido de libre lectura; se permite citar con atribución y enlace a la URL original.