por Actualizar PHP parece una tarea sencilla hasta que ejecutamos php -v, vemos una versión reciente y descubrimos que la web sigue utilizando otra. En un mismo servidor pueden convivir el PHP de la terminal, varios servicios PHP-FPM y un contenedor con su propia instalación. Actualizar uno no actualiza automáticamente los demás.
Vamos a ver cómo identificar el que atiende nuestra web, comprobar de dónde viene el paquete y actualizarlo sin cambiar de rama a ciegas. Esto sirve tanto para una aplicación propia como para WordPress, aunque los pasos de mantenimiento dependen de cómo esté alojada.
Por qué conviene revisarlo ahora
El aviso oficial de PHP del 21 de octubre de 2026 describe dos vulnerabilidades críticas de ejecución remota de código, CVE-2026-109618 y CVE-2026-109619. Afectan a instalaciones que sirven peticiones web, incluidas FPM, Apache y otros servidores. Las correcciones upstream se publicaron en 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Un paquete de Ubuntu puede conservar un número base anterior y llevar el parche retroportado. Por eso necesitamos la versión completa del paquete y el aviso de su proveedor, no sólo comparar los primeros números con esa lista.
Hay además una nota oficial del 23 de octubre sobre una combinación poco habitual de configuración de sesiones. Conviene leerla también. La actualización y las medidas provisionales tienen alcances distintos, y una mitigación parcial no convierte una instalación vulnerable en segura. Mantengamos como referencia el aviso vigente del proyecto y el de nuestra distribución.
Comprobar el PHP de la terminal
Empezamos recogiendo información. Estos comandos no actualizan paquetes:
command -v php
php -v
php --ini
El primero muestra qué ejecutable encuentra nuestra sesión. El segundo indica la versión de ese ejecutable. El tercero permite ver su configuración. Si trabajamos con varias versiones, una herramienta puede usar /usr/bin/php8.3 mientras php apunta a otra.
También podemos consultar la interfaz de ejecución, llamada SAPI:
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
En la terminal aparecerá cli. Eso confirma precisamente que estamos mirando la terminal. No demuestra qué ejecuta Nginx, Apache, el proceso de una cola o una tarea programada. La documentación de PHP sobre las SAPI explica esta diferencia.
Averiguar cuál utiliza la web
Si utilizamos WordPress, en Herramientas → Salud del sitio → Información → Servidor podemos consultar la versión que ve la aplicación. En un hosting administrado también suele aparecer en la configuración del dominio. No basta con mirar la versión predeterminada del panel si ese dominio tiene una selección propia.
En una aplicación nuestra, podemos obtener estos tres datos desde una ruta de diagnóstico protegida:
<?php
header('Content-Type: application/json; charset=utf-8');
echo json_encode([
'version' => PHP_VERSION,
'sapi' => PHP_SAPI,
'ini' => php_ini_loaded_file() ?: null,
], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
Este fragmento está pensado para un entorno de pruebas o una ruta accesible sólo para administradores. No lo dejamos como archivo público en la raíz de la web. Tampoco necesitamos publicar un phpinfo() completo, que muestra mucha más información de la necesaria.
Así podemos distinguir fpm-fcgi, apache2handler o cgi-fcgi de cli. La ruta del archivo de configuración también ayuda a detectar que estábamos editando el php.ini equivocado. PHP documenta por separado cómo selecciona su configuración y cómo consultar el archivo cargado.
Si administramos Nginx, revisamos el fastcgi_pass del bloque correspondiente al dominio. Puede apuntar, por ejemplo, a /run/php/php8.3-fpm.sock, a otro servicio o a una dirección de contenedor. En Apache comprobamos si ese sitio utiliza un módulo PHP o una configuración que envía las peticiones a FPM. No cambiamos el destino únicamente porque exista otro socket más reciente.
Ver la versión completa y el origen del paquete
En Ubuntu, Debian y derivados podemos listar los paquetes instalados:
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*'
Después consultamos los que realmente intervienen en esa web. Para un servidor con PHP 8.3-FPM, por ejemplo:
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
Aquí importan la versión instalada, la candidata y el repositorio que la suministra. La información procede de las listas locales de APT, así que puede estar atrasada si todavía no hemos actualizado esas listas.
Contrastamos la versión completa con el aviso de seguridad de Ubuntu, Debian o el proveedor del repositorio. Un PPA no hereda automáticamente los parches de Ubuntu. Si la rama está fuera de soporte, necesitamos una confirmación del proveedor que la mantiene o preparar una migración a una rama con soporte.
En un alojamiento sin acceso al sistema de paquetes, ésta es una pregunta concreta para soporte: qué runtime sirve el dominio, qué compilación está activa y dónde confirman que incorpora las correcciones. «El servidor está actualizado» no aclara esos tres puntos.
Actualizar dentro de la misma rama
Antes del mantenimiento hacemos una copia comprobada de la aplicación, su configuración y la base de datos. Revisamos también extensiones necesarias y compatibilidad en un entorno de pruebas. Un parche de seguridad dentro de una rama y pasar de PHP 8.2 a 8.5 son operaciones distintas.
Con la rama y los paquetes identificados, actualizamos las listas y simulamos la operación. Este ejemplo corresponde exclusivamente a un equipo que ya tiene instalados esos paquetes de PHP 8.3:
sudo apt update
sudo apt-get -s install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
Leemos lo que propone APT antes de continuar. Añadimos a la operación las extensiones instaladas que tengan una actualización pendiente, como el controlador de la base de datos. Si anuncia eliminaciones inesperadas o cambiar de rama, resolvemos primero el motivo.
Cuando la simulación corresponda con lo previsto, repetimos sin -s:
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
Si la versión candidata no contiene el parche que necesitamos, repetir el comando no lo consigue. Hay que revisar repositorios y soporte. Tampoco lo solucionamos purgando todas las versiones o añadiendo un repositorio al azar.
Comprobar que los procesos nuevos están en uso
Instalar archivos nuevos no garantiza que todos los procesos que atendían la web hayan sido sustituidos. El mantenimiento puede reiniciar servicios y producir una interrupción, así que lo hacemos en una ventana prevista.
Para el ejemplo de FPM comprobamos primero la configuración y, si es válida, reiniciamos el servicio concreto:
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm
Si falla la primera orden, no continuamos con el reinicio. Revisamos el error y la configuración de FPM. Con Apache y mod_php, el proceso que hay que renovar es Apache, tras comprobar su configuración. No copiamos el reinicio de FPM si nuestra web no usa FPM.
Volvemos a consultar la versión desde la propia aplicación y probamos una página dinámica, el acceso y una operación que utilice la base de datos. Una portada servida desde caché puede funcionar aunque PHP esté fallando. Revisamos además los registros del servicio y de la aplicación por si aparecen errores nuevos.
Las colas y otros procesos PHP de larga duración tienen su propio ciclo de reinicio. Los identificamos en el despliegue y los renovamos de forma controlada. No damos el mantenimiento por terminado porque php -v haya cambiado.
Si PHP está dentro de Docker
En ese caso, actualizar PHP en el anfitrión no cambia el de la imagen. Podemos consultar el CLI del servicio, sustituyendo web por su nombre real:
docker compose exec web php -v
docker compose images
La primera orden sigue consultando CLI. Comprobamos también qué ve la aplicación web dentro de ese servicio. Para actualizar necesitamos una imagen corregida o reconstruir la nuestra desde una base mantenida, probarla y recrear el servicio con el procedimiento habitual del proyecto.
Modificar paquetes a mano dentro de un contenedor que luego se destruirá deja una instalación difícil de reproducir. La corrección debe quedar en la imagen y en la configuración de despliegue, con una copia recuperable de los datos persistentes.
Al terminar deberíamos poder relacionar el dominio, el proceso que lo atiende y el paquete o imagen que lleva la corrección. Esa comprobación evita muchos falsos «ya está actualizado». Para trabajar después con el código, tenemos también la selección de editores e IDE para PHP en Linux.
