Qué dicen el BSI, la CISA, ENISA, Cloudflare y AWS sobre PHP2Shell

Proyecto PHP y PHP Foundation

El aviso de php.net del 21 de octubre es la fuente operativa. Indica que ambos fallos pueden permitir la ejecución remota de código sin autenticación, que toda instalación de PHP que atiende peticiones web está expuesta, que mod_php presenta el mayor riesgo y que solo una actualización es una solución completa. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Según la publicación de la PHP Foundation del mismo día, se demostró una RCE completa en Apache mod_php con la configuración por defecto antes del código de la aplicación, y se confirmó en PHP-FPM mediante rutas de aplicación. La Foundation no da ningún número de compromisos.

NVD

Según la cronología de Tanium, la NVD publicó CVE-2026-109618 el 21 de octubre de 2026 a las 14:17 UTC con el estado «Undergoing Analysis». Cuando este sitio consultó la API de la NVD el 22 de octubre de 2026 hacia las 07:20 UTC, ambas entradas tenían el estado «Modified» y llevaban, junto a la puntuación CVSS v4.0 de 9.2 del equipo de seguridad de PHP, una puntuación CVSS v3.1 propia de la NVD (Primary) de 9.8 (Crítica), vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Las dos puntuaciones proceden de sistemas de valoración distintos y no se contradicen. Para las versiones corregidas, manda el aviso de PHP.

CISA

La alerta de la CISA del 21 de octubre de 2026 pide parchear de inmediato a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, inventariar PHP incluso donde solo es un componente y desconectar los sistemas que no puedan actualizarse, incluido PHP 8.1 y anteriores. Un firewall de aplicaciones web puede ofrecer cierta protección mientras tanto. Sobre la explotación: la CISA no había observado ninguna hasta su publicación. La alerta no dice que ninguna de las CVE se haya añadido al catálogo KEV. Este sitio volvió a consultar el feed JSON del KEV de la CISA el 22 de octubre de 2026 hacia las 08:05 UTC: la versión 2026.10.21 del catálogo (publicada el 21 de octubre a las 14:04 UTC) seguía sin incluir ninguna de las dos CVE.

ENISA, declaración conjunta de la UE y CERT-EU

ENISA publicó una declaración conjunta sobre las vulnerabilidades críticas de PHP. Según el texto consultado, el equipo de seguridad de PHP publicó las actualizaciones el 21 de octubre de 2026 a las 13:40 UTC, y los fallos pueden ejecutar código malicioso sin autenticación en servidores vulnerables. El aviso CERT-EU 2026-018 es un documento aparte: su versión 1.1 indica que las correcciones se publicaron el 21 de octubre a las 13:30 UTC, que circulan PoC, lo que aumenta la probabilidad de explotación en curso, y recomienda parchear de inmediato o aislar las aplicaciones expuestas públicamente hasta que se aplique y verifique una corrección. Las horas 13:30, 13:40 y 14:00 UTC se mantienen tal como las dan las fuentes.

Reino Unido y Países Bajos

El NCSC británico aconseja identificar PHP en general, no solo las versiones antiguas, aplicar el endurecimiento del equipo de PHP y desconectar un sistema si las mitigaciones provisionales no son posibles a tiempo. En los sistemas expuestos hay que buscar indicios de compromiso. Remite al repositorio php2shell del NCSC-NL con software que depende de PHP: un inventario inicial, no la prueba de que un producto no incluido sea seguro.

Canadá, Alemania y Japón

