PHP2Shell: Amazon vio el exploit 4 días antes del aviso

Qué pasó: un intento de explotación cuatro días antes del aviso público

Amazon Threat Intelligence detectó un intento de explotación de PHP2Shell con fecha del 17 de octubre de 2026 en la telemetría de MadPot, su red interna de honeypots. El hallazgo se hizo público cuatro días después del aviso oficial de CVE-2026-109618 y CVE-2026-109619, las dos vulnerabilidades críticas de PHP que buena parte de la infraestructura web parcheó a las apuradas.

El detalle que importa: el intento llegó desde una dirección IP asociada a una red comercial de anonimización. Según CJ Moses, CISO de Amazon Integrated Security, el hecho de que alguien apuntara a un honeypot desde una IP anonimizada mientras la vulnerabilidad seguía bajo embargo sugiere que se trató de un actor de amenaza. Cómo consiguió la información del exploit antes del anuncio sigue sin explicación.

La cronología del día del parche es igual de incómoda. El embargo estaba previsto levantarse el 21 de octubre de 2026 a las 14:00 UTC. Amazon identificó múltiples pruebas de concepto (PoC) para la vulnerabilidad, la más temprana alrededor de las 02:00 UTC de ese mismo día, doce horas antes del anuncio. Entre las 02:00 y las 08:00 UTC detectó intentos adicionales contra MadPot desde infraestructura anonimizada distinta, con payloads variados: señal de que eran varios actores, no uno.

Por qué el tiempo entre parche y exploit se está derrumbando

La lección estructural que deja Amazon va mucho más allá de PHP. "El tiempo entre el parche y un exploit funcional se está acortando por razones estructurales", escribió Moses. Antes, la mayoría de la explotación observada llegaba después de que se publicara una PoC: unos pocos actores capaces construían el exploit y el resto esperaba. Esa dependencia se está debilitando.

El motivo es el análisis asistido por IA. Convertir el diff de un parche o un aviso en un exploit funcional es cada vez más barato, y eso habilita a muchos más actores a moverse en horas o incluso minutos una vez que los detalles técnicos se hacen públicos.

Los números de la industria lo confirman. Matthew Prince, cofundador y CEO de Cloudflare, dijo que su empresa vio "miles de intentos de explotación" en las 10 horas previas al anuncio, y que eso saltó a decenas de miles en los 45 minutos posteriores, cientos de miles en dos horas y millones después, según recogió Infosecurity Magazine. Sansec había anticipado que la explotación masiva empezaría dentro de los 15 minutos siguientes a la publicación del parche.

También hubo un factor humano en el adelantamiento de los PoC. Según The Hacker News, ELLIO observó su primera petición PHP2Shell a las 08:36 UTC del 21 de octubre, menos de una hora después de que Chainguard publicara imágenes con el fix antes del levantamiento del embargo.

La escala: el 70% de la web y millones de hosts sin soporte

PHP sostiene una porción enorme de internet. Según datos de W3Techs citados por Infosecurity Magazine, cerca del 69,7% de los sitios web cuyo lenguaje de servidor se conoce usan PHP. Wiz lo resume en una frase: "con el 70% de internet afectado, el impacto de PHP2Shell no se puede exagerar".

El inventario de exposición es el dato más duro para cualquier equipo técnico. VulnCheck identificó PHP en 2.608.039 hosts con exposición a internet, de los cuales más de 700.000 corren versiones 3.x a 7.3 y unos 400.000 están en 7.4, 8.0 u 8.1, ramas sin soporte. Modat detectó 4,38 millones de servicios PHP expuestos al 20 de octubre de 2026, y el 79% (unos 3,47 millones) en una rama que el proyecto ya no mantiene.

Los parches oficiales existen solo para las ramas soportadas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Quien corre 8.1 o anterior no recibe corrección oficial y la recomendación es migrar.

Qué significa esto para tu startup

