PHP2Shell en el catálogo KEV: primeras shells en honeypots

📌 Novedades posteriores: PHP2Shell en PAN-OS: correcciones para cinco ramas y Panorama (29 de octubre de 2026) · PHP2Shell y Fragnesia: root en firewalls PAN-OS en 15 minutos (28 de octubre de 2026)

El 26 de octubre de 2026 CISA, la agencia estadounidense de ciberseguridad y seguridad de las infraestructuras, añadió las dos vulnerabilidades PHP2Shell, CVE-2026-109618 y CVE-2026-109619, a su catálogo Known Exploited Vulnerabilities (KEV). Las agencias civiles federales de Estados Unidos deben corregirlas antes del jueves 29 de octubre. Ese mismo fin de semana llegaron las primeras pruebas públicas de ejecución de código lograda, aunque obtenidas en honeypots.

Nuestros artículos anteriores trataban el anuncio de los dos fallos, las versiones corregidas del 21 de octubre, la tercera RCE CVE-2026-115560 y una semana de intentos de explotación sin éxitos confirmados. A continuación, las novedades.

Qué significa la inclusión en el KEV

Según The Register, la semana anterior CISA había advertido del peligro sin haber observado explotaciones logradas. Ahora la agencia considera ambas vulnerabilidades explotadas activamente, pero no ha indicado víctimas ni atacantes, ni detalles de los ataques. Un portavoz, citado por The Record, remitió a las reglas del KEV, según las cuales la «explotación activa» incluye tanto los intentos como los ataques logrados. Según Computer Weekly, CISA no sabe si los fallos se han usado en campañas de ransomware.

En la práctica, la inclusión confirma que las vulnerabilidades están en el punto de mira, no cuántos sistemas en producción se han comprometido realmente. El plazo solo vale para las agencias federales estadounidenses, pero CISA invita a todas las organizaciones a dar prioridad a las correcciones.

En su aviso actualizado, recogido por The Record, CISA pide:

• identificar e inventariar los sistemas con cualquier versión de PHP;
• aplicar las correcciones o desconectar los sistemas que no se puedan actualizar enseguida;
• tener en cuenta que en algunos casos un web application firewall puede ofrecer protección durante un tiempo limitado.

El aviso también enlaza las indicaciones de PHP y de las agencias de Australia, Canadá, Nueva Zelanda y Reino Unido.

Las primeras RCE logradas

Según The Register, el 24 de octubre el investigador Adel Karimi (Perplexity) registró 35 ejecuciones de shell logradas en tres honeypots con PHP 8.4.26 bajo Apache mod_php. También Computer Weekly informa de una ejecución remota de código en un honeypot con la misma versión y configuración, conocida el domingo 25 de octubre. Los detalles, según The Register:

• los ataques procedían de dos direcciones IP y usaban el agotamiento y la divulgación de memoria para llegar a la ejecución de código;
• una vez obtenida la shell, los atacantes intentaron contactar con servidores externos mediante PHP, curl y wget, sin lograr descargar más malware;
• la actividad es compatible con CVE-2026-109618, que Computer Weekly describe como corrupción de memoria; no hay rastro de CVE-2026-109619, un fallo ligado a un estado interno de la petición que ya no es válido;
• Karimi advierte de que los honeypots tenían una configuración favorable, con un solo worker: los resultados no dicen lo fiable que es el exploit contra servidores en producción.

También según The Register, el Threat Intelligence Lab de la Universidad de Delft ha contado más de 50.000 peticiones de explotación desde más de 600 direcciones IP en 70 países; 171 de esas direcciones no se limitaron a buscar servidores vulnerables y enviaron código de exploit o droppers de malware. Las fuentes no publican las direcciones: no hay indicadores de compromiso públicos.

Algunas alertas anteriores resultaron prematuras: Sophos atribuyó la actividad observada a escaneos e intentos fallidos, y Palo Alto Networks retiró la relación entre los fallos y una intrusión en una agencia gubernamental europea (The Register, The Record).

