Ya están disponibles los parches de php2shell para las versiones de PHP 5.2 a 8.1

Principales conclusiones

• «php2shell» es el nombre que se le da a dos vulnerabilidades críticas de ejecución remota de código (RCE) en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619.
• PHP las corrigió en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, pero las ramas que han llegado al final de su ciclo de vida no reciben parches del desarrollador original.
• Se han notificado intentos de ataque antes del lanzamiento, así que aplica el parche ahora y reinicia todos los procesos de PHP.
• El servicio «Endless Lifecycle Support» (ELS) de TuxCare para entornos de ejecución ya dispone de versiones compuestas para las versiones de PHP que han llegado al final de su ciclo de vida.

La versión resumida

Ir a la versión completa ↓

En qué consiste: «php2shell» es el apodo que los investigadores dieron a CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas de ejecución remota de código en el propio PHP, no en ningún marco de trabajo ni sistema de gestión de contenidos (CMS). La noticia se filtró el 20 de octubre de 2026, antes de la divulgación prevista, y el equipo de seguridad de PHP adelantó su lanzamiento de emergencia al 21 de octubre.

Impacto: Ambas vulnerabilidades permiten que un atacante no autenticado ejecute código como el usuario del proceso de PHP; sin embargo, la facilidad con la que se puede explotar un servidor concreto depende de cómo se ejecute PHP en él. Se ha confirmado la ejecución remota completa de código (RCE) en PHP con mod_php de Apache con los límites predeterminados, y también se ha validado una vía de explotación contra PHP-FPM. Ir a esta sección →

Gravedad: El equipo de seguridad de PHP califica ambas vulnerabilidades con un 9,2 según el CVSS v4.0, lo que se considera crítico. La puntuación de 10,0 que se difundió tras la filtración nunca fue la calificación de PHP. Ir a esta sección →

A quién afecta: los avisos de PHP abarcan las versiones afectadas en las cuatro ramas con soporte, mientras que la herramienta de explotación filtrada afirma que funciona incluso en versiones anteriores a la 5.4.0. El proyecto original solo ofrece parches para las versiones 8.2 a 8.5, por lo que PHP 8.1, 8.0, 7.x y 5.x no reciben nada de php.net, y Mallory contabilizó aproximadamente 884 000 servidores conectados a Internet que ejecutaban una de esas versiones. Ir a esta sección →

Situación: Dane Knecht, director técnico de Cloudflare, informó de los primeros intentos de ataque contra sitios web en PHP a las 07:43 UTC del 21 de octubre, horas antes del lanzamiento, aunque no está claro cuántos tuvieron éxito. Ya están disponibles las versiones de Endless Lifecycle Support (ELS) para Runtimes que corrigen ambas vulnerabilidades (CVE) para todas las ramas fuera de soporte, desde PHP 5.2 hasta 8.1.

Haz esto ahora mismo: localiza todas las instalaciones de PHP que tengas, incluidas las copias integradas en el software de terceros y en los paneles de control, y empieza por todas aquellas que ejecuten Apache mod_php sin saltarte los hosts que utilizan FPM. Actualiza las ramas compatibles desde el código fuente original o desde tu distribución, y traslada las que hayan llegado al final de su vida útil a una versión fija de ELS o retíralas de la red pública. A continuación, reinicia o sustituye todos los procesos de PHP, ya que el código antiguo sigue atendiendo solicitudes hasta que ese proceso se cierre. Para ver qué se está ejecutando realmente:

ps aux | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[h]ttpd|[a]pache2'

Mientras revisas la lista, presta atención a los procesos de trabajo de PHP que inicien terminales o herramientas de descarga. Así es como suele manifestarse un ataque.

Ir a esta sección →

La mayoría de las emergencias relacionadas con PHP empiezan con una aplicación: un plugin de WordPress, una extensión de Magento o un paquete de Laravel que nadie ha tocado desde 2019. Lo actualizas, cambias algunas claves secretas y sigues adelante. Nada de eso afecta al intérprete subyacente.

php2shell no funciona así. Las vulnerabilidades se encuentran en el intérprete, por lo que el software afectado es, a grandes rasgos, «cualquier cosa que ejecute PHP», y la corrección solo se aplica a cuatro ramas que reciben mantenimiento. Cualquiera que siga utilizando PHP 7.4 en una aplicación de facturación heredada (y hay muchas) se ha enterado de la existencia de una vulnerabilidad crítica de ejecución remota de código (RCE) para la que no habrá ningún parche de los desarrolladores originales, nunca.