• Centro Canadiense de Ciberseguridad, AL26-026, 21 de octubre de 2026: ambas CVE se describen como use-after-free que podrían permitir a un actor no autenticado ejecutar código arbitrario. El Centro cita informes de fuentes abiertas sobre un PoC disponible y ninguna explotación activa constatada; cita las mismas cuatro versiones corregidas e indica que 8.1 y anteriores no recibirán versión oficial.
• BSI, alerta 2026-297981-1032, versión 1.0 del 21 de octubre de 2026: un CVSS v4.0 de 9.2 significa ejecución remota de código sin autenticación ni interacción del usuario. No se conoce ninguna explotación confirmada, pero ya hay informes no confirmados de exploits. El parche se esperaba a las 16:00 hora alemana (14:00 UTC) y debía aplicarse en cuanto se publicara. Léalo como la postura del BSI en el momento de esa versión, no como un levantamiento posterior de la alerta.
• JPCERT/CC publicó el 22 de octubre de 2026 su alerta completa JPCERT-AT-2026-0033: PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起. Indica que la explotación puede permitir ejecutar código arbitrario con los privilegios del proceso PHP, que JPCERT/CC ha confirmado un uso amplio del producto en Japón, y pide aplicar las correcciones cuanto antes e investigar si hubo compromiso. Añade que el PHP de las distribuciones Linux y los productos que incluyen PHP también pueden verse afectados. Para esa investigación transmite las pistas de los descubridores: cookies PHPSESSID inusualmente largas o mal formadas en respuestas anteriores, solicitudes multipart/form-data sospechosas seguidas de errores de límite de memoria de PHP o errores HTTP 500, y workers de PHP que se cayeron o reiniciaron de forma inesperada. No encontrar estas huellas no prueba que no hubo ataque. La alerta no formula una constatación de explotación propia. La lista JVN de JPCERT/CC incluyó esa misma mañana una entrada relacionada, con hora 10:30.
• La IPA (Information-technology Promotion Agency, Japón) publicó el 22 de octubre de 2026 la página PHPの脆弱性対策について (CVE-2026-109618, CVE-2026-109619: PHP2shell), como continuación de su solicitud de preparación del 21 de octubre. Describe CVE-2026-109618 como un fallo en la gestión de la falta de memoria (OOM) y CVE-2026-109619 como un fallo en el procesamiento de peticiones, mediante los que un tercero remoto puede ejecutar código arbitrario, cita las mismas cuatro versiones corregidas y recoge a Wiz, según la cual PHP desde 5.4 está afectado por al menos una de las dos vulnerabilidades. Para PHP 8.1 y anteriores, que no reciben corrección, la IPA aconseja pasar a una versión con soporte o a un producto parcheado, aplicar medidas provisionales o restricciones de acceso y, si no es posible, plantearse bloquear el acceso externo o detener temporalmente el servicio. La página no contiene ninguna declaración sobre explotación.

Singapur, Hong Kong y Tailandia

• La Cyber Security Agency de Singapur, alerta AL-2026-151 del 21 de octubre de 2026, actualizada el 22 de octubre: ambas CVE tienen CVSS v4.0 9.2 y pueden permitir ejecución remota de código sin autenticación. En «Known Exploitation» dice que hay informes de intentos de explotación generalizados y del desarrollo de varias pruebas de concepto. Afirma que todas las versiones de PHP están afectadas y pide actualizar de inmediato, priorizando los sistemas expuestos a Internet, y comprobar si hay PHP en los servidores web a través de componentes de terceros aunque el sitio principal no use PHP.
• La lista de boletines de HKCERT del 22 de octubre de 2026 califica «PHP Multiple Vulnerabilities» como riesgo extremadamente alto y señala que CVE-2026-109618 y CVE-2026-109619 se están explotando activamente. Es la formulación de HKCERT; el resumen no nombra ningún sitio comprometido.
• ThaiCERT (National Cyber Security Agency de Tailandia) publicó una alerta en X el 22 de octubre de 2026 a las 07:40 UTC (publicación). Dice que se ha publicado una prueba de concepto, enumera las mismas cuatro versiones corregidas, menciona PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed, y recuerda que los paquetes de distribuciones o paneles pueden mantener el número de versión antiguo con la corrección retroportada, que hay que reiniciar los workers de PHP tras actualizar y reconstruir las imágenes de contenedor desde imágenes base corregidas. No informa de un compromiso confirmado.

Cloudflare y las cifras del 22 de octubre

