php2shell (CVE-2026-109618 / 109619) no se puede evaluar con php -v: dónde divergen los números de versión entre FPM, Docker y las distribuciones

Si el PHP que atiende las peticiones web (PHP-FPM, el mod_php de Apache, php-cgi, FrankenPHP, LiteSpeed) es anterior a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, le afectan CVE-2026-109618 y CVE-2026-109619, conocidas como php2shell. La solución es actualizar a una de estas versiones (o, en paquetes de distribución, al paquete corregido) y reiniciar los procesos. Lo que hay que comprobar no es el php -v local, sino «el PHP que realmente sirve la web» y «la versión del paquete instalado».

Este artículo se centra en cuatro puntos en los que juzgar solo por el número de versión lleva a una conclusión equivocada. Todas las cifras y datos de estado son a fecha de 2026-10-22, y las fuentes de cada apartado se enumeran al final.

Qué se sabe a fecha de 2026-10-22

El aviso de PHP afirma que «la única solución completa es actualizar». Las mitigaciones para el periodo previo a la actualización se tratan más adelante en este artículo.

Trampa 1: php -v y el PHP expuesto a la web pueden ser distintos

php -v ejecutado por SSH informa de la versión del PHP de CLI. Las peticiones web las atienden procesos de PHP-FPM o mod_php cargado en Apache, que son binarios y paquetes distintos. Si has instalado un PHP más reciente solo para la CLI, ejecutas varias versiones en paralelo o un pool de FPM apunta a otra versión, el lado web puede seguir siendo antiguo aunque php -v muestre una versión corregida.

Hay varias formas de ver la versión real del lado web.

# FPM en Debian / Ubuntu (con nombre por versión)
php-fpm8.3 -v

# FPM en sistemas de la familia RHEL
php-fpm -v

# Comprobar si mod_php está cargado en Apache
apachectl -M | grep -i php

El método más fiable es hacer que el PHP que realmente se ejecuta vía web informe de su propia versión. Coloca un archivo temporal con un nombre difícil de adivinar y bórralo en cuanto lo hayas comprobado.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Si PHP_SAPI es fpm-fcgi, PHP se ejecuta con FPM; apache2handler significa mod_php; cgi-fcgi significa CGI. Evita dejar phpinfo() expuesto, ya que por sí mismo filtra información.

El reinicio es otro paso que se pasa por alto con facilidad. Aunque se sustituya el paquete, los procesos de php-fpm o Apache que ya están en marcha pueden seguir ejecutando el código antiguo. Algunas configuraciones se reinician automáticamente al actualizar paquetes; otras no. Tras actualizar, reinicia FPM / Apache y vuelve a comprobar la versión del lado web con los métodos anteriores.

Trampa 2: con Docker, no se puede juzgar por el nombre de la etiqueta

La imagen oficial de php tiene «etiquetas móviles» como 8.3 y 8.3-fpm, cuyo contenido se sustituye, y etiquetas fijas como 8.3.30, que fijan la versión.

• Aunque una etiqueta móvil pase a una versión corregida en Docker Hub, tu copia local sigue siendo la imagen antigua hasta que vuelvas a hacer pull. Los contenedores en ejecución también siguen usando la imagen antigua hasta que se recreen. Un Dockerfile con FROM php:8.3-fpm seguirá construyéndose sobre la base antigua si esta permanece en la caché de compilación.
• Una etiqueta fija se queda antigua para siempre hasta que cambies tú el número.

Puedes comprobar si se han publicado las etiquetas de las versiones corregidas mediante la API de Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Estos son los resultados de consultar cuatro líneas de versiones el 2026-10-22 (horas en UTC).

Al comprobarlo aparecieron tres puntos en los que juzgar por los números puede inducir a error.

1. «Actualizado recientemente» no significa «corregido». La etiqueta fija 8.3.35 se reconstruyó durante el 2026-10-21, pero el PHP_VERSION de su interior seguía siendo 8.3.35. Fíjate en la versión del interior, no en la marca de tiempo de actualización.
2. Digests distintos pueden tener el mismo contenido. 8.3 y 8.3.36 tenían digests de etiqueta distintos (el valor del índice multiarquitectura), pero la imagen amd64 era idéntica y ambas tenían PHP_VERSION=8.3.36. Igualmente, en 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm y 8.2-fpm, el PHP_VERSION de la imagen amd64 era una versión corregida.
3. No hay imágenes oficiales corregidas para 8.1 y anteriores. 8.1-fpm se actualizó por última vez el 2025-12-31.

Para comprobar tus imágenes locales y los contenedores en ejecución:

# Versión de PHP de una imagen descargada localmente
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Volver a hacer pull y recrear los contenedores
docker compose pull
docker compose up -d

# Si construyes tu propia imagen, vuelve a descargar la base y luego compila
docker compose build --pull

# Versión dentro de un contenedor en ejecución
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Sustituye app en el último comando por el nombre de tu propio servicio. Cada imagen oficial se construye con un único PHP_VERSION, así que la versión de CLI dentro de un contenedor coincide con la versión de FPM / Apache de ese contenedor (la Trampa 1 se aplica cuando PHP está instalado directamente en el host).

FrankenPHP incorpora PHP, por lo que la versión de FrankenPHP y la versión de PHP incorporada son números distintos. Las notas de la versión de FrankenPHP 1.13.2, publicada el 2026-10-21, indican que las imágenes de Docker se compilaron con PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 y los binarios estáticos con PHP 8.5.12.

Trampa 3: los paquetes de las distribuciones están «corregidos con números antiguos»

