LiteSpeed cPanel Plugin: el symlink de un usuario FTP que se vuelve root en tu servidor de hosting

Contexto del incidente

El 1 de junio de 2026, LiteSpeed publico un parche fuera de banda para el plugin de LiteSpeed en cPanel (security advisory oficial). La vulnerabilidad quedo registrada como CVE-2026-54420, con un CVSS 3.1 de 8.5 (HIGH) y vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. El 15 de junio, CISA la sumo al catalogo KEV con fecha de remediacion BOD 26-04 el 18 de junio, o sea manana.

El vector es una escalada de privilegios clasica por symlink UNIX (CWE-61) en el plugin de cPanel de LiteSpeed, sobre servidores de hosting compartido que corren CloudLinux con CageFS. Lo reporto el equipo de Namecheap tras ver explotacion real. La tecnica que ya vimos miles de veces vuelve a pegar, esta vez con un nombre nuevo: cualquier cuenta de usuario con FTP o web shell puede crear un symlink que engane al plugin y terminar ejecutando acciones como root, saltando el aislamiento que CageFS deberia dar.

El aislamiento entre usuarios en hosting compartido no es un producto, es un proceso. Y cuando un componente como el plugin de LiteSpeed corre con privilegios altos, todo el CageFS del mundo se evapora en una tarde.

Como funciona el ataque?

El plugin de LiteSpeed para cPanel expone una user-end plugin que maneja tareas administrativas especificas de cada cuenta desde el panel de usuario. Para realizarlas, invoca endpoints internos de la API de cPanel con privilegios elevados. El bug esta en como el plugin resuelve paths antes de hacer esas llamadas: si un usuario malicioso (o un atacante que ya compromise una cuenta FTP o suba un web shell) crea un symlink estrategicamente ubicado dentro de su espacio, el plugin lo sigue y termina escribiendo o ejecutando fuera del home del usuario, en zonas donde CageFS no llega a confinar.

El escenario concreto que explotaron en mayo, segun el advisory, es encadenar dos endpoints JSONAPI de cPanel en una secuencia que un usuario legitimo nunca combinaria:

• generateEcCert: crea un certificado SSL autofirmado para una cuenta.
• packageUserSize: recalcula el espacio usado por una cuenta.

Estas dos llamadas, una detras de la otra, con alta concurrencia (7-10 en paralelo) y desde la misma IP de origen, son la huella digital de la explotacion. La UI legitima de cPanel hace una a la vez, y el plugin de LiteSpeed las invoca bajo un contexto con el que el atacante puede pivotar hacia root usando el symlink como puente.

Como proteger tu infraestructura?

1. Actualizar el plugin a 2.4.8 (y el WHM plugin a 5.3.2.1+)

El fix es directo: el plugin de LiteSpeed para cPanel tiene que estar en 2.4.8 o superior, que viene empaquetado con el WHM Plugin 5.3.2.1. Para actualizar y re-instalar el plugin de usuario, ejecuta:

wget -O- https://litespeedtech.com/packages/cpanel/lsws_whm_plugin_install.sh | sh

Si por algun motivo no podes actualizar, la mitigacion de emergencia que LiteSpeed publico es desinstalar el plugin de usuario:

/usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall

Esto desactiva el vector de ataque aunque te quedes con la version vieja del plugin. Una vez que actualices, podes reinstalarlo con --install y volver a habilitar el autoinstall con --autoinstall 1.

2. Auditar logs en busca de la firma del ataque

LiteSpeed publico un comando de deteccion oficial. Si devuelve lineas, tenes que investigar caso por caso porque hay falsos positivos, pero las senales caracteristicas son estas tres:

grep -rE "cpanel_jsonapi_func=(generateEcCert|packageUserSize)|cert_action_entry .*geneccert" /usr/local/cpanel/logs/ /var/cpanel/logs/ 2>/dev/null

Lo que tenes que mirar en cada hit:

• Pairing: generateEcCert seguido inmediatamente por packageUserSize para la misma cuenta (la UI legitima no encadena estas dos).
• Concurrencia: 7-10 llamadas concurrentes en un corto periodo (la UI legitima hace una a la vez).
• Origen unico: la misma IP de origen golpeando ambos endpoints en rafaga.

