PHP2Shell: parches de emergencia para dos vulnerabilidades críticas en PHP: qué hacer ahora mismo

El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas de ejecución remota de código (RCE), agrupadas bajo el nombre de PHP2Shell. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 se encuentran en el propio motor de PHP, y no en ninguna aplicación concreta, por lo que es vulnerable cualquier servidor que procese solicitudes web a través de PHP — incluidos PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Ambas vulnerabilidades están valoradas en 9,2 puntos según CVSS v4.0 y permiten que un atacante no autenticado ejecute código arbitrario. Las correcciones están disponibles en las versiones PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35: actualizar el runtime es la única solución completa.

Detalles técnicos de las vulnerabilidades

Ambas vulnerabilidades pertenecen a la clase Use After Free (CWE-416), pero explotan mecanismos distintos dentro de PHP.

CVE-2026-109618 — RCE mediante corrupción de memoria durante el tratamiento de un error de falta de memoria (OOM). Según el aviso de seguridad oficial, PHP utiliza longjmp() para manejar errores OOM y, en determinados contextos, la solicitud puede interrumpirse cuando los datos internos aún no están completamente inicializados. Al mismo tiempo, el procedimiento de finalización de la solicitud trata los datos no válidos como si fueran correctos. En la configuración Apache mod_php esto es especialmente peligroso: la rutina de apagado (shutdown) se llama incondicionalmente incluso si el inicio de la solicitud falla, y el análisis automático del cuerpo de la solicitud puede agotar el límite de memoria antes de que empiece a ejecutarse el código de la aplicación.

CVE-2026-109619 — RCE mediante estado global obsoleto. Como se indica en el aviso de seguridad, el estado interno perteneciente a una solicitud puede conservarse después de liberarse la memoria. Una solicitud posterior, procesada por el mismo worker, puede utilizar ese estado obsoleto antes de que la inicialización normal lo reinicie. Se ha confirmado la ejecución de código a través de la ruta fatal backtrace en mod_php y mediante el ciclo de vida de las sesiones, tanto en mod_php como en PHP-FPM.

Además de la ejecución de código, el atacante puede leer la memoria del proceso de trabajo de PHP, que puede contener contraseñas, tokens de autenticación, claves API y certificados de otras solicitudes, sin necesidad de obtener RCE previamente.

Versiones y configuraciones afectadas

Son vulnerables todas las versiones de PHP anteriores a 8.2.35, 8.3.36, 8.4.27 y 8.5.12. El código vulnerable lleva presente en PHP más de diez años, afectando a versiones hasta PHP 5.4. PHP señala Apache mod_php como la configuración con el riesgo confirmado más alto: para CVE-2026-109618 se ha demostrado un exploit que se activa antes de que se ejecute ningún código de la aplicación. PHP-FPM también es vulnerable: para CVE-2026-109619 se ha confirmado una vía de explotación a través del ciclo de vida de las sesiones.

Reacción del sector

Incluso antes de la publicación de los parches, Cloudflare, según el CTO de la compañía, Dane Knecht, detectó intentos tempranos de explotación y desplegó reglas WAF de emergencia, calificándolas como una medida temporal. Al mismo tiempo, ninguna fuente ha confirmado una intrusión exitosa. La empresa watchTowr, que reprodujo CVE-2026-109618, no había detectado, a las 11:26 UTC del 21 de octubre, explotación in the wild. Según los datos de Huntress, en el momento de la publicación de su informe tampoco había código de exploit público disponible.

Varias organizaciones desactivaron preventivamente sus servicios. BambooHR suspendió sus operaciones en Estados Unidos, Canadá e Irlanda, advirtiendo de interrupciones en el procesamiento de nóminas. En los Países Bajos se desconectaron los portales gubernamentales MijnOverheid, DigiD, el sitio web de la cámara baja del parlamento, el centro nacional de ciberseguridad y varios sistemas educativos.

Por qué la configuración session.upload_progress.enabled no es una protección

