Amazon vio intentos de ataque a PHP2Shell cuatro días antes de su divulgación

Alguien intentó explotar PHP2Shell cuatro días antes de que la mayoría de los defensores supiera que existía. Según Amazon, su red de honeypots MadPot registró un intento contra las dos fallas de PHP el 17 de octubre de 2026. Las correcciones y la divulgación pública no llegaron hasta el 21 de octubre a las 14:00 UTC. Amazon afirma ahora que las fallas se están explotando de forma amplia.

PHP corrigió las dos fallas, CVE-2026-109618 y CVE-2026-109619, en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 el miércoles. Ambas tienen una puntuación de 9.2 y pueden permitir que un atacante ejecute código en un servidor web sin iniciar sesión. Según la cronología de Amazon, un servidor parcheado el miércoles pudo sufrir ataques antes.

Qué vio Amazon

MadPot es la red de honeypots de Amazon, servidores señuelo creados para atraer a los atacantes y registrar lo que hacen. En la publicación del AWS Security Blog, Amazon detalla lo que registraron sus sensores.

Hora (UTC)	Qué ocurrió
17 de octubre	MadPot registra el primer intento, desde una dirección ligada a una red comercial de anonimización
20 de octubre	Los números CVE circulan en Hacker News y redes sociales, según Tenable
21 de octubre, hacia las 02:00	Aparece el primer exploit de prueba de concepto, unas 12 horas antes de las correcciones
21 de octubre, de 02:00 a 08:00	Llegan más intentos desde otra infraestructura anonimizada
21 de octubre, 14:00	Se levanta el embargo y se publican las correcciones

Los intentos del 21 de octubre usaron cargas e infraestructuras variadas, lo que según Amazon sugiere más de un atacante. Tras la publicación, aparecieron más exploits en cuestión de horas y llegaron a los sensores de Amazon casi de inmediato.

Amazon es prudente con lo que no sabe. Sus sensores son señuelos, así que no puede decir si los primeros intentos habrían funcionado en sistemas reales. Amazon también escribe que «sigue sin estar claro cómo obtuvo el actor información del exploit antes de la divulgación». El intento del 17 de octubre llegó tres días antes de que se filtraran los números CVE.

Cómo se rompió el embargo

Un embargo es el periodo discreto en que un proyecto y sus socios preparan correcciones antes de anunciar un fallo. El embargo de PHP2Shell no se sostuvo.

Según Tenable y The Hacker News, la PHP Foundation planeó primero la publicación para el 22 de octubre. La adelantó un día después de que se filtraran los números CVE. The Register informa de que la fundación también acusó a Chainguard, que publica imágenes de contenedores, de difundir compilaciones parcheadas antes del plazo acordado. «Cualquier atacante podía ahora estudiar la corrección en forma binaria mientras todos los demás usuarios de PHP seguían esperando la publicación», dijo la fundación, según The Hacker News. Los informes no incluyen una respuesta de Chainguard.

El tamaño de la ola de ataques

Matthew Prince, CEO de Cloudflare, publicó cifras en X. Cloudflare vio miles de intentos en las 10 horas previas al anuncio. La cifra subió a decenas de miles en los 45 minutos siguientes y a cientos de miles en dos horas. Prince habla ahora de «millones».

La empresa de alojamiento Pantheon bloqueó más de 60.000 solicitudes sospechosas, informa The Hacker News. Cloudflare dice que los atacantes cambian sin parar sus cargas para esquivar sus reglas de cortafuegos. Ninguna de estas cifras confirma una intrusión con éxito. Muestran intentos bloqueados o registrados.

The Hacker News cita a CJ Moses, CISO de Amazon Integrated Security, sobre por qué esto se repite: «El análisis asistido por IA abarata convertir el diff de un parche o un aviso en un exploit que funciona».

Qué significa para los desarrolladores

Si usas PHP, tu investigación empieza el 17 de octubre, no el día en que aplicaste el parche. Amazon lo dice sin rodeos: «Empieza las investigaciones desde la primera explotación conocida, no desde la fecha de divulgación».

• Parchea primero. Instala 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reinicia después cada worker de PHP para que el código nuevo se ejecute de verdad. Según Amazon, solo una actualización corrige por completo las dos fallas.
• Busca el patrón conocido en tus registros. Amazon aconseja buscar solicitudes POST que contengan la cadena PHP_SESSION_UPLOAD_PROGRESS en las subidas de formularios. La empresa de seguridad Hadrian dice que la mayoría de los ataques que observa abusan de esta ruta de progreso de subida de las sesiones.
• Busca señales de que se ejecutó código. Revisa los servidores en busca de procesos inesperados y archivos modificados. El FBI aconseja vigilar los procesos de PHP que lanzan intérpretes de comandos o descargan archivos.
• Usa los parches temporales solo mientras actualizas. La lista de PHP incluye el ajuste session.upload_progress.enabled=0 y reiniciar los workers. Amazon también sugiere bloquear las subidas de archivos multipart si tu aplicación puede prescindir de ellas.
• No confíes en el código de exploits públicos. JFrog informa de exploits falsos de PHP2Shell y de malware de broma en GitHub. Tenable advierte de que el código que circula puede esconder malware.
• Investiga las direcciones IP publicadas, pero no te fíes solo de bloquearlas. Amazon publica seis, pero aconseja investigar en lugar de bloquear, porque pertenecen a servicios de anonimización compartidos.