Si confirmas un hit, revisa los logs del sistema por la IP atacante para ver que acciones dispararon: paquetes cambiados, certs nuevos, archivos subidos.

3. Revisa tu exposicion de CageFS y los symlinks

CageFS aisla cada usuario en su propio filesystem jail, pero esa garantia se rompe si algun proceso con privilegios altos sigue symlinks fuera de los confines del usuario. Un par de controles utiles:

• Valida que /usr/share/cagefs-skeleton este bien configurado y que no haya copias sueltas de binarios que permitan escapar del jail.
• Monitorea lveinfo y los contadores LVE de CloudLinux para detectar picos anomalos de I/O o CPU por usuario, que son la senal tipica de alguien ejecutando cosas pesadas desde una cuenta de hosting (scanners, mineros, exfil).
• Activa auditd con watch sobre /etc/passwd, /etc/shadow y /var/cpanel. Una modificacion ahi suele ser post-explotacion.

4. Aplica el principio de menor privilegio al FTP y a los web shells

La entrada al ataque es una cuenta FTP o un web shell. Vale la pena endurecer esto aunque no corras LiteSpeed:

• Deshabilita FTP plano en favor de SFTP/FTPS con RequireExplicitSsl=1 en la config de Pure-FTPd o ProFTPD.
• Forza quotas estrictas y open_basedir en PHP-FPM para que un web shell no pueda ni siquiera leer fuera del docroot de la cuenta.
• Monitorea uploads de archivos .php, .phtml, .phar en /home/*/public_html con WAF de capa 7 o inotifywait y alerta al admin en tiempo real.
• Para cuentas sospechosas o clientes nuevos, dejalas las primeras 72h en una zona de staging con CageFS mas restrictivo (cagefsctl --enable con jail en modo strict).

Indicadores de compromiso (IoC)

Los IoCs oficiales publicados por LiteSpeed estan en el advisory del 1 de junio. Lo mas util es la busqueda de logs y la heuristica de pairing, porque no hay un payload unico con hash publico todavia. Estos son los indicadores que tenes que cazar:

• Endpoints JSONAPI en pairing sospechoso: generateEcCert + packageUserSize en la misma cuenta dentro de la misma ventana temporal.
• Concurrencia anomala: 7-10 invocaciones paralelas del mismo endpoint en menos de un minuto, algo que ningun usuario legitimo dispara.
• Symlinks creados en /home/<user>/ apuntando fuera del docroot: find /home/*/public_html -type l -lname "/etc/*" -o -lname "/var/cpanel/*" -o -lname "/root/*" te tira cualquier symlink cruzado que ya este plantado.
• Certs SSL nuevos en cuentas que no administran dominios: revisalos con grep -r "crt.sh|cert_action_entry" /var/cpanel/logs/access.log y filtra por cuentas que no tengan dominios delegados.
• Cambios en /var/cpanel/packages o /var/cpanel/quota: paquetes modificados o quotas relajadas por una cuenta que no deberia poder hacerlo son post-explotacion casi garantizada.

Para Splunk/ELK, un query inicial util para cazar la firma del ataque en los access logs de cPanel:

index=cpanel sourcetype=access_combined
| rex field=uri "/(?<api>\w+)/(?<func>\w+)\?"
| where api="cpanel_jsonapi" AND func IN ("generateEcCert", "packageUserSize")
| stats count values(func) AS functions values(src_ip) AS ips BY user
| where functions="generateEcCert,packageUserSize" AND count > 5

Y para Suricata/Snort, una firma generica para detectar las llamadas encadenadas en HTTP (ajusta a tu entorno):

alert http any any -> $HOME_NET 2082 (msg:"CVE-2026-54420 LiteSpeed cPanel chain gen"; flow:established,to_server; http_uri; content:"/cpanel_jsonapi_func=generateEcCert"; nocase; http_uri; content:"cpanel_jsonapi_func=packageUserSize"; nocase; distance:0; within:2048; classtype:web-application-attack; sid:202654420; rev:1;)