En resumen: una actualización de PHP en cPanel tras PHP2Shell consta de tres pasos: llevar todos los paquetes ea-php y, en su caso, alt-php a un estado corregido, reiniciar por completo PHP-FPM y Apache, y documentar el estado de los paquetes. Los clientes del servidor no pueden fijar por sí mismos los valores provisionales más importantes; eso lo tiene que hacer el administrador de WHM.
Situación de partida en los servidores cPanel
PHP2Shell comprende las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 en el propio PHP. Ambas permiten ejecutar código malicioso sin autenticación y tienen una puntuación CVSS v4.0 de 9,2. Afectan a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El proyecto PHP publicó el 21/10/2026 las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
cPanel no incluye PHP como un único paquete, sino mediante EasyApache 4, con un conjunto de paquetes por versión, por ejemplo ea-php83 o ea-php84. A ello se suman, en algunos servidores, los paquetes del sistema operativo y, en CloudLinux, las versiones alt-php. Cada fuente tiene su propio estado. Solo obtiene una imagen completa si comprueba las tres.
Actualizar PHP en cPanel: comprobar inventario y asignación
Empiece con un inventario. Los comandos siguientes solo leen y no modifican nada. Las rutas y los nombres de paquetes son ejemplos y pueden variar según la instalación.
# Versiones de PHP instaladas según la API de WHM
whmapi1 php_get_installed_versions
# Versión de cada instalación ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Estado de los paquetes (sistemas basados en RPM, ejemplo)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
En el MultiPHP Manager ve qué dominio usa qué versión y si PHP-FPM está activado. Anote las versiones que estén instaladas pero no asignadas a ningún dominio. También hay que actualizarlas o eliminarlas.
Valorar bien los backports
Como con otros proveedores, el número de versión mostrado no es el único criterio. Si una corrección se entrega como backport, el número puede seguir igual. Por eso compruebe además el registro de cambios del paquete y los avisos del proveedor.
# Buscar números CVE en el registro de cambios de un paquete (ejemplo)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
Que no aparezca ninguna entrada no significa automáticamente que falte la corrección. Sí significa que necesita una confirmación escrita antes de dar el servidor por parcheado. Cómo leer correctamente las versiones se explica en Comprobar la versión de PHP y el estado del parche.
Actualización, reinicio y control
La actualización se instala en WHM mediante la actualización del sistema o con el gestor de paquetes. Después se reinician todos los procesos PHP. Los archivos nuevos no bastan mientras sigan en memoria procesos antiguos.
# Reiniciar los servicios PHP-FPM de todas las versiones (script de cPanel)
/scripts/restartsrv_apache_php_fpm
# Reiniciar Apache por completo
/scripts/restartsrv_httpd
# Controlar la hora de inicio de los procesos PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Todo proceso PHP debería tener una hora de inicio posterior a la actualización. Si no es así, finalícelo de forma selectiva a través del servicio correspondiente. Si tiene varios servidores, conviene un breve registro por máquina que pueda usar más adelante como prueba.
Una actualización del CMS con herramientas de cPanel como WP Toolkit no cierra la vulnerabilidad de PHP. Es recomendable, pero no sustituye ni la actualización de PHP ni el reinicio.
Fijar los valores provisionales de forma centralizada
Si una versión aún no está corregida, php.net recomienda medidas provisionales que no ofrecen una protección completa. En cPanel se fijan en el MultiPHP INI Editor, en el modo para administradores, o directamente en el php.ini de la versión ea-php correspondiente. Los valores en .user.ini de las cuentas de clientes no bastan para session.upload_progress.enabled.
; php.ini de todo el servidor para la versión afectada (ejemplo)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Sin función de carga de archivos, php.net indica post_max_size = 8M. En PHP 8.5 se añade fatal_error_backtraces=0. Después reinicie de nuevo todos los procesos de trabajo. El límite de memoria se fija mediante cgroups, por ejemplo con los límites de CloudLinux, y no mediante RLIMIT_AS ni RLIMIT_DATA. Más detalles en Medidas inmediatas sin parche.
Responsabilidad entre el operador del servidor y los titulares de las cuentas
En un servidor cPanel con muchas cuentas, el administrador de WHM es responsable de PHP, de los servicios y de la configuración de todo el servidor. Los titulares de cada cuenta son responsables de sus aplicaciones, plugins y credenciales. Informe a los titulares de las cuentas de cuándo y cómo se ha parcheado, y recomiéndeles que revisen sus aplicaciones en busca de anomalías. Cómo se ve la situación desde el punto de vista del cliente se describe en Hosting compartido.
Conserve los registros desde el 20/10/2026. Un parche no elimina el software malicioso que se haya introducido antes.
Para la prueba basta con un registro sencillo por servidor: fecha y hora de la actualización, lista de los paquetes ea-php y alt-php con la versión anterior y la posterior, la lista de procesos con las horas de inicio tras el reinicio y, en su caso, la confirmación del proveedor de paquetes sobre los backports. Guarde el registro fuera del servidor. Servirá más adelante como justificante ante clientes, aseguradoras o auditores y facilitará la próxima actualización de emergencia, porque los pasos ya estarán descritos. Si opera varios servidores cPanel, merece la pena reunir los comandos de lectura de esta página en un pequeño script que se ejecute igual en todas las máquinas y recoja los resultados. Así detecta de un vistazo las diferencias entre servidores, por ejemplo una versión de PHP olvidada.
¿Cómo ayuda PHP SOS en concreto?
- Hacemos el inventario de los paquetes ea-php, alt-php y del sistema, y asignamos cada cuenta a su versión de PHP.
- A través de nuestro servicio de parcheo de PHP actualizamos, reiniciamos todos los servicios y documentamos el estado con listas de paquetes y horas de los procesos.
- Cuando es necesario, fijamos los valores provisionales para todo el servidor y sin posibilidad de sobrescribirlos.
- Revisamos las cuentas en busca de rastros típicos de un compromiso y, si hay hallazgos, iniciamos la eliminación de malware.
- Después reducimos el número de versiones de PHP y reforzamos la configuración.
Preguntas frecuentes
¿Dónde veo en WHM qué dominio usa qué versión de PHP?
En el MultiPHP Manager de WHM ve, para cada dominio, la versión asignada y si PHP-FPM está activo. Para obtener una lista completa conviene consultar además por línea de comandos. Anote también las versiones que no están asignadas a ningún dominio.
¿Puede un cliente de cPanel fijar por su cuenta los valores provisionales en .user.ini?
Para session.upload_progress.enabled, php.net indica expresamente que .user.ini e ini_set() no bastan. El valor debe ir en el php.ini, en el pool de FPM o en la configuración del servidor, y eso solo puede hacerlo el administrador del servidor.
¿Basta con un reinicio graceful de Apache?
Con PHP-FPM hay que reiniciar los propios servicios FPM; una recarga de Apache no los renueva. Con manejadores de PHP basados en Apache, lo más seguro es un reinicio completo. Después compruebe la hora de inicio de todos los procesos PHP.
¿Qué pasa con CloudLinux y alt-php?
En los servidores CloudLinux, algunos sitios web funcionan con paquetes alt-php propios en lugar de ea-php. Estos tienen su propio estado de paquetes y hay que comprobarlos y actualizarlos por separado.