Sobre los tiempos, CrowdStrike, citada por Computer Weekly, explica que convertir los exploits en armas llevó más tiempo porque el PoC debe adaptarse a la versión de PHP y a la aplicación objetivo, con conocimientos específicos de contenedores Docker y paquetes. Según TechCrunch, única fuente sobre este punto, los dos fallos se conocían desde hacía dos años, pero se consideraban no explotables en la práctica, hasta que los investigadores de la empresa Calif encontraron un método con la ayuda de un modelo de IA.

Técnicas MITRE ATT&CK: T1190 (explotación de aplicaciones expuestas a Internet) y, para los intentos de descargar herramientas con curl y wget, T1105 (Ingress Tool Transfer).

Actualizaciones: las cifras dependen de la fuente

• Según el panel de Censys citado por The Record, de los 42 millones de servicios PHP expuestos a Internet, más de 10 millones se han actualizado desde el 21 de octubre; el 22 de octubre eran alrededor de 1 millón.
• El PHP2Shell Tracker de Infrawatch, citado por Computer Weekly, contaba a las 12:00 UTC del 27 de octubre unos 443.000 hosts visibles actualizados, en torno al 20% del total, con 31.000 más en las 24 horas anteriores: el 27,2% en el Reino Unido y el 19,7% en Estados Unidos.

Las dos herramientas miden conjuntos distintos y las cifras absolutas no son comparables, pero ambas indican que la mayoría de las instalaciones expuestas aún no está actualizada.

Impacto para las empresas europeas e italianas

El KEV no obliga a las empresas europeas, pero es una señal que conviene seguir. Las fuentes indican dónde pueden quedar instalaciones olvidadas:

• sitios pequeños o sin mantenimiento y PHP «escondido» dentro de productos y plataformas más grandes, también en socios externos (William Wright, Closed Door Security, a Computer Weekly);
• los backends de las apps para Android e iOS: según el análisis de NowSecure recogido por Cybersecurity360, los fallos no afectan a los teléfonos, pero un backend PHP comprometido puede exponer datos y API que usan las apps, incluidos los servicios a los que se accede mediante SDK de terceros.

Para las entidades sujetas a NIS2, la inclusión en el KEV es un elemento que documentar en la prioridad de las correcciones, junto con la verificación de los proveedores que gestionan aplicaciones PHP por cuenta de la empresa; un posible incidente significativo debe evaluarse a efectos de la notificación al CSIRT nacional (en Italia, el CSIRT Italia). En la sanidad hay que revisar primero los portales de pacientes, las citas en línea y las apps relacionadas.

Qué hacer ya

1. Actualiza a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o a las versiones corregidas de tu distribución o de tu hosting, y comprueba la versión que usa realmente el servidor web, no solo la de php -v.
2. Versiones sin soporte: pasa a una rama con soporte u obtén correcciones de tu proveedor; si no es posible, saca el sistema de Internet, como indica CISA.
3. Prioridad a Apache mod_php: es la configuración de las RCE logradas en los honeypots.
4. Usa un WAF solo como medida temporal, a la espera de la actualización.
5. Deja desactivado session.upload_progress.enabled si ya lo hiciste por CVE-2026-115560: el tercer fallo aún no está corregido.
6. Pide confirmación a tus proveedores de la actualización de aplicaciones, hosting y backends de las apps móviles.
7. Busca señales de compromiso: procesos PHP que lanzan shells, curl o wget, conexiones salientes inesperadas desde los servidores web, peticiones anómalas en los registros.

Cómo ayuda ARXDOME

ARX Shield muestra para cada máquina las vulnerabilidades abiertas por paquete, con las ya explotadas destacadas. El inventario de ARX Sentry enumera el software y los procesos de los servidores con el agente: ayuda a encontrar PHP y PHP-FPM. ARX Expose indica qué servicios públicos de tu empresa exponen productos reconocidos, para que empieces por los accesibles desde Internet.

Última actualización: 27 de octubre de 2026