Además, hay un tercer problema. Estos fallos se hicieron públicos en forma de rumores antes de que se publicaran como parches, y los atacantes empezaron a sondear el sistema antes de que llegaran las correcciones.

La puntuación actual según el CVSS 4.0 del NIST es de 9,2 (crítica), pero circulaban otras cifras sin confirmar. La mañana del 20 de octubre, una publicación en Hacker News afirmaba que el jueves 22 de octubre se darían a conocer dos vulnerabilidades de ejecución remota de código en PHP, con una puntuación de 10,0 y que se remontaban a PHP 5. El autor de la publicación no aportó ninguna prueba más allá de «fuente: confía en mí, tío». La publicación fue retirada, pero ya había capturas de pantalla por todas partes.

Este rumor no se disipó, ya que watchTowr publicó que la información era cierta, que los fallos estaban sujetos a embargo y que todo el mundo debía esperar hasta el jueves. A las 19:33 UTC de esa misma tarde, Jakub Zelenka envió el aviso previo del equipo de seguridad de PHP a php.announce. En él se confirmaban dos vulnerabilidades críticas, ambas con una puntuación de 9,2 según el CVSS v4.0, y se anunciaba un lanzamiento previsto para el día siguiente, 21 de octubre, reservándose el derecho a adelantarlo si los detalles se hacían públicos o si aparecían casos de explotación.

El embargo se retrasó un día, y muchas otras personas estaban viendo las mismas capturas de pantalla. A las 07:43 UTC de la mañana siguiente, el director técnico de Cloudflare afirmó que la empresa estaba detectando los primeros ataques y que sus reglas provisionales del WAF se habían aplicado a todos los planes, incluido el plan gratuito.

Por cierto, el aviso previo de PHP no mencionaba ninguno de los dos CVE. Los identificadores se dieron a conocer por primera vez a través del material filtrado y de los informes de watchTowr, y los avisos de PHP los confirmaron cuando se publicaron las correcciones.

Antes de la publicación, la información disponible era escasa. watchTowr afirmó que creía haber reproducido el CVE-2026-109618; Huntress no había creado una prueba de concepto y, según Sansec, la captura de pantalla filtrada de PHP2Shell mostraba un banner en el que se afirmaba que se cubrían todas las versiones a partir de la 5.4.0. Los dos avisos de seguridad de PHP del 21 de octubre llenaron la mayoría de los vacíos.

109618, «RCE mediante corrupción OOM», se reduce a cómo PHP gestiona los errores de falta de memoria. Utiliza longjmp() para abortar la solicitud, y si falla alguna asignación mientras la memoria de la solicitud solo está parcialmente inicializada, el código de cierre detecta posteriormente ese estado anómalo o se desvía en función de él. El análisis en varias partes ofrece a los atacantes varias formas de provocar un error de memoria insuficiente (OOM) sin salirse de los límites aparentes, como por ejemplo, partes con un número ilimitado de encabezados. En mod_php, todo esto ocurre durante la inicialización de la solicitud, antes de que se ejecute ningún código de la aplicación.

CVE-2026-109619, «RCE a través de un estado global obsoleto», es un fallo de «uso tras liberación» (use-after-free) que se extiende a lo largo de varias solicitudes. Un error fatal, incluido el de falta de memoria (OOM), puede hacer que un trabajador persistente mantenga punteros a memoria que pertenecía a una solicitud que ya ha finalizado. Una solicitud posterior en el mismo proceso de trabajo accede entonces a ese estado obsoleto antes de que la inicialización normal lo restablezca. Es más complicado de llevar a cabo, pero PHP aún así confirmó la ejecución remota de código (RCE) contra mod_php y validó la ruta de sesión contra PHP-FPM.

Por lo tanto, la forma en que se ejecuta PHP es importante. mod_php es el peor caso en ambos aspectos. FPM cierra un proceso hijo cuando falla el inicio de una solicitud, lo que bloquea la secuencia de OOM más limpia, pero PHP sigue considerándolo vulnerable. PHP considera que FrankenPHP es probablemente vulnerable a ataques OOM independientes de la aplicación, al igual que mod_php, y LSAPI se comporta más bien como FPM.

La conexión del progreso de la subida

Ese banner de la versión 5.4.0 resultó ser una buena pista. PHP 5.4 introdujo el progreso de subida por sesión, que permite a un script comprobar en qué punto se encuentra una subida multiparte. Está activado por defecto, y el propio aviso de PHP lo describe como una función poco utilizada. También es un explotador confirmado en CVE-2026-109619, ya que accede a la gestión de sesiones antes de la inicialización normal y puede recuperar el estado que dejó una solicitud interrumpida, no session_start() Hay que llamar. El análisis de un investigador ya había señalado un «use-after-free» en esta ruta de ejecución antes de que se publicaran los avisos, y había dado en el clavo.

