En resumen: Para comprobar un CVE en el registro de cambios, busque en el historial de cambios del paquete de PHP instalado CVE-2026-109618 y CVE-2026-109619: en Debian y Ubuntu en /usr/share/doc/<paquete>/changelog.Debian.gz, en sistemas RPM con rpm -q --changelog. Una coincidencia, junto con el nivel del paquete, la comparación con el aviso de seguridad oficial y la hora del reinicio, constituye un justificante sólido. Que no haya coincidencia no prueba todavía que la vulnerabilidad siga abierta.
Por qué un justificante es más que «hemos parcheado»
Tras PHP2Shell, muchos quieren saber si sus servidores están seguros: la dirección, el delegado de protección de datos, los clientes con encargo de tratamiento y, a veces, la aseguradora de ciberriesgos. «Hemos parcheado» no basta para ello. Se pide una prueba que un tercero pueda verificar.
El número de versión a menudo no sirve, porque las distribuciones incorporan las correcciones como backport y el número no cambia. El registro de cambios del paquete es una base mejor. Lo escribe el responsable del paquete y, en las actualizaciones de seguridad, suele enumerar los números CVE corregidos.
Dónde están los registros de cambios
Cada formato de paquete tiene su propio lugar. La siguiente tabla ayuda a llegar rápido al sitio correcto.
| Sistema | Ubicación del registro de cambios | Comando para buscar |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paquete>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (en línea) | Archivo de paquetes de la distribución | apt changelog <paquete> |
| RHEL, AlmaLinux, Rocky, Fedora | Base de datos de paquetes RPM | rpm -q --changelog <paquete> |
| Imágenes de contenedor | En la imagen, como en el sistema base | Ejecutar el comando dentro del contenedor |
En Debian y Ubuntu, el directorio de documentación de algunos paquetes binarios apunta mediante un enlace simbólico a un paquete común, por ejemplo php8.3-common. Si zgrep no encuentra el archivo, examine el directorio con ls -l /usr/share/doc/ | grep php.
Comprobar el CVE en el changelog: cómo proceder
Los siguientes comandos son de solo lectura. Adapte los nombres de paquete a su instalación.
# Debian/Ubuntu: en local, sin red
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: cabecera de la entrada más reciente con nivel de paquete y fecha
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Familia RHEL: entrada con fecha y nivel de paquete
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
En Debian y Ubuntu, el nivel del paquete figura en la línea de cabecera de cada entrada y la fecha en la línea final. En RPM, ambos figuran en la línea situada encima de las entradas. Así no solo ve si se menciona el CVE, sino también con qué nivel de paquete. Compare ese nivel con el instalado, por ejemplo con dpkg-query -W o rpm -q. Si coinciden, la corrección está incluida en el paquete en uso.
Paquetes de panel y contenedores
Los paneles de alojamiento, como Plesk o cPanel, traen sus propios paquetes de PHP. También estos son paquetes DEB o RPM corrientes, y su registro de cambios se puede leer con las mismas herramientas. Si los proveedores mencionan en él números CVE o solo la nueva versión de PHP varía de unos a otros. Si el paquete indica la versión upstream 8.5.12, 8.4.27, 8.3.36 o 8.2.35, basta como justificante; en el caso de backports con número antiguo necesita la información del proveedor.
En los contenedores, el justificante pertenece a la imagen, no al host. Revise los paquetes de la imagen a partir de la cual se inició el contenedor en ejecución y anote además el digest de la imagen. Así se podrá reconstruir después qué nivel se ejecutaba realmente, aunque la imagen se haya vuelto a construir entretanto con la misma etiqueta.
Si el CVE falta en el registro de cambios
Una entrada ausente puede tener varias causas. Repáselas en este orden:
- Paquete equivocado: si hay varias ramas o fuentes de PHP en un servidor, la respuesta suele estar en el registro de cambios de otro paquete.
- Versión upstream en lugar de CVE: si la fuente entrega la nueva versión upstream, por ejemplo 8.4.27, en el registro de cambios puede figurar solo «New upstream version». Entonces el propio número de versión es la prueba, porque php.net indica como corregidas las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
- Otra formulación: algunos responsables mencionan números de error o identificadores de aviso como GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp en lugar del CVE.
- Comparación con el aviso de seguridad: si el aviso oficial de su distribución, por ejemplo un USN o el Debian Security Tracker, indica un nivel de paquete corregido y está instalado ese nivel o uno posterior, también es una prueba. Para Debian y Ubuntu encontrará los niveles en el artículo Debian y Ubuntu: ¿está parcheado mi paquete de PHP?, y para la familia RHEL en RHEL, AlmaLinux y Rocky Linux.
- Preguntar al proveedor: en paquetes de panel, compilaciones del hoster o fuentes de terceros solo sirve la respuesta por escrito. La guía Preguntar al hoster por el estado del parche ofrece una plantilla.
Si tras estos pasos sigue sin haber justificante, trate el servidor como no parcheado y aplique medidas provisionales hasta aclarar la cuestión.
De la coincidencia al justificante
Una coincidencia en el registro de cambios prueba que el paquete contiene la corrección. No prueba que los procesos en ejecución la utilicen. Un justificante completo contiene por ello cinco datos por servidor e instalación de PHP:
- servidor, rama de PHP y modo de funcionamiento, por ejemplo PHP-FPM o mod_php
- nivel del paquete instalado y origen del paquete
- referencia en el registro de cambios o enlace al aviso de seguridad oficial
- momento de la actualización y hora de inicio de los procesos de PHP en ejecución
- nombre de la persona que realizó la comprobación y fecha de esta
Guarde las salidas en bruto de los comandos como archivo de texto junto al justificante. Más adelante son más fáciles de verificar que un resumen hecho de memoria.
Un justificante solo responde a si la vulnerabilidad estaba cerrada a partir de un momento determinado. Para el tiempo anterior necesita los registros desde el 20 de octubre de 2026 y, en su caso, un rastreo de huellas. El procedimiento general de comprobación de versiones lo describe la página Comprobar correctamente la versión de PHP y el nivel de parcheo.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos los registros de cambios de todos los paquetes de PHP de sus servidores y los comparamos con los avisos de seguridad oficiales.
- Cuando los registros no dicen nada, aclaramos el nivel con la distribución, el proveedor del panel o el hoster.
- Comprobamos que los procesos en ejecución se hayan reiniciado tras la actualización.
- Con el servicio de parcheo de PHP recibe el justificante por servidor en una forma que puede entregar a terceros.
Preguntas frecuentes
¿Por qué no basta la versión de PHP como justificante?
Muchas distribuciones incorporan las correcciones de seguridad como backport sin cambiar la versión de PHP. El número de versión no dice entonces nada sobre el parche. El registro de cambios del paquete instalado, en cambio, menciona los números CVE corregidos.
¿Qué significa que el CVE no aparezca en el registro de cambios?
Puede significar que falta la corrección. Pero también puede ser que el responsable del paquete lo formule de otro modo, por ejemplo con un número de error o con la versión upstream. En ese caso compare el nivel del paquete con el aviso de seguridad oficial o pregunte al proveedor.
¿Cuánto tiempo debo conservar el justificante?
Mientras pueda ser relevante para auditorías internas, aseguradoras o posibles cuestiones de protección de datos. Archívelo junto con los registros desde el 20 de octubre de 2026. Los plazos concretos consúltelos con el delegado de protección de datos o con asesoría jurídica.
¿Puedo comprobar el registro de cambios también sin acceso a Internet?
Sí. Debian y Ubuntu guardan el registro de cambios de cada paquete en local, en /usr/share/doc, y los sistemas RPM lo almacenan en la base de datos de paquetes. Ambos se pueden leer sin red.