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

Si el PHP que atiende las solicitudes web (PHP-FPM, mod_php de Apache, php-cgi, FrankenPHP, LiteSpeed) es anterior a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, está afectado por 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 revisar 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 lugares donde juzgar solo por el número de versión lleva a una conclusión equivocada. Todas las cifras y la información de estado son al 2026-10-22, y las fuentes de cada punto se listan al final.

Lo que se sabe al 2026-10-22

El aviso de PHP afirma que «la única corrección completa es actualizar». Las mitigaciones para el período 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 escrito por SSH informa la versión del PHP de CLI. Las solicitudes web las atienden procesos de PHP-FPM o mod_php cargado en Apache, que son binarios y paquetes distintos. Si instalaste un PHP más nuevo solo para CLI, ejecutas varias versiones en paralelo o tienes un pool de FPM que apunta a otra versión, el lado web puede seguir con una versión antigua 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 su propia versión. Coloca un archivo temporal con un nombre difícil de adivinar y elimínalo apenas termines de revisar.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

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

El reinicio es otro paso fácil de olvidar. Aunque el paquete se haya reemplazado, los procesos de php-fpm o Apache que ya están en ejecución pueden seguir con el código antiguo. Algunas configuraciones se reinician automáticamente al actualizar paquetes; otras no. Después de actualizar, reinicia FPM / Apache y vuelve a verificar la versión del lado web con los métodos anteriores.

Trampa 2: Con Docker, no se puede juzgar por el nombre del tag

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

• Aunque un tag móvil pase a una versión corregida en Docker Hub, tu copia local sigue siendo la imagen antigua hasta que hagas pull de nuevo. 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.
• Un tag fijo sigue siendo antiguo para siempre hasta que subas el número tú mismo.

Puedes comprobar si ya se publicaron tags de 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).

Esta revisión mostró tres puntos en los que juzgar por los números puede inducir a error.

1. «Actualizado recientemente» no significa «corregido». El tag fijo 8.3.35 se reconstruyó durante el 2026-10-21, pero el PHP_VERSION en su interior seguía siendo 8.3.35. Mira la versión interna, no la fecha de actualización.
2. Digests distintos pueden tener el mismo contenido. 8.3 y 8.3.36 tenían digests de tag 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 revisar tus imágenes locales y 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 compilas 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;'

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

FrankenPHP incorpora PHP, así 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 se «corrigen con números antiguos»

Ubuntu y RHEL portan solo las correcciones a versiones anteriores (backporting). El número que muestra php -v sigue siendo antiguo, por lo que una verificación numérica como «menor que 8.3.36, por lo tanto vulnerable» marcará como vulnerable un sistema que ya está corregido. A la inversa, tampoco puedes confiar en el número para quedarte tranquilo. Decide con base en la versión del paquete y en el security tracker de cada distribución.

Paquetes corregidos que figuran en cada tracker al 2026-10-22 (iguales para ambos CVE):

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

Algunos paquetes aún no están corregidos (al 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.

Ejemplos de comandos para revisar 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 cuál es la versión instalada
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Ajusta 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. Luego completa el reinicio y la verificación del lado web descritos en la Trampa 1.

Si instalas PHP desde un repositorio de terceros y no desde 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 administrados, no puedes actualizar PHP tú mismo

En hosting compartido y en entornos de PHP administrados, el proveedor reemplaza el runtime de PHP. Aquí tampoco basta el número: si el proveedor compila PHP por su cuenta o hace backports de correcciones, el número de versión puede seguir siendo antiguo.

Hay tres cosas que puedes hacer tú mismo.

1. Verifica la versión del lado web. Usa el archivo temporal de la Trampa 1 para imprimir PHP_VERSION y PHP_SAPI, y elimínalo de inmediato. Si el panel de control tiene un selector de versión de PHP, anota también qué versión tienes seleccionada.
2. Lee el aviso del proveedor y, si no hay ninguno, pregunta. Pregunta: «¿Para 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 aplicaron)?». Preguntar por el número de CVE y no por el número de versión permite obtener una respuesta que también cubra los backports.
3. Si seleccionaste 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. A menos que el proveedor haya hecho backports de las correcciones, cambiar de versión es el camino seguro.

Estado por proveedor de hosting (al 2026-10-22)

En hosting compartido, normalmente el proveedor actualiza el runtime de PHP, y los avisos de muchos proveedores indican que «no se requiere ninguna acción de los usuarios». Los usuarios tienen dos cosas que hacer: revisar el aviso oficial de su proveedor y, si seleccionaron una versión antigua de PHP en el panel de control, decidir si cambian a la versión que recomienda el aviso (una que tenga una versión corregida).

La tabla siguiente resume únicamente lo que está escrito en las páginas oficiales de cada proveedor (anuncios e información de mantenimiento), parafraseando el texto 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 dice «no se pudo confirmar» o «no se encontró». La ausencia de información allí no significa que el proveedor no haya respondido. Consulta directamente los anuncios y el soporte de tu proveedor.

Mitigaciones mientras no puedes actualizar de inmediato

El aviso de PHP enumera ajustes que reducen la superficie de ataque hasta que puedas actualizar. Sin embargo, el propio aviso declara explícitamente 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 cargas de archivos, 32M si las hay). No uses RLIMIT_AS / RLIMIT_DATA como sustituto.

El NCSC del Reino Unido recomienda considerar poner fuera de línea cualquier sistema que no se pueda actualizar o mitigar de inmediato, y buscar 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 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 tomadas de los datos VEX de Red Hat)
• NCSC: Critical security issue affecting PHP