En resumen: Si php -v muestra la misma versión tras la actualización, casi siempre se debe a un backport: la distribución incorpora solo la corrección de seguridad a su versión existente de PHP y el número se mantiene. Ubuntu 24.04 sigue así informando de 8.3.6, aunque el paquete esté corregido frente a PHP2Shell. Aclare la cuestión mediante el nivel del paquete y el registro de cambios, y compruebe además si el sitio web funciona realmente con el código nuevo.
Un momento típico tras PHP2Shell
El administrador ha aplicado la actualización, todo sin errores. Para comprobarlo escribe php -v y ve la misma versión que antes. ¿No ha funcionado la actualización? ¿Sigue abierto el servidor? Esta pregunta es de las más frecuentes desde el 21 de octubre de 2026.
La buena noticia: en la mayoría de los casos todo está en orden. La mala: también hay casos en los que el mismo número indica realmente un problema. Este artículo ayuda a distinguir ambos.
Por qué las distribuciones no cambian el número
Las distribuciones empresariales y LTS prometen estabilidad. Dentro de una versión, el comportamiento y las interfaces no deberían cambiar en lo posible. Pero un salto de PHP 8.3.6 a 8.3.36 traería numerosas correcciones de errores y pequeños cambios de comportamiento que podrían perturbar las aplicaciones.
Por eso, muchos mantenedores de paquetes incorporan solo la corrección de seguridad concreta a su versión existente. Este proceso se llama backport. La versión upstream, que PHP mismo comunica mediante php -v, se mantiene igual. Lo que cambia es el nivel del paquete, que asigna la distribución.
En el ejemplo de Ubuntu 24.04 es así: PHP informa de 8.3.6. Pero el nivel de paquete corregido es, según USN-8948-1, 8.3.6-0ubuntu0.24.04.13. Cuenta la parte final. Debian decidió otra cosa en PHP2Shell y entregó para bookworm y trixie las nuevas versiones upstream 8.2.35 y 8.4.27. El resumen por versión figura en el artículo Debian y Ubuntu: ¿está parcheado mi paquete de PHP?.
Merece la pena descomponer una vez una versión de paquete así. En el ejemplo 8.3.6-0ubuntu0.24.04.13: la parte anterior al guion es la versión upstream, es decir, lo que PHP mismo comunica. Detrás sigue la revisión de la distribución. ubuntu0.24.04 remite a la versión, el último número cuenta las revisiones. Cada corrección de seguridad aumenta ese número. En Ubuntu Pro aparece además un añadido como +esm5 y en las actualizaciones de seguridad de Debian uno como ~deb12u1. Quien sabe leer estas partes reconoce de un vistazo si un paquete se modificó tras un aviso de seguridad.
Dónde aparece por todas partes el número antiguo
El número sin cambios no aparece solo en php -v. También figura en lugares visibles desde fuera o que evalúan las herramientas:
| Lugar | Qué figura allí | Consecuencia |
|---|---|---|
php -v y php -i |
versión upstream, fecha de compilación | los administradores dudan de la actualización |
| página phpinfo | versión upstream | el mismo efecto en el navegador |
cabecera X-Powered-By |
versión upstream, si expose_php está activado |
los escáneres externos notifican una vulnerabilidad |
| paneles de alojamiento como Plesk | versión upstream | se muestra, por ejemplo, 8.2.34 a pesar del parche |
| escáneres de vulnerabilidades | comparación por número | falsa alarma con backports |
Los escáneres externos son un caso aparte. Quien los usa puede recibir tras PHP2Shell hallazgos de servidores que hace tiempo están corregidos. No ignore esos hallazgos en bloque, sino acredite para cada servidor el nivel del paquete y anótelo como revisado. Otro motivo para ocultar hacia fuera las indicaciones de versión figura en el artículo expose_php y cabeceras del servidor.
Cuándo es el mismo número una señal de alarma
Hay tres situaciones en las que el número sin cambios indica realmente un problema:
- La fuente de paquetes entrega la versión upstream. Si PHP procede de una fuente que normalmente entrega la versión upstream actual, por ejemplo Debian en PHP2Shell o fuentes de terceros como Remi y sury.org, tras la actualización debería aparecer 8.5.12, 8.4.27, 8.3.36 u 8.2.35. Si sigue el número antiguo, el paquete no se actualizó.
- Está comprobando la instalación equivocada.
php -vmuestra la línea de comandos. Si el sitio web funciona con otra versión, por ejemplo de un panel de alojamiento o de una Software Collection, la salida no dice nada sobre el sitio web. - El nivel del paquete no ha cambiado. Si también el nivel del paquete es el mismo que antes de la actualización, la actualización no ha llegado a ese paquete, por ejemplo porque estaba retenido o falta la fuente.
Para quien no es técnico puede resumirse así: el número de versión describe el modelo, el nivel del paquete el estado de mantenimiento. Dos servidores con la misma versión de PHP pueden diferir mucho en seguridad. Por eso no pregunte a su TI o a su proveedor de servicios por la versión, sino por el justificante del parche.
Cómo aclararlo en cinco minutos
Los siguientes comandos son de solo lectura. Los ejemplos parten de Ubuntu o Debian y PHP 8.3; en sistemas RHEL use rpm -q en lugar de dpkg-query.
# 1. ¿Qué comunica PHP mismo, incluida la fecha de compilación?
php -v
# 2. ¿Qué nivel de paquete está instalado y de qué fuente?
apt policy php8.3-fpm
# 3. ¿Contiene el registro de cambios los números CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. ¿Desde cuándo funcionan los procesos de PHP del sitio web?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
La fecha de compilación en la salida de php -v es un indicio, pero no una prueba. El justificante fiable lo da la entrada del registro de cambios. Cómo encontrarla y conservarla cuando está formulada de otra manera o falta lo describe el artículo Acreditar números CVE en el registro de cambios del paquete.
Anote tras cada comprobación ambos números: la versión upstream de php -v y el nivel del paquete. Quien pregunte más adelante por qué el servidor «sigue en 8.3.6» recibirá así una respuesta clara.
La comprobación general mediante versión, paquete y procesos la resume la página Comprobar correctamente la versión de PHP y el nivel de parcheo.
¿Cómo ayuda PHP SOS en concreto?
- Aclaramos para cada servidor si un número de versión sin cambios es un backport o una actualización que falta.
- Valoramos los hallazgos de los escáneres de vulnerabilidades y acreditamos las falsas alarmas con el nivel del paquete y el registro de cambios.
- Comprobamos qué instalación de PHP usa realmente el sitio web y si se han reiniciado sus procesos.
- En el servicio de parcheo de PHP documentamos lado a lado la versión upstream y el nivel del paquete.
Preguntas frecuentes
¿Está mi servidor sin parchear si php -v muestra el número antiguo?
No necesariamente. Muchas distribuciones incorporan las correcciones como backport en la versión existente. Ubuntu 24.04, por ejemplo, sigue mostrando 8.3.6 aunque el paquete esté corregido según USN-8948-1. Lo decisivo son el nivel del paquete y el registro de cambios.
¿Por qué mi escáner de seguridad notifica una vulnerabilidad a pesar de la actualización?
Muchos escáneres solo leen el número de versión, por ejemplo de la cabecera X-Powered-By. Con los backports eso lleva a falsas alarmas. Compruebe el nivel del paquete y documente el resultado en lugar de ignorar el hallazgo sin más.
¿Puede ser que php -v muestre un número nuevo pero el sitio web no?
Sí. php -v muestra la línea de comandos. El sitio web puede funcionar mediante otra instalación o mediante procesos iniciados antes de la actualización. Por eso compruebe también el servicio FPM o Apache y su hora de inicio.
¿Ayuda la fecha de compilación en la salida de php -v?
Es un indicio, pero no una prueba. Una fecha de compilación posterior al 21 de octubre de 2026 encaja con un paquete corregido, pero no acredita que la corrección esté incluida. La entrada del registro de cambios es el mejor justificante.