El equipo de Threat Intelligence de Amazon informó el miércoles que el 17 de octubre de 2026 detectó un intento de explotar las recién reveladas vulnerabilidades PHP2Shell contra su servicio de honeypot MadPot, en un contexto en el que los fallos se explotan de forma generalizada tras la publicación de los parches.
CJ Moses, CISO de Amazon Integrated Security, señaló en una publicación compartida con The Hacker News que el intento de explotación provino de una dirección IP vinculada a una red comercial de anonimización. Aunque la vulnerabilidad seguía bajo embargo, el ataque a un honeypot desde una IP anonimizada sugiere la actuación de un actor de amenazas, si bien no está claro cómo obtuvo información sobre el exploit antes de su divulgación.
El intento se registró desde la IP "103.216.220[.]92", geolocalizada en Australia, según Amazon.
Dos fallos críticos en el núcleo de PHP
La actividad guarda relación con dos vulnerabilidades que afectan al núcleo de PHP, ambas con una puntuación de 9,2 en el sistema CVSS. Identificadas como CVE-2026-109618 y CVE-2026-109619 y descubiertas por investigadores de Calif, OpenAI y Wiz (propiedad de Google), pueden aprovecharse para lograr ejecución remota de código sin autenticación previa en los sistemas afectados.
Los fallos están presentes en todas las versiones de PHP de las series 7.x y 8.x y ponen en riesgo cualquier endpoint PHP accesible de un servidor afectado, incluidos formularios estáticos, rutas de inicio de sesión y comprobaciones de estado. Según CrowdStrike, un ataque que explote estas fallas no deja prácticamente 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, el framework o los complementos utilizados.
CrowdStrike añadió que los procesos trabajadores permanecen estables, las respuestas devuelven HTTP 200 y los registros de la aplicación no muestran anomalías, porque nunca se ejecutó código de la aplicación. El único rastro en el servidor es un error fatal por límite de memoria en el registro del servidor web, que suele descartarse como ruido, lo que deja a los defensores sin telemetría web útil para identificar endpoints comprometidos.
Divulgación adelantada por una filtración
La divulgación coordinada estaba prevista para el 22 de octubre de 2026 a las 14:00 UTC, pero los detalles sobre los identificadores CVE y un exploit de prueba de concepto (PoC) se filtraron antes, lo que llevó a la PHP Foundation a adelantar la publicación un día.
Ambos problemas residen en partes de PHP que casi todas las peticiones tocan: la gestión de memoria y el manejo de errores. Su posición central en PHP es lo que hizo que ambas vulnerabilidades fueran graves y también tan difíciles de corregir sin romper la compatibilidad, perjudicar el rendimiento o forzar cambios en el amplio ecosistema de extensiones de terceros.
Amazon indicó que detectó múltiples exploits PoC de PHP2Shell coincidiendo con el día de la publicación de los parches, con el primer intento registrado alrededor del 21 de octubre de 2026 a las 2:00 UTC. Le siguieron otros intentos de explotación desde infraestructura anonimizada en las seis horas posteriores. La variedad de payloads y la infraestructura de anonimización empleada apuntan a la participación de varios actores de amenazas, según Amazon Threat Intelligence.
Los intentos se registraron desde las siguientes direcciones IP el 21 de octubre de 2026:
- 31.223.184[.]166
- 37.19.200[.]5
- 134.209.159[.]64
- 103.114.163[.]188
- 95.217.98[.]37
Según ELLIO, la primera petición de PHP2Shell dirigida a sus sensores se observó el 21 de octubre a las 8:36 UTC, menos de una hora después de que "Chainguard rompiera unilateralmente el embargo y publicara imágenes compiladas con la corrección".
Chainguard había recibido el parche por adelantado para que sus usuarios pudieran actualizar en el momento de la divulgación. Cualquier atacante podía ahora estudiar la corrección en forma binaria mientras el resto de usuarios de PHP seguía esperando la publicación. Esto ignoró semanas de trabajo de muchas partes en pos de una divulgación coordinada.
Alertas de agencias y proveedores
La gravedad de las vulnerabilidades ha provocado advertencias de agencias internacionales de ciberseguridad como el Centro Nacional de Ciberseguridad (NCSC) del Reino Unido y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) de Estados Unidos, que instan a las organizaciones a aplicar las correcciones cuanto antes o a considerar desconectar los sistemas.
Supervisen los servidores web en busca de actividad sospechosa, como procesos PHP que lancen inesperadamente shells de comandos o descarguen archivos. Asegúrense de contar con capacidades adecuadas de monitorización de procesos que ayuden a identificar posibles explotaciones.
En una alerta similar, la Agencia de Seguridad Nacional (NSA) de Estados Unidos señaló que las vulnerabilidades pueden dar a los actores de amenazas una vía directa al sistema de archivos o la base de datos del servidor. OpenAI, que describió los fallos como "uno de los problemas de seguridad más impactantes de la memoria reciente", ha publicado una habilidad de Codex para comprobar si un sitio web o un binario PHP local es vulnerable a PHP2Shell.
Dado que PHP impulsa la mayoría de los sitios web del mundo, la enorme superficie de ataque, unida a la gravedad y facilidad de explotación de PHP2Shell, supone riesgos importantes, ya que permite a atacantes no autenticados ejecutar código y robar datos sensibles.
PHP es utilizado por casi el 70% de los sitios web. Las vulnerabilidades php2shell afectan al propio entorno de ejecución de PHP y pueden permitir a los atacantes ejecutar código malicioso en servidores vulnerables, exponer datos de clientes o interrumpir servicios. Como PHP sustenta plataformas ampliamente usadas como WordPress y Magento, estos fallos podrían afectar potencialmente a un gran número de aplicaciones en internet.
El análisis de VulnCheck ha identificado PHP en 2.608.039 hosts expuestos a internet, de los cuales más de 700.000 ejecutan PHP 3.x hasta 7.3. Otro conjunto de unos 400.000 hosts ejecuta PHP 7.4, 8.0 u 8.1, mientras que 403.000 hosts ejecutan las ramas 8.2 a 8.5 con soporte.
PHP es un lenguaje masivamente popular e impulsa grandes partes de internet. La prioridad inmediata es una responsabilidad clara: saber dónde se usa PHP en sus servicios y productos, quién es responsable de la remediación y con qué rapidez pueden desplegarse las correcciones.
Ilkka Turunen, Field CTO de Sonatype, añadió que es probable que exista una larga cola de entornos que necesiten aplicar el parche, ya que PHP se incluye en muchas distribuciones de sistemas operativos y está presente en numerosos entornos históricos.
Otros desarrollos destacados
- La plataforma WebOps Pantheon afirmó haber bloqueado más de 60.000 peticiones sospechosas que sondeaban la vulnerabilidad.
- VulnCheck identificó dos hosts, 85.11.167[.]243 y 45.198.224[.]169, con el user-agent "php2shell-scan/109618" armando CVE-2026-109618 contra sus honeypots, mientras que 109.71.252[.]97 aprovechó ambas fallas.
- Cloudflare ha observado tráfico de ataque dirigido a sus clientes, con actores de amenazas que "mutan el payload del ataque para intentar eludir nuestras protecciones rastreando el volumen de coincidencias y cruzándolo con la lógica de las reglas".
- CloudLinux ha publicado paquetes corregidos para ea-php52 hasta ea-php85 y todas las versiones alt-php.
- Numerosos proveedores de seguridad y software han publicado orientaciones y mitigaciones adicionales, entre ellos Akamai, Amazon Web Services (AWS), Arctic Wolf, Automattic, Cisco Talos, Corelight, CyCognito, Fastly, Google Cloud, Hadrian, Imperva, NetSPI, Orca Security, OX Security, Palo Alto Networks Unit 42, Pentest Tools, Rapid7, ReliaQuest, SOCRadar, Searchlight Cyber, Sophos, Tanium, Vercel, watchTowr y Zscaler.
El tiempo entre el parche y el exploit funcional se está reduciendo por razones estructurales. Antes, la mayor parte de la explotación que observábamos llegaba tras la publicación de una prueba de concepto pública. Un pequeño número de actores capacitados creaba los exploits y el resto esperaba. Esa dependencia se está debilitando. El análisis asistido por IA abarata convertir un diff de parche o un aviso en un exploit funcional. Como resultado, más actores pueden actuar en horas o incluso minutos una vez divulgados los detalles técnicos de una vulnerabilidad.
Deja una respuesta