El equipo de seguridad de PHP había anunciado dos vulnerabilidades críticas en el propio intérprete, no en un framework o plugin. Son CVE-2026-109618 y CVE-2026-109619, conocidas en conjunto como PHP2Shell. PHP les asignó una puntuación de 9,2 en CVSS v4.0. Informes filtrados antes del parche hablaban de 10,0, pero esa cifra no estaba verificada.

session.upload_progress.enabled = 0

El aviso 2026-018 de CERT-EU describió el impacto como ejecución remota de código sin autenticación. CERT-EU y la ACSC australiana señalaron que PHP 5 y las versiones posteriores podían estar afectadas. PHP todavía no había confirmado oficialmente el rango de versiones afectadas cuando se cerró el informe. Los parches previstos cubrían PHP 8.2, 8.3, 8.4 y 8.5. Los informes previos mencionaban 8.5.12, 8.4.27, 8.3.36 y 8.2.35, pendientes de confirmación en el anuncio oficial.

La divulgación rompió el calendario habitual de los embargos de seguridad. Sobre las 15:20 UTC del 20 de octubre, una publicación anónima en Hacker News avisó de que dos fallos críticos de RCE en PHP estaban a punto de hacerse públicos. La publicación fue eliminada, pero circularon capturas. Según el informe, el embargo original terminaba el 22 de octubre. PHP adelantó entonces el lanzamiento al 21 de octubre a las 14:00 UTC y dejó abierta la posibilidad de publicarlo antes si aparecían indicios de explotación activa. CERT-EU publicó el aviso 2026-018, watchTowr reprodujo uno de los fallos y el vídeo de demostración de un investigador fue retirado posteriormente.

Los primeros análisis relacionaron el problema con el código de progreso de subida de sesiones de PHP. A las 05:00 UTC del 21 de octubre, GMO Flatt Security aclaró que el cambio de configuración que se estaba difundiendo no ofrecía una protección completa y probablemente podría esquivarse. A las 07:43 UTC, Dane Knecht, director técnico de Cloudflare, informó de los primeros ataques y dijo que la empresa había activado reglas WAF de emergencia para todos sus clientes, incluidos los planes gratuitos. Huntress, watchTowr y la ACSC no habían confirmado explotación observada en Internet cuando publicaron sus respectivas actualizaciones.

En pocas horas aparecieron repositorios de prueba de concepto en GitHub. Algunos servían para comprobar la vulnerabilidad y otros afirmaban contener exploits funcionales. Al menos una auditoría independiente concluyó que el código de explotación que circulaba no funcionaba. Cuando se publica un parche, los atacantes pueden comparar el código corregido con la versión vulnerable. Sansec esperaba que los ataques masivos comenzaran pocos minutos después del lanzamiento.

La superficie de ataque sospechada está en el procesamiento de datos multipart por parte del intérprete PHP. Este formato se utiliza en las subidas de archivos y se analiza antes de que se ejecute el código de la aplicación. Si esa evaluación es correcta, las comprobaciones de acceso, la protección CSRF y la validación de archivos llegan demasiado tarde. Desactivar las subidas de archivos de PHP puede no impedir el análisis de una petición multipart. Por tanto, cualquier página que acepte datos POST podría ser relevante, no solo un formulario de subida. PHP no había confirmado la causa exacta y los investigadores no coincidían sobre el componente afectado. La recomendación común era actualizar o parchear PHP.

La medida de emergencia más difundida fue `session.upload_progress.enabled = 0`. GMO Flatt explicó después que no bastaba como protección. Otro investigador sostuvo que la segunda vulnerabilidad seguía siendo accesible a través del analizador multipart aunque esa opción estuviera desactivada. Joe Ferguson, responsable de la versión PHP 8.6, también recomendó no confiar en los ajustes INI. La opción es PHP_INI_PERDIR y no puede modificarse durante la ejecución con `ini_set()`. Un cambio aplicado en la configuración de CLI en lugar del pool de PHP-FPM, o colocado en `.user.ini` bajo mod_php, puede no tener ningún efecto y hacerlo en silencio. Desactivarla elimina los indicadores de progreso de las subidas y puede añadir una capa defensiva, pero no resuelve el incidente.

El mayor problema está en las ramas sin mantenimiento. PHP 8.1 llegó al final de su vida útil en diciembre de 2025 y PHP 8.0 lo hizo en noviembre de 2023. PHP 7.x y 5.x habían quedado fuera de soporte años antes. Si los fallos se remontan realmente a PHP 5, esas instalaciones no recibirán un parche del proyecto PHP. Un análisis de Shodan realizado por Mallory el 20 de octubre encontró unos 1,5 millones de hosts expuestos a Internet que anunciaban una versión de PHP. Aproximadamente 884.000, el 59 %, utilizaban una rama sin parche previsto. La estimación incluía 369.000 hosts con PHP 5.x, 329.000 con 7.x y 186.000 con 8.0 u 8.1. Otros 740.000 hosts ocultaban su versión, por lo que la exposición real probablemente es mayor. Estos recuentos de banners no equivalen a un recuento de sistemas vulnerables.

Los mismos datos identificaron unos 53.600 hosts PHP en India. Cerca de 19.800 de los que mostraban una versión utilizaban una rama sin parche previsto. Los banners no permiten saber quién opera esos sistemas. Entre las instalaciones antiguas suelen encontrarse portales abandonados, sitios de pequeñas empresas y entornos de hosting compartido que llevan años sin mantenimiento.

Los operadores de una rama fuera de soporte tienen varias opciones. Pueden migrar a una versión compatible, conseguir un parche retroportado de su distribución o proveedor de hosting, retirar el sistema de Internet mediante una VPN o una lista de permitidos, o apagarlo. Las distribuciones empresariales y algunos proveedores mantienen paquetes antiguos según sus propios calendarios. Por eso hay que comprobar la CVE en el aviso del proveedor y no confiar únicamente en el número de versión. CERT-EU recomienda dejar los sistemas fuera de línea cuando no sea posible parchearlos.

La primera medida debe ser inventariar todos los entornos PHP, incluidos PHP-FPM, Apache mod_php, CGI, contenedores, runners de CI, cPanel, Plesk, XAMPP y appliances que incorporen PHP. Los sistemas expuestos y todos los que ejecuten PHP 8.1 o anterior deben entrar en la lista de emergencia. El cambio debe prepararse con antelación y debe quedar claro quién puede aprobar un reinicio. Los usuarios de Cloudflare deben configurar las reglas gestionadas para bloquear, no solo registrar, y deben impedir el acceso directo al origen.

Después de la publicación, las ramas compatibles deben actualizarse de inmediato mediante php.net o el aviso de la distribución. Hay que reiniciar PHP-FPM, Apache, Laravel Octane y los workers de cola, porque los procesos de larga duración conservan el intérprete antiguo en memoria. La verificación debe hacerse sobre el proceso que atiende las peticiones, no únicamente con `php -v` desde la shell. Los clientes de hosting gestionado deben preguntar al proveedor cuándo estará disponible el paquete corregido.

La revisión de incidentes debe buscar archivos PHP nuevos o modificados en las raíces web y directorios de subida, nuevos administradores en el CMS, conexiones salientes inesperadas y workers PHP que se caigan. Los investigadores señalan que los intentos fallidos de explotación pueden provocar el cierre de un worker. Un aumento de errores 5xx en peticiones POST merece una investigación. Un servidor expuesto con una rama fuera de soporte debe considerarse potencialmente comprometido hasta completar las comprobaciones. Después deben rotarse las credenciales, claves API y roles cloud presentes en ese sistema.