Desactivar la función sigue sin ser una solución. Gina Banyard, del equipo central de PHP, afirmó desde el principio que la única medida de mitigación es aplicar un parche, y ambos avisos de seguridad la respaldan, al señalar que una actualización es la única solución completa y fiable. Desactivar el progreso de la subida bloquea la ruta de sesión demostrada, pero no ninguna de las demás rutas del ciclo de vida.

Si hoy no es posible aplicar el parche a algunos servidores, se activará la solución provisional de PHP para esa ruta. php.ini o pasar por allí sin cita previa en conf.d, y Sansec incorpora además un modo de sesión estricto:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Los grupos de FPM pueden anular la configuración principal del archivo INI, por lo que debes comprobar la configuración efectiva de cada grupo. Si un grupo necesita su propia configuración alternativa, utilízala y, a continuación, reinicia sus procesos de trabajo:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

El modo de sesión estricto es una característica propia de PHP orientaciones sobre la seguridad de las sesiones ha promovido durante años, por lo que la primera opción casi no cuesta nada, aunque es posible que Redis o los gestores de sesiones de bases de datos no implementen la comprobación de ID en la que se basa. Otras soluciones provisionales incluyen fatal_error_backtraces=0 en PHP 8.5 y bloqueando las solicitudes multiparte en el front-end si la aplicación nunca admite subidas de archivos. En el caso de CVE-2026-109618, la medida provisional principal en la configuración de PHP consiste en aplicar memory_limit=-1 de forma administrativa y reiniciando cada proceso de trabajo, lo que elimina el límite predecible por solicitud en el que se basa el exploit confirmado. Hay que manejar esta medida con cuidado, ya que también desactiva la protección de PHP contra scripts fuera de control, y PHP indica que aún no está completa. Ninguna de estas medidas es una solución definitiva. Trátalas como medidas provisionales hasta que todos los servidores estén parcheados.

Por qué el PHP «al final de su vida útil» es el mayor problema

La página de versiones compatibles de PHP es muy clara al respecto. Las ramas 8.4 y 8.5 cuentan con soporte activo; las 8.2 y 8.3 solo reciben correcciones de seguridad; y todas las versiones anteriores han llegado al final de su ciclo de vida. Las ramas que han llegado al final de su ciclo de vida no reciben actualizaciones de seguridad de php.net, y ni siquiera una vulnerabilidad crítica de ejecución remota de código (RCE) cambia esta situación.

Las cifras sobre lo que sigue en uso no son nada halagüeñas. Mallory contabilizó unos 884 000 servidores expuestos a Internet cuyo banner HTTP indicaba PHP 8.1 o una versión anterior a fecha de 20 de octubre, lo que supone aproximadamente el 59 % de los servidores que indicaban alguna versión. Los banners no constituyen una confirmación de vulnerabilidad, y algunos de esos servidores ejecutan paquetes adaptados a versiones anteriores. Sigue siendo una cifra abrumadora de servidores expuestos a Internet que indican una versión obsoleta de PHP.

Las instalaciones que causan problemas son aquellas que nadie considera servidores PHP: los dispositivos preconfigurados de los proveedores y el software de Windows que incluye su propio php-cgi.exe (ELS for Runtimes también ofrece versiones de PHP para Windows, precisamente por este motivo). Paneles de control. Una wiki interna que alguien creó en 2017 y de la que nunca más se volvió a hablar.

Imagina una agencia de 30 personas que aloja unos cuantos cientos de sitios web de clientes en WordPress en un único servidor con cPanel, con la mitad de las cuentas fijas en PHP 7.4 porque un tema premium deja de funcionar correctamente en la versión 8.x. Nadie va a migrar todos esos sitios a PHP 8 antes del viernes. Actualizar PHP es un proyecto de aplicación, y esa es precisamente la razón por la que siguen funcionando tantas instalaciones de PHP 7.x.

Esta es la laguna que ELS para Runtimes viene a cubrir. TuxCare adapta las correcciones de seguridad a las ramas que han llegado al final de su ciclo de vida, de modo que un sitio fijado en la versión 7.4 recibe la corrección de php2shell sin tener que realizar una migración forzada a PHP 8 mientras existe una vulnerabilidad de ejecución remota de código (RCE) activa. La migración sigue siendo necesaria, pero se lleva a cabo según el calendario que elija cada uno.

