AWS informó de un intento de explotar PHP2Shell antes del aviso público

AWS informó el 21 de octubre de que la telemetría de su red de honeypots MadPot había registrado un intento de explotar PHP2Shell el 17 de octubre, cuatro días antes de la divulgación pública de las vulnerabilidades. La actividad llegó desde una dirección IP asociada a una red comercial de anonimización y se dirigió a un honeypot, un sistema señuelo que sirve para observar ataques. AWS dijo que no podía determinar si los intentos habrían funcionado contra sistemas reales.

Qué fallos encontró PHP y qué versiones los corrigen

PHP2Shell reúne dos vulnerabilidades críticas del núcleo de PHP que pueden permitir ejecución remota de código sin autenticación. PHP asignó a ambas una puntuación de 9,2 en CVSS 4.0.

• CVE-2026-109618 afecta al manejo de errores por falta de memoria: puede dejar datos de una solicitud parcialmente inicializados y provocar que PHP los trate como válidos durante la limpieza.
• CVE-2026-109619 implica estado interno obsoleto: una solicitud posterior en el mismo proceso de trabajo puede reutilizar datos después de que se haya liberado la memoria que los respaldaba.

PHP enumera como afectadas las instalaciones que sirven solicitudes web mediante PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Señala mod_php como la integración de mayor riesgo, porque una solicitud sin autenticar puede activar el problema antes de que se ejecute el código de la aplicación.

Las versiones corregidas que publicó PHP son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Algunas distribuciones y proveedores con soporte a largo plazo pueden aplicar las correcciones a ramas anteriores sin usar la misma numeración. Conviene identificar qué runtime de PHP ejecuta el servicio, no limitarse a comprobar la versión de un CMS o una aplicación. El aviso oficial de seguridad de PHP recoge las versiones y los detalles técnicos.

Qué observaron por separado otras redes de sensores

Telekom Security informó de que sus propios honeypots no registraron cargas que parecieran exploits antes de que los avisos aparecieran en su cronología. La empresa situó esa aparición a las 13:34 UTC del 21 de octubre y la primera carga serializada con aspecto de exploit en sus sensores a las 14:18 UTC. Sus datos describen esa red; AWS informó de una observación distinta en MadPot el 17 de octubre.

AWS también situó alrededor de las 02:00 UTC del 21 de octubre el primero de varios exploits de prueba de concepto que detectó. Informó de más intentos contra MadPot entre las 02:00 y las 08:00 UTC. La cronología distingue la actividad que AWS observó antes de la divulgación de los intentos posteriores.

Qué pueden hacer quienes administran PHP

PHP indica que actualizar a una versión corregida es la solución completa. Las medidas de configuración pueden reducir la exposición a rutas concretas, pero no sustituyen la actualización; después de cambiar la configuración, hay que reiniciar los procesos de trabajo afectados.

AWS recomienda revisar las solicitudes POST que contengan PHP_SESSION_UPLOAD_PROGRESS, los registros del servidor web y posibles ejecuciones inesperadas de procesos o cambios de archivos. Si no se puede aplicar el parche de inmediato, sugiere valorar restricciones temporales a las cargas multipartes y comprobar antes su impacto en la aplicación.

AWS publicó seis direcciones IP asociadas a la actividad: 103.216.220.92, observada el 17 de octubre; y 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. AWS advierte de que las direcciones incluyen infraestructura de anonimización compartida y no son exclusivas de estos intentos, por lo que recomienda investigar las coincidencias en lugar de bloquearlas automáticamente.