Según Amazon Threat Intelligence, un actor de amenazas intentó explotar dos vulnerabilidades críticas de PHP (CVE-2026-109618 y CVE-2026-109619), conocidas colectivamente como PHP2Shell, cuatro días antes de que fueran reveladas y parcheadas públicamente. La actividad comenzó el 17 de octubre de 2026, mientras las fallas aún estaban bajo divulgación coordinada, permitiendo potencialmente el control remoto de los sistemas afectados.

Un actor de amenazas intentó explotar dos vulnerabilidades críticas de PHP cuatro días antes de que los fallos fueran revelados públicamente y parcheados, según Amazon Threat Intelligence.

La actividad comenzó el 17 de octubre de 2026, mientras las vulnerabilidades aún estaban bajo divulgación coordinada. Los fallos, rastreados como CVE-2026-109618 y CVE-2026-109619 y conocidos conjuntamente como PHP2Shell, pueden permitir la ejecución remota de código en los servidores web afectados.

El intento temprano fue registrado por MadPot, la red de honeypots de Amazon (sistemas diseñados para atraer y observar actividad sospechosa). Provino de una dirección IP vinculada a un servicio comercial de anonimización.

AWS señaló que no está claro cómo el actor obtuvo información sobre las vulnerabilidades antes de su divulgación, o si el intento habría tenido éxito contra un servidor real.

Analistas de AWS también observaron varios intentos más de PHP2Shell el 21 de octubre, antes del lanzamiento público de las correcciones. La primera actividad de prueba de concepto apareció alrededor de las 02:00 UTC, unas 12 horas antes de que se abriera la ventana de divulgación a las 14:00 UTC.

La actividad utilizó diferentes cargas útiles e infraestructura anonimizada, lo que según AWS puede indicar la presencia de varios actores. Aparecieron exploits adicionales de prueba de concepto después de la divulgación, y AWS informó que PHP2Shell estaba siendo ampliamente explotado.

Estaban apuntando a vulnerabilidades críticas de PHP días antes

Las vulnerabilidades afectan el manejo de la memoria y los datos de solicitud de PHP. CVE-2026-109618 está vinculado a una condición de falta de memoria que puede dejar los datos internos en un estado incompleto.

CVE-2026-109619 implica un estado obsoleto que puede permanecer en un trabajador de PHP de larga ejecución y ser utilizado durante una solicitud posterior. En algunos casos, los atacantes podrían usar estos fallos para ejecutar código remotamente, sin necesidad de iniciar sesión primero.

El equipo de seguridad de PHP lanzó correcciones el 21 de octubre. Las versiones parcheadas incluyen PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Las ramas más antiguas de PHP también pueden necesitar actualizaciones proporcionadas por el proveedor o una actualización a una versión soportada.

Deberías revisar el paquete o la distribución específica que uses, ya que algunos proveedores pueden aplicar un parche sin cambiar el número de versión mostrado por el proyecto PHP original.

Cybersecurity News cubrió previamente la advertencia de parche de emergencia del equipo de PHP, que instaba a los administradores a prepararse para el lanzamiento.

Un informe posterior detalló las actualizaciones de seguridad de emergencia de PHP2Shell. Los informes describen etapas separadas de la misma historia: la advertencia anticipada, seguida de los parches para los dos fallos.

Por qué es importante la actividad temprana

El lanzamiento de un parche no marca el inicio del riesgo. Los atacantes pueden enterarse de una debilidad antes de la divulgación pública, como sugiere la observación de AWS del 17 de octubre.

Después de que se publica una corrección, otros atacantes también pueden estudiar los cambios y desarrollar herramientas funcionales rápidamente. AWS afirmó que los exploits de prueba de concepto aparecieron a las pocas horas de la divulgación e instó a los defensores a no tratar la fecha del anuncio público como la fecha más temprana posible de explotación.

Eso significa que deberías revisar la actividad anterior a la fecha del parche, y no solo investigar las alertas generadas posteriormente. AWS recomienda comenzar la revisión al menos desde el 17 de octubre.

Las comprobaciones pertinentes incluyen los registros del servidor web, lanzamientos de procesos inusuales y cambios inesperados de archivos en los hosts de PHP. También deberías buscar solicitudes POST que contengan la cadena PHP_SESSION_UPLOAD_PROGRESS en las cargas de formularios.

Las organizaciones deben actualizar los entornos de ejecución de PHP lo antes posible y confirmar que los trabajadores de producción estén ejecutando el código corregido.

Esto incluye revisar servidores web, contenedores y entornos de hosting gestionados, en lugar de confiar únicamente en la versión de PHP instalada para uso en línea de comandos. Puede ser necesario un reinicio o un redespliegue para que los trabajadores de larga ejecución dejen de usar el entorno de ejecución antiguo.

Si no es posible realizar una actualización inmediata, AWS sugiere considerar restricciones en las cargas de archivos multipart. Tal cambio puede afectar las funciones normales de la aplicación, por lo que deberías evaluar el impacto antes de aplicarlo.

AWS dice que los cambios solo de configuración no corrigen completamente ambas vulnerabilidades; actualizar a una versión corregida es la remediación completa.

Para más contexto sobre los informes de actividad antes del parche, consulta la cobertura sobre los intentos tempranos de explotación de PHP2Shell.

Otro informe cubre la herramienta pública de pruebas de PHP2Shell. Juntos, estos informes subrayan por qué deberías usar múltiples señales y evitar depender de una única regla de detección específica de un CVE.

Indicadores de compromiso (IoCs):-

Dirección IP	Fecha observada
103.216.220.92	17 de octubre de 2026
31.223.184.166	21 de octubre de 2026
37.19.200.5	21 de octubre de 2026
134.209.159.64	21 de octubre de 2026
103.114.163.188	21 de octubre de 2026
95.217.98.37	21 de octubre de 2026

Nota: Las direcciones IP y los dominios han sido "desactivados" intencionadamente (por ejemplo, [.]) para evitar la resolución accidental o el hipervínculo. Actívalos solo dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.

Fuentes:
https://cybersecuritynews.com/critical-php-vulnerabilities/