De dónde procede la corrección de php2shell, por rama, con las fechas de soporte de PHP:

Ambos avisos indican que las versiones parcheadas son la 8.5.12, la 8.4.27, la 8.3.36 y la 8.2.35, y el registro de cambios de PHP incluye los detalles por rama. Instala la tuya y, a continuación, comprueba que los procesos que atienden las solicitudes la ejecutan realmente.

Si PHP procede de los propios repositorios de tu distribución de Linux, lo que cuenta es su aviso de seguridad. Las distribuciones suelen aplicar correcciones retroactivamente sin modificar el número de versión del desarrollador original, por lo que la cadena de versión por sí sola no sirve para determinar nada.

Consigue hoy mismo ELS para Runtimes →

PHP ya ha pasado por esto antes

En mayo de 2012, se dieron a conocer los detalles de CVE-2012-1823, un fallo que permitía la ejecución remota de código en php-cgi, se hicieron públicas por error antes de que la corrección estuviera lista. El equipo de PHP lanzó rápidamente las versiones 5.3.12 y 5.4.2. Stefan Esser y otros demostraron enseguida que la corrección podía eludirse, por lo que PHP tuvo que publicar nuevas versiones unos días más tarde, ya que Según informó Computerworld en aquel momento.

Luego está el CVE-2024-4577, el de Windows php-cgi Inyección de argumentos a partir de junio de 2024. Akamai detectó intentos de explotación contra sus honeypots en las 24 horas siguientes a la divulgación, según Noticias Hacker.

Los errores que se filtran acortan los plazos de todo el mundo, incluidos los de los desarrolladores que escriben la corrección, y las correcciones apresuradas a veces requieren una segunda revisión. Sigue atento a los avisos durante unos días después de aplicar el parche.

Mira lo que genera PHP

La ejecución remota de código (RCE) a nivel de intérprete suele presentar las mismas características, independientemente de cómo funcione el fallo. Un proceso de PHP como, por ejemplo, php-fpm, php-cgi, lsphp o un proceso de Apache inicia algo que normalmente nunca inicia. Shells, Python o Perl, curl o wget. Las líneas de comando que contengan /dev/tcp/ o mkfifo son indicios clásicos de un «reverse shell», al igual que un php -r Llamada en una sola línea fsockopen. Una ráfaga de whoami, id o uname -a Que alguien esté ejecutando el servidor web como usuario es señal de que está realizando un reconocimiento. Ninguno de estos indicios es una prueba por sí solo, ya que las herramientas de administración también realizan algunas de esas mismas acciones. Lo que importa es un árbol de procesos inusual que coincida con una solicitud o con un archivo recién creado.

En los servidores Linux que carecen de sistemas de detección de amenazas en los puntos finales, la herramienta gratuita «process-watcher», creada por Florian Roth, registra todos los programas que inicia un proceso PHP, junto con su línea de comandos completa. Roth deja claro que la herramienta no previene nada, sino que se limita a observar. De momento, para obtener una visión rápida de la situación en un momento dado:

ps -eo pid,ppid,user,args --forest | grep -A3 '[p]hp-fpm'

Si se detecta algo, aísla el servidor y guarda los registros del servidor web y de PHP antes de que alguien «limpie» nada. Un registro de acceso «limpio» no significa que todo esté en orden, ya que los registros predeterminados no registran los cuerpos de las solicitudes POST. Busca webshells, archivos nuevos en el directorio raíz web, nuevas tareas cron y nuevas cuentas. Aplicar parches a un host comprometido es como cerrar la puerta con el intruso todavía dentro. Cuando no sea posible aplicar los parches de inmediato, el CERT-EU recomienda considerar la posibilidad de retirar de las redes públicas las aplicaciones conectadas a Internet hasta que se haya implementado una solución. Un WAF o una VPN delante de una sucursal antigua permite ganar tiempo, y eso es todo lo que permite.

Lo primero es el inventario, y la lista suele ser más larga de lo que nadie espera. Este bucle comprueba las ubicaciones habituales de Linux, las compilaciones de ELS en /opt/alt/ incluidos, y muestra la versión que indica cada archivo binario. Es un punto de partida, ya que las compilaciones personalizadas y los paquetes de los proveedores pueden encontrarse en cualquier lugar:

for p in /usr/bin/php /usr/bin/php[0-9]* /opt/alt/php*/usr/bin/php; do [ -x "$p" ] && echo "$p $("$p" -r 'echo PHP_VERSION;')"; done