Antes de la publicación de los parches, se difundió activamente en la comunidad la recomendación de establecer session.upload_progress.enabled=0 como solución temporal. La empresa tokiota GMO Flatt Security propuso inicialmente esta medida, pero posteriormente retiró la recomendación, declarando que esta configuración por sí sola no constituye una corrección completa y que se esperan formas de sortearla.

La desarrolladora del núcleo de PHP Gina Peter Banyard escribió de forma tajante: «Lo único que puedo decir es que la única medida de protección es actualizar PHP. Por desgracia, sé demasiado».

Los avisos de seguridad publicados lo confirmaron: desactivar session.upload_progress.enabled solo bloquea las vías de explotación confirmadas de CVE-2026-109619 a través de sesiones, pero no cubre otras variantes y no afecta en absoluto a CVE-2026-109618. La empresa watchTowr evalúa los cambios en los archivos INI como ineficaces para impedir la explotación.

Recomendaciones sobre actualización y medidas temporales

Actualizar el runtime de PHP es la única solución completa. Es necesario actualizar exactamente la instancia de PHP que atiende las solicitudes web (PHP-FPM, mod_php o CGI) y, a continuación, reiniciar Apache, PHP-FPM y todos los workers de larga duración. Actualizar las aplicaciones (WordPress, Laravel, etc.) no actualiza el runtime de PHP.

Si la actualización inmediata no es posible, según el aviso de seguridad oficial de PHP, las siguientes medidas reducen el riesgo en rutas de ataque concretas, pero no hacen que el servidor sea seguro:

• Para CVE-2026-109618: establecer memory_limit=-1 de forma que las aplicaciones no puedan sobrescribir el valor; mantener post_max_size bajo; aplicar límites de tamaño de las solicitudes a nivel del servidor web o del proxy. PHP advierte: no utilice RLIMIT_AS ni RLIMIT_DATA como sustituto — pueden activar la misma ruta vulnerable.
• Para CVE-2026-109619: establecer session.upload_progress.enabled=0 y reiniciar todos los workers; en PHP 8.5, adicionalmente establecer fatal_error_backtraces=0.
• Aislamiento: CERT-EU recomienda considerar el aislamiento de las aplicaciones PHP expuestas a internet de las redes públicas hasta la instalación del parche — mediante VPN, listas de clientes permitidos o autenticación en el perímetro.
• Minimización de las consecuencias de una posible intrusión: reducir el volumen de datos en el servidor, eliminar credenciales almacenadas y roles en la nube, rebajar privilegios y garantizar el registro de logs en un almacenamiento protegido.

Versiones de PHP sin soporte

PHP 8.1 y versiones anteriores no reciben actualizaciones por parte del proyecto PHP. Sin embargo, dada la criticidad de las vulnerabilidades, el equipo de seguridad de PHP ha publicado backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1. Las distribuciones Linux y los proveedores LTS pueden ofrecer sus propias correcciones: compruebe el changelog del paquete en busca de los CVE, y no el número de versión, tal como recomienda Debian.

Detección y monitorización

Según las recomendaciones de Huntress, la explotación de este tipo de vulnerabilidades suele manifestarse como procesos hijo sospechosos generados por los workers de PHP — shells, intérpretes, herramientas de descarga y comandos de reconocimiento. Estos indicadores son signos generales de compromiso de PHP, y no específicos de PHP2Shell.

Los investigadores que descubrieron las vulnerabilidades recomiendan, tras la actualización, revisar los logs en busca de: solicitudes multipart inusuales acompañadas de errores de límite de memoria o repeticiones de HTTP 500; cookies PHPSESSID anómalamente grandes en las respuestas; reinicios inexplicables de los workers de PHP.

PHP2Shell es un caso poco habitual en el que la vulnerabilidad afecta no a una aplicación concreta, sino al propio runtime del lenguaje, haciendo vulnerable incluso a un servidor con una página muy simple. La prioridad de actualización es máxima: en primer lugar, los servidores con Apache mod_php, y después los de PHP-FPM. Para las versiones sin soporte, aplique los backports o aísle los servidores de internet. Las reglas de WAF y los cambios de configuración reducen el riesgo en rutas específicas, pero no sustituyen al parche.