El blog de Cloudflare del 21 de octubre indica que las reglas WAF para planes gratuitos y de pago estaban activas desde las 03:02 UTC, que la vulnerabilidad se había filtrado antes de la publicación oficial y que Cloudflare había observado tráfico de ataque y cambios en los payloads dirigidos contra las reglas; los clientes debían parchear igualmente. Un artículo de Reuters del 22 de octubre de 2026 cita a Matthew Prince en una publicación en X (que este sitio no abrió): miles de intentos en las diez horas previas al anuncio, decenas de miles en los 45 minutos siguientes, cientos de miles en dos horas y millones en el momento de la publicación. El mismo artículo indica que sitios web gubernamentales en Europa y otros lugares se desconectaron y que Mitsubishi UFJ Financial Group y el Ministerio de Finanzas de Japón suspendieron temporalmente algunos servicios como medida de emergencia. Eso describe desconexiones, no un compromiso mediante PHP2Shell.

AWS y watchTowr

AWS indica que MadPot vio un intento de explotación el 17 de octubre de 2026, cuatro días antes de la divulgación, y más intentos y PoC el 21 de octubre, también antes del fin del embargo. No está claro si habrían tenido éxito en sistemas reales; tras el parche, PHP2Shell se explota de forma generalizada, en referencia a los intentos observados, no a una lista publicada de sitios comprometidos. watchTowr observa intentos activos de explotación de ambas CVE en su red de honeypots; según SecurityWeek, sin intentos exitosos.

El boletín de seguridad de AWS 2026-143-AWS (publicado el 21 de octubre de 2026 a las 14:30 PDT, actualizado por última vez a las 20:30 PDT) indica que los servicios de AWS no están afectados, pero que los clientes que usan versiones de PHP afectadas en Amazon WorkMail, Elastic Beanstalk, Amazon Linux o Lightsail podrían estarlo. El impacto se limita al worker de PHP afectado y a sus permisos a nivel de aplicación; hasta ahora no se ha establecido propagación entre clientes. El estado por servicio está en la página de estado de los fabricantes.

Datadog, Qualys, Tanium, Huntress y Elastic

• Datadog Security Labs indica que reprodujo ambos problemas de forma independiente y que la autenticación en la aplicación no detiene la vía de mod_php. Solo parchear es una solución completa. No reproducimos los pasos de reproducción.
• Qualys aconseja, en una actualización del 21 de octubre de 2026, priorizar el PHP expuesto públicamente, empezando por Apache mod_php.
• Tanium indica que se ha informado de explotación en la práctica, pero que los exploits públicos fiables aún escaseaban al redactar su texto y que ninguna CVE figuraba en la actualización del KEV del 21 de octubre revisada.
• Huntress aconseja actualizar de inmediato a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y, en la parte mostrada por la búsqueda, aún no había observado explotación entre sus socios.
• Elastic Security Labs afirma, en una publicación del 21 de octubre de 2026, que al escribirla no existía una prueba de concepto pública fiable de extremo a extremo, por lo que basa la detección en el resultado común de cualquier RCE en PHP: un servidor web o worker de PHP (php-fpm, php-cgi, lsphp, Apache, nginx) que inicia una shell, descarga una segunda fase con curl o wget o escribe nuevos archivos de script en la raíz web. La publicación enumera las reglas de Elastic (endpoint y SIEM) para ese comportamiento y consultas de inventario para localizar instalaciones de PHP. Elastic advierte que esto no garantiza una cobertura completa, por ejemplo ante ejecución sin archivos.

Distribuciones y proveedores de paneles en resumen

El boletín RHSB-2026-013 de Red Hat indica que algunas actualizaciones están disponibles y otras en preparación. Ubuntu ha publicado correcciones para todas las versiones con soporte. cPanel ha publicado actualizaciones para ea-php74 y superiores, Plesk correcciones para el PHP incluido. Detalles y límites de estas afirmaciones en la página de fabricantes.

Cierres preventivos

El PHPocalypse Tracker, mantenido por la comunidad, recoge sitios que se desconectaron por PHP2Shell a partir de informes públicos y sus propias comprobaciones. El 22 de octubre de 2026 tenía 50 entradas: 24 en Países Bajos, 17 organismos públicos y 44 ya de vuelta. Entre ellas, el Parlamento neerlandés y el NCSC-NL, DigiD, la Universidad de Viena, DeviantArt y 4chan (solo lectura). La autoridad francesa de protección de datos, la CNIL, aún devolvía HTTP 503 cuando lo comprobamos. La mayoría habla de precaución; ninguna entrada es un compromiso confirmado. Las horas son las del primer informe, no las del cierre real.