Ubuntu y RHEL portan solo las correcciones a versiones antiguas (backporting). El número que muestra php -v sigue siendo antiguo, así que una comprobación numérica del tipo «inferior a 8.3.36, luego vulnerable» marcará como vulnerable un sistema ya corregido. Y a la inversa, tampoco puedes tranquilizarte por el número. Decide según la versión del paquete y el tracker de seguridad de cada distribución.

Paquetes corregidos que figuraban en cada tracker a fecha de 2026-10-22 (iguales para ambos CVE):

Esta tabla muestra directamente por qué los números no bastan. El PHP corregido de Ubuntu 24.04 es una versión que empieza por 8.3.6, muy inferior al 8.3.36 de upstream. El PHP predeterminado de RHEL 9 está corregido y sigue en 8.0.30, aunque upstream ya no publica correcciones para 8.0. Debian ha pasado a los mismos números que upstream (8.2.35 / 8.4.27).

Algunos paquetes aún no están corregidos (a fecha de 2026-10-22).

• El módulo php 8.4 de RHEL 9 figura como «afectado, sin corrección».
• Debian forky (testing) tiene php8.4 8.4.26-1, marcado como «vulnerable». El php8.4 de sid (unstable) es 8.4.27-1 y está corregido.

Comandos de ejemplo para comprobar tu propio servidor:

# Debian / Ubuntu: versión instalada y versión disponible
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: si este CVE está corregido en este servidor
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Familia RHEL: si existe una actualización que corrija este CVE, y la versión instalada
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Adapta el nombre del paquete (php8.3-fpm, etc.) a tu entorno. Compara la versión mostrada con la «versión corregida» de la tabla anterior o del tracker; si es igual o superior, la corrección está aplicada. Después completa el reinicio y la comprobación del lado web descritos en la Trampa 1.

Si instalas PHP desde un repositorio de terceros en lugar de los paquetes propios de la distribución, debes seguir las actualizaciones de ese repositorio. El aviso de PHP señala que rpms.remirepo.net, mantenido por voluntarios, no tendría actualizaciones el día de la divulgación, y recomienda cambiar a los paquetes de la distribución o a compilaciones propias.

Trampa 4: en hosting compartido y entornos gestionados no puedes actualizar PHP tú mismo

En hosting compartido y entornos PHP gestionados, es el proveedor quien sustituye el entorno de ejecución de PHP. Aquí tampoco basta el número: si el proveedor compila PHP por su cuenta o hace backport de las correcciones, el número de versión puede seguir siendo antiguo.

Hay tres cosas que puedes hacer tú mismo.

1. Comprobar la versión del lado web. Usa el archivo temporal de la Trampa 1 para mostrar PHP_VERSION y PHP_SAPI y bórralo enseguida. Si el panel de control tiene un selector de versión de PHP, anota también qué versión tienes seleccionada.
2. Leer el aviso del proveedor y preguntarle si no hay ninguno. Pregunta: «¿En qué versiones de PHP de mi plan se aplicarán las correcciones de CVE-2026-109618 y CVE-2026-109619, y cuándo (o ya se han aplicado)?». Preguntar por el número de CVE y no por el número de versión te dará una respuesta que también cubre los backports.
3. Si has seleccionado una versión sin soporte, actualiza. El proyecto PHP no publica correcciones para 8.1 y anteriores, y el soporte de 8.2 termina el 2026-12-31. Salvo que el proveedor haya hecho backport de las correcciones, cambiar de versión es el camino seguro.

Estado por proveedor de hosting (a fecha de 2026-10-22)

En el hosting compartido, lo normal es que el proveedor actualice el entorno de PHP, y los avisos de muchos proveedores indican que «no se requiere ninguna acción por parte de los usuarios». Los usuarios tienen dos cosas que hacer: consultar el aviso oficial de su proveedor y, si han seleccionado una versión antigua de PHP en el panel de control, decidir si cambian a la versión que recomienda el aviso (una con versión corregida publicada).

La tabla siguiente resume únicamente lo que consta en las páginas oficiales de cada proveedor (anuncios e información de mantenimiento), parafraseando la redacción de sus avisos. Los avisos se actualizan a medida que avanza el trabajo, así que confirma siempre el estado real en la página oficial citada.

Cuando no pude encontrar o abrir un aviso oficial, la tabla indica «no se pudo confirmar» o «no se encontró». La ausencia de información no significa que el proveedor no haya respondido. Consulta directamente los anuncios y el soporte de tu proveedor.

Mitigaciones mientras no puedas actualizar de inmediato

El aviso de PHP enumera ajustes que reducen la superficie de ataque hasta que puedas actualizar. Sin embargo, el propio aviso afirma expresamente que «no te hacen estar seguro». Los principales son:

• Para CVE-2026-109619: establece session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor, y reinicia todos los workers (ini_set() y el .user.ini de FPM no funcionan para esto). En PHP 8.5, establece también fatal_error_backtraces=0.
• Para CVE-2026-109618: establece memory_limit=-1 de forma que la aplicación no pueda sobrescribirlo y reduce post_max_size (8M si no hay subidas de archivos, 32M si las hay). No uses RLIMIT_AS / RLIMIT_DATA como sustituto.

El NCSC del Reino Unido recomienda considerar desconectar cualquier sistema que no se pueda actualizar ni mitigar de inmediato, y comprobar si hay indicios de compromiso antes de actualizar o aplicar mitigaciones.

Fuentes (consultadas el 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: anuncios de las versiones PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: imagen oficial de php
• Notas de la versión de FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (versiones de los paquetes corregidos a partir de los datos VEX de Red Hat)
• NCSC: Critical security issue affecting PHP