Si tu producto corre sobre PHP, y si usas WordPress, Drupal, Joomla o Magento lo hace, este episodio invalida dos supuestos con los que casi todos los equipos operan.

Primero: tus SLA de parcheo están calibrados para un mundo que ya no existe. Amazon lo dice sin vueltas: para vulnerabilidades críticas en sistemas expuestos a internet, los plazos de parcheo y mitigación se miden en horas. Un SLA de 7 o 30 días asume un retraso que ya no existe. Si tu política interna dice "crítico: 30 días", esa política te deja expuesto semanas después de que el exploit esté circulando.

Segundo: la fecha de divulgación no es la fecha del primer ataque. Las investigaciones deben arrancar desde la explotación conocida más temprana, no desde el aviso. En el caso de PHP2Shell, eso significa revisar tus logs desde al menos el 17 de octubre de 2026.

Acciones concretas que puedes ejecutar esta semana:

• Actualiza a las versiones corregidas. Es la única remediación completa para ambas CVE. No hay workaround de configuración que resuelva los dos problemas a la vez.
• Revisa tus logs desde el 17 de octubre, no desde el 21. Busca peticiones POST con la cadena PHP_SESSION_UPLOAD_PROGRESS en formularios de subida, ejecución inesperada de procesos y modificaciones de archivos en servidores de aplicaciones.
• Si no puedes parchear ya, considera bloquear las subidas de archivos multipart en los despliegues PHP, pero antes evalúa cómo afecta a tu aplicación.
• Invierte en detecciones que no dependan de una firma para una CVE específica. La primera explotación casi siempre llega antes de que existan esas firmas.

El detalle que complica la detección

Hay un agravante técnico que conviene tener en el radar. Según CrowdStrike, un ataque exitoso contra estas vulnerabilidades no deja casi rastro digital: no hay autenticación que eludir, ni sesión que robar, ni endpoint vulnerable que descubrir. La exposición es independiente del CMS, framework o plugins que uses.

Los procesos worker se mantienen estables, las respuestas devuelven HTTP 200 y los logs de aplicación no registran anomalías, porque nunca se ejecutó código de la aplicación. El único rastro del lado del servidor es un fatal de límite de memoria en el log de errores del servidor web, que normalmente se descarta como ruido. SentinelOne advirtió además que los atacantes pueden robar contraseñas, tokens y claves de API desde la memoria del proceso PHP sin ejecutar código, lo que dificulta la detección con herramientas centradas en ejecución maliciosa.

Indicadores de compromiso: qué hacer con las IPs

Amazon publicó seis direcciones IP observadas en la actividad:

• 103.216.220.92, observada el 17 de octubre de 2026
• 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 y 95.217.98.37, observadas el 21 de octubre de 2026

Un punto importante: estas IPs pertenecen a infraestructura de anonimización compartida y no son exclusivas de esta actividad. La recomendación de Amazon es investigar cualquier observación que involucre estas direcciones, no bloquearlas a ciegas, porque bloquear infraestructura compartida puede cortar tráfico legítimo.

Conclusión

El caso PHP2Shell deja una conclusión incómoda para cualquier founder con producto en producción: la ventana entre "hay parche" y "hay exploit" se comprimió a horas, y en este caso la explotación empezó antes de que existiera el parche. La divulgación coordinada sigue siendo el modelo correcto, porque protege a los defensores hasta que alguien más encuentra el mismo bug. Nada más que eso.

Lo que cambia es la velocidad. Si tu equipo todavía trata el parcheo crítico como una tarea de sprint, el riesgo ya no está en el bug: está en tu proceso.

Fuentes

• Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (fuente original)
• PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure - Infosecurity Magazine
• Someone Tried to Exploit PHP2Shell 4 Days Before the Vulnerabilities Were Publicly Disclosed - The Hacker News
• Hackers Exploited the PHP Vulnerabilities Days Before They Were Patched - WIRED
• 5 Things To Know About Critical PHP Vulnerabilities Exploitation - CRN
• PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws - SecurityWeek