En resumen: una actualización de PHP en LiteSpeed afecta a los paquetes lsphp con los que LiteSpeed ejecuta PHP mediante LSAPI. Tras la actualización deben reiniciarse todos los procesos lsphp, y en LiteSpeed eso no siempre ocurre automáticamente con el servidor web. Compruebe el estado de los paquetes y la hora de inicio de los procesos antes de dar el servidor por parcheado.
LiteSpeed, LSAPI y lsphp en pocas palabras
LiteSpeed Web Server y su variante gratuita OpenLiteSpeed no ejecutan PHP como módulo, sino mediante una interfaz propia llamada LSAPI. Los programas PHP para ello se llaman lsphp y suelen proceder de repositorios de paquetes propios, por ejemplo lsphp83 o lsphp84 según la versión. En paneles como cPanel, Plesk o CyberPanel pueden intervenir además paquetes de PHP propios del panel.
PHP2Shell comprende las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 en el propio PHP, cada una con un CVSS v4.0 de 9,2. El proyecto PHP cita expresamente a LiteSpeed entre los modos de funcionamiento afectados. Están corregidas las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Actualizar PHP en LiteSpeed: hacer el inventario
Averigüe primero qué versiones de lsphp están instaladas y cuáles están en uso. Los comandos siguientes solo leen. Las rutas y los nombres de paquetes son ejemplos y dependen de la instalación y de la distribución.
# Versiones de lsphp instaladas (ruta habitual)
ls -d /usr/local/lsws/lsphp*/ 2>/dev/null
for p in /usr/local/lsws/lsphp*/bin/lsphp; do echo "$p"; "$p" -v | head -1; done
# Estado de los paquetes (ejemplos)
rpm -qa | grep -E '^lsphp[0-9]+' | sort
dpkg -l | grep -E 'lsphp[0-9]+'
# Procesos lsphp en ejecución con su hora de inicio
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Contraste la lista con la configuración: ¿qué host virtual usa qué External App Handler? En la interfaz de LiteSpeed lo encuentra en Server Configuration y en los ajustes de los hosts virtuales. Aun así, debería actualizar o eliminar las versiones sin asignación.
Tener en cuenta los backports y los repositorios de paquetes
Si lsphp procede de una fuente externa, decide el estado de paquetes de esta. Si PHP lo entrega un panel o una distribución, vale lo que estos indiquen. En ambos casos una corrección puede entregarse como backport sin que cambie el número de versión mostrado. Por eso compruebe las notas de cambios del proveedor del paquete y, en caso de duda, pida que le confirmen el estado. El número de versión por sí solo no es una prueba.
Reinicio: lo que importa en LiteSpeed
LiteSpeed puede ejecutar PHP en el llamado Detached Mode. En él, los procesos lsphp siguen funcionando independientemente del servidor web, para que los sitios web respondan más rápido tras un reinicio del servidor web. Para una actualización de seguridad es una trampa: el servidor web se ha reiniciado, pero los procesos PHP antiguos con el código vulnerable siguen activos.
# Reiniciar el servidor web (ruta a modo de ejemplo)
/usr/local/lsws/bin/lswsctrl restart
# Después, controlar: ¿son todos los procesos lsphp más recientes que la actualización?
ps -eo pid,lstart,user,cmd | grep lsphp | grep -v grep
Si un proceso lsphp muestra una hora de inicio anterior a la actualización, finalícelo de forma selectiva. LiteSpeed iniciará en la siguiente solicitud un proceso nuevo con el código actualizado. Planifique este paso fuera de las horas de mayor carga, porque después la primera solicitud de cada sitio web puede tardar algo más.
Tras la actualización de PHP, un servidor solo está parcheado cuando ningún proceso lsphp es más antiguo que la actualización. Deje constancia del control con fecha y hora.
Medidas provisionales hasta que llegue el parche
Si para una versión de lsphp todavía no hay un paquete corregido, php.net recomienda medidas provisionales. No ofrecen una protección completa. Fije los valores en el php.ini de la versión de lsphp correspondiente o en la configuración del servidor, no en .user.ini ni mediante ini_set().
; php.ini de la versión de lsphp afectada (ruta según la instalación)
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con función de carga de archivos, php.net indica post_max_size = 32M, con upload_max_filesize por debajo. En PHP 8.5 se añade fatal_error_backtraces=0. Los límites de memoria se fijan mediante cgroups, en CloudLinux por ejemplo con los límites previstos allí, y no mediante RLIMIT_AS ni RLIMIT_DATA. Después vuelve a tocar reiniciar todos los procesos lsphp. Más detalles: Medidas inmediatas sin parche. El BSI recomienda desconectar temporalmente de la red un servidor web si la actualización no es posible de inmediato.
Después de la actualización
Un parche cierra la vulnerabilidad, pero no elimina el software malicioso ya introducido ni demuestra que antes no pasara nada. Conserve los registros de acceso desde el 20/10/2026 y revise los sitios web en busca de archivos PHP nuevos en los directorios de cargas, cuentas de administrador ajenas y conexiones salientes inusuales. Encontrará indicaciones para la supervisión continua en nuestra monitorización de seguridad. En servidores cPanel con LiteSpeed merece la pena además mirar cPanel y WHM.
Muchos servidores LiteSpeed funcionan bajo un panel de hosting como cPanel, Plesk, DirectAdmin o CyberPanel. Entonces el panel determina de qué fuente procede lsphp y cómo se instalan las actualizaciones. En ese caso, haga las actualizaciones a través del panel o de sus repositorios de paquetes y no instale en paralelo desde una segunda fuente; de lo contrario, resulta difícil saber qué versión está realmente en marcha. Deje constancia además de qué sitio web funciona con qué versión de lsphp. En servidores con muchas cuentas de clientes, esta lista es la base para informar de forma selectiva a los titulares y para comprobar por muestreo, después de la actualización, que los sitios web funcionan sin errores. Los sitios web que exijan una versión de PHP que ya no recibe soporte deben ir en una lista aparte, porque para ellos no llegará ninguna actualización oficial.
¿Cómo ayuda PHP SOS en concreto?
- Registramos todas las versiones de lsphp, los repositorios de paquetes y las asignaciones de manejadores de su servidor.
- Mediante el servicio de parcheo de PHP actualizamos, finalizamos todos los procesos lsphp antiguos y documentamos la prueba.
- Donde todavía no hay paquete disponible, fijamos los valores provisionales para todo el servidor y limitamos la memoria mediante cgroup.
- Revisamos los sitios web en busca de rastros de un ataque y conservamos los registros.
Preguntas frecuentes
¿Afecta PHP2Shell a LiteSpeed?
Sí. Según el proyecto PHP, LiteSpeed figura entre los modos de funcionamiento afectados. Las vulnerabilidades están en el propio PHP, que LiteSpeed ejecuta mediante LSAPI. Por tanto, lo determinante es el estado de los paquetes lsphp.
¿Por qué siguen en marcha procesos lsphp antiguos después de la actualización?
LiteSpeed puede dejar los procesos PHP funcionando de forma independiente del servidor web para ahorrar tiempo de carga. Según el modo de funcionamiento, reiniciar el servidor web no los finaliza de inmediato. Por eso compruebe la hora de inicio de todos los procesos lsphp.
¿Vale también para OpenLiteSpeed?
En principio sí. OpenLiteSpeed también usa lsphp mediante LSAPI. Las rutas, los repositorios de paquetes y la interfaz de administración son distintos, pero el principio de actualizar, reiniciar y controlar es el mismo.
¿Ayuda la caché de LiteSpeed contra la vulnerabilidad?
No. Una caché de páginas sirve algunas páginas sin PHP, pero las solicitudes que llegan a PHP siguen siendo vulnerables. Una caché no sustituye a la actualización de PHP.