Quisiera aportar algo a este debate, porque creo que hay una diferencia técnica importante que no se ha aclarado suficientemente.
La respuesta de
@banahosting.com de que
«cPanel ya fue actualizado» no necesariamente demuestra que las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 estén corregidas en las versiones PHP que utilizan los sitios web alojados.
En nuestras verificaciones con
Banahosting, encontramos servidores con CloudLinux, LiteSpeed y EasyApache donde PHP continúa mostrando versiones como 8.2.34, 8.3.35, 8.4.26 y 8.5.11, todas anteriores a las versiones corregidas oficialmente por PHP.
Investigando encontramos que
CloudLinux publicó sus propias correcciones mediante backporting, incorporando los parches de seguridad sin cambiar el número de versión que reporta el intérprete.
Por ejemplo, PHP 8.4.26 puede estar corregido mediante el paquete ea-php84-php-common-8.4.26-2.el8.cloudlinux.1.
Esto nos lleva a dos reflexiones:
1. ¿Quién realizó realmente la corrección?
En servidores que utilizan CloudLinux con EA-PHP, la corrección de las versiones PHP utilizadas por los sitios corresponde a los paquetes de CloudLinux. La actualización de cpanel-php84 es distinta y no constituye, por sí sola, evidencia de que el PHP de los dominios esté corregido.
2. ¿Cómo podemos auditar estas actualizaciones?
Aunque el backporting es una práctica válida y utilizada por distribuciones empresariales, genera una dificultad importante para quienes administramos sitios en hosting compartido con
Banahosting.
Si PHP continúa identificándose como 8.4.26, ¿cómo podemos demostrar que realmente contiene los parches, especialmente cuando no tenemos acceso root ni podemos consultar los paquetes RPM instalados?
Considero que
los proveedores deberían acompañar estas actualizaciones con información verificable sobre las revisiones exactas de los paquetes y los CVE corregidos, en lugar de limitarse a indicar que cPanel está actualizado. (opinión personal)
No cuestiono la validez técnica del backporting. Mi inquietud está en la trazabilidad, la transparencia y la posibilidad de realizar auditorías independientes y verificables para nuestros clientes.
Al final, quienes administramos infraestructura y sitios de clientes necesitamos algo más que una versión visible de PHP o una confirmación genérica: necesitamos evidencia de que las vulnerabilidades fueron corregidas en el entorno que realmente ejecuta nuestras aplicaciones.
¿De que manera se puede confirmar qué revisiones de EA-PHP y Alt-PHP están instaladas y si incluyen las correcciones para ambos CVE?
Sería una información muy valiosa para todos los que administramos sitios web en los servidores de
Banahosting.
Fuente oficial de CloudLinux:
https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5
Actualización:
Para complementar lo anterior, CloudLinux publicó el
22 de octubre de 2026, a las 14:31 UTC, (estaba redactando este post) una actualización titulada
"Why fixed alt-php and ea-php packages show an older PHP version", donde explica expresamente que las correcciones de las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 fueron incorporadas mediante
backporting, manteniendo el número anterior de PHP.
Por ejemplo:
- PHP oficial corregido: 8.4.27
- PHP mostrado por CloudLinux: 8.4.26
- Paquete EA-PHP corregido: 8.4.26-2.el8.cloudlinux.1
Esto confirma que una versión aparentemente vulnerable puede contener los parches, siempre que corresponda a la revisión corregida del paquete.
CloudLinux también recomienda verificar los CVE directamente en el historial del paquete instalado:
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
Por tanto, el punto que considero importante aclarar no es si el
backporting es válido, sino
cómo podemos verificar desde un hosting compartido que realmente está instalada la compilación corregida, especialmente cuando no tenemos acceso a RPM ni privilegios administrativos.