Esto muestra lo que hay en el disco, no lo que ejecuta cada sitio web, ya que los grupos de FPM, los vhosts y los paneles de control pueden apuntar cada uno a un binario diferente. Comprueba también esas configuraciones. Las ramas compatibles reciben la actualización del desarrollador original o de la distribución. Las compilaciones de ELS for Runtimes se actualizan a través del gestor de paquetes habitual, utilizando los comandos que figuran en la documentación de PHP de ELS for Runtimes de TuxCare. En sistemas basados en RPM, el comando es `sudo yum update alt-php*`. En Debian y Ubuntu, actualiza las listas de paquetes y actualiza los paquetes alt-php:

sudo apt-get update
sudo apt-get upgrade alt-php*

A continuación, el paso que se suele omitir. No basta con instalar el paquete corregido si los trabajadores siguen ejecutando el código antiguo. Un servidor maestro de PHP-FPM en funcionamiento, o mod_php Se carga dentro de Apache, mantiene el código antiguo en memoria hasta que se reinicia, y un contenedor lo conserva hasta que se sustituye. Los servidores de alojamiento compartido con docenas de grupos FPM son el caso clásico, en el que una versión se reinicia y otras tres no. Comprueba que todos los procesos maestros de FPM se hayan iniciado después de que se aplicara la actualización:

ps -eo pid,lstart,args | grep '[p]hp-fpm: master'

Por último, no cierres el ticket basándote en la comparación de versiones de origen realizada por un escáner. Una versión de ELS o una compilación de distribución adaptada a versiones anteriores puede seguir indicando el número de versión original del desarrollador original, por lo que los escáneres que solo leen cadenas de versión pueden marcar como vulnerables hosts que ya están parcheados. Si tus herramientas lo admiten, introdúceles los datos de seguridad legibles por máquina de TuxCare, que incluyen fuentes OVAL y CSAF. Registra el paquete instalado, el aviso de seguridad al que da respuesta y el proceso que realmente atiende las solicitudes, porque eso es lo que te pedirá un auditor.

Por qué es importante php2shell

Un entorno de ejecución es una dependencia, y dejar de ofrecer soporte para él significa que cualquier nueva vulnerabilidad crítica puede permanecer sin solucionar indefinidamente. Los equipos realizan un seguimiento minucioso de sus paquetes de Composer y, a continuación, los ejecutan en un intérprete que dejó de recibir parches de seguridad hace años.

La filtración también puso de manifiesto lo poco que se avisa con antelación. Los primeros rumores se confirmaron en cuestión de horas, la corrección se publicó al día siguiente y los intentos de ataque aparecieron antes incluso de que se publicara. Una frase como «Actualizaremos el próximo trimestre» no resiste un plazo como ese.

También ha surgido una vía para hacerlo uno mismo. PHP ha incorporado retrocompatibilidades para las versiones 7.4, 8.0 y 8.1 en php-src sin etiquetar las versiones, y los scripts de la comunidad ahora recompilan PHP a partir del código fuente con ellas. Puede funcionar para un único servidor autocompilado, pero solo corrige php2shell y nada posterior, omite los paquetes de las distribuciones, `mod_php` y `lsphp`, y convierte cada futura vulnerabilidad CVE de PHP de nuevo en un proyecto de compilación.

Así que aplica ahora los parches a las ramas compatibles y reinicia lo que haya que reiniciar. En cuanto al PHP que php.net ha dejado de mantener, trasládalo a una versión ELS corregida o retíralo de Internet, y luego incluye la migración real en el calendario en lugar de dejarla en una lista de deseos.

Consigue hoy mismo ELS para Runtimes →

Cronología

Referencias

Las fuentes principales de esta entrada son los avisos de seguridad de PHP sobre la ejecución remota de código (RCE) mediante corrupción por desbordamiento de memoria (OOM) (CVE-2026-109618) y la ejecución remota de código (RCE) mediante un estado global obsoleto (CVE-2026-109619), el aviso previo del equipo de seguridad de PHP en php.announce (20 de octubre de 2026), la página de versiones compatibles de PHP y el registro de cambios de PHP 8, las preguntas frecuentes sobre php2shell de watchTower, la investigación sobre php2shell de Sansec, el informe de respuesta rápida de Huntress, el aviso de seguridad 2026-018 del CERT-EU, el análisis de exposición de Mallory, el «process-watcher» de Florian Roth, las entradas del NVD para CVE-2026-109618 y CVE-2026-109619, la cobertura de The Hacker News y la documentación de TuxCare sobre ELS para entornos de ejecución de PHP.