Debian y Ubuntu: ¿está parcheado mi paquete de PHP?

En resumen: Si su paquete de PHP en Debian o Ubuntu está parcheado frente a PHP2Shell, lo reconoce por el nivel exacto del paquete, no por la versión de PHP. Ubuntu publicó el 21 de octubre de 2026 paquetes corregidos para todas las versiones compatibles, y para las más antiguas mediante Ubuntu Pro. Debian ha corregido php8.2 en bookworm y php8.4 en trixie. Compare el nivel instalado con dpkg --compare-versions y reinicie después todos los servicios de PHP.

La pregunta detrás de la pregunta

«¿Está parcheado mi paquete de PHP?» suena a pregunta de sí o no. En la práctica, la respuesta depende de tres cosas: ¿de qué fuente procede el paquete, qué nivel está instalado y ese nivel está también en ejecución? Este artículo responde a los dos primeros puntos para los paquetes oficiales de Debian y Ubuntu. Cómo comprobar en general la versión y los procesos en ejecución figura en Comprobar correctamente la versión de PHP y el nivel de parcheo.

Hemos consultado los datos en los avisos de seguridad oficiales de Ubuntu y en el Debian Security Tracker el 25 de octubre de 2026. Ambos CVE, CVE-2026-109618 y CVE-2026-109619, figuran allí con los mismos niveles corregidos.

Niveles de paquete corregidos en Ubuntu

Ubuntu ha publicado las correcciones en dos avisos. USN-8948-1 cubre las versiones actuales y USN-8948-2 las más antiguas, que solo reciben actualizaciones de seguridad mediante Ubuntu Pro. Para 16.04 y 14.04, Ubuntu menciona además la oferta de Legacy Support.

Llama la atención que todos los niveles conservan la versión original de PHP. Ubuntu 24.04 se queda en 8.3.6, aunque la corrección se tomó de 8.3.36. Por qué es así y cómo manejarlo lo explica el artículo Por qué php -v muestra el mismo número. Están afectados, entre otros, los paquetes binarios para FPM, CLI, CGI y el módulo de Apache, por ejemplo php8.3-fpm y libapache2-mod-php8.3.

Niveles de paquete corregidos en Debian

Debian sigue aquí otro camino y entrega las nuevas versiones upstream. Según el Security Tracker, el estado es este:

El aviso de bookworm apareció como DLA, es decir, mediante Debian LTS. Para php8.2 en unstable, el tracker aún no indica, en el momento de la consulta, un nivel corregido. Quien opere sistemas de prueba en unstable debería tenerlo presente.

Las versiones más antiguas de Debian no aparecen en las dos entradas CVE en el momento de la consulta. Si un servidor aún funciona en una versión así, por ejemplo Debian 11 con PHP 7.4, no puede fiarse de una actualización de seguridad del archivo oficial. Entonces quedan tres caminos: subir el sistema operativo a una versión compatible, usar una oferta comercial de soporte a largo plazo cuya cobertura de PHP2Shell le confirmen por escrito, o proteger el servidor con medidas provisionales y restringir su accesibilidad hasta la migración. A la larga, solo el primer camino es sostenible.

Cómo comparar con exactitud el nivel instalado

Un vistazo al número de versión no basta, porque las versiones de Debian se ordenan con sus propias reglas. dpkg --compare-versions compara correctamente. Los siguientes comandos son de solo lectura; adapte los nombres de paquete y el nivel de destino a su versión.

# Nivel instalado y origen del paquete
apt policy php8.3-fpm

# Todos los paquetes de PHP instalados con su versión
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null

# Comparación exacta con el nivel corregido (ejemplo Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"

Fíjese en la salida de apt policy en la línea con el origen del paquete. Si no figura allí el archivo de seguridad de su distribución, sino, por ejemplo, packages.sury.org o un PPA, las tablas anteriores no valen. Entonces cuenta el nivel de esa fuente de terceros, que tratamos en el artículo El repositorio sury.org.

Además merece la pena mirar el registro de cambios incluido. Cómo encontrar allí los números CVE y conservarlos como justificante lo describe el artículo Acreditar números CVE en el registro de cambios del paquete.

Trampas típicas en la comprobación

Revisado un solo paquete: PHP consta de muchos paquetes binarios. Si php8.3-cli está actualizado pero php8.3-fpm no, el sitio web sigue abierto. Revise todos los paquetes de una rama, en especial FPM, CGI y el módulo de Apache.

Paquete retenido: los paquetes fijados con apt-mark hold se quedan sin actualizar. apt-mark showhold los muestra.

Ubuntu Pro no activo: en 20.04 y anteriores, las correcciones solo llegan si Ubuntu Pro está configurado. Sin Pro, el sistema sigue siendo vulnerable a pesar de ejecutar las actualizaciones.

Espejo desactualizado: si el servidor obtiene los paquetes mediante un espejo o proxy interno, no ve las nuevas actualizaciones de seguridad hasta que este se actualice. En caso de duda, compruebe si apt update alcanza realmente la fuente de seguridad.

Reinicio olvidado: los paquetes nuevos solo surten efecto tras el reinicio de todos los servicios que han cargado PHP. needrestart, si está instalado, muestra los servicios con código obsoleto.

¿Cómo ayuda PHP SOS en concreto?

• Averiguamos para cada servidor el origen de todos los paquetes de PHP y comparamos el nivel con los avisos oficiales.
• Aplicamos las actualizaciones, también mediante Ubuntu Pro, y reiniciamos todos los servicios afectados.
• Con el servicio de parcheo de PHP usted recibe por cada servidor un justificante con el nivel del paquete, la coincidencia en el registro de cambios y la hora del reinicio.
• En sistemas con fuentes de terceros o versiones antiguas, aclaramos qué camino lleva a un nivel corregido acreditable.

Preguntas frecuentes

Fuentes

• Ubuntu Security Notice USN-8948-1
• Ubuntu Security Notice USN-8948-2
• Debian Security Tracker: CVE-2026-109618
• Debian Security Tracker: CVE-2026-109619