Una falla crítica en versiones previas a 6.3.7 rompe el aislamiento entre usuarios en hosting compartido y elude CageFS de CloudLinux
El 11 de septiembre, LiteSpeed lanzó la versión 6.3.7 de su servidor web Enterprise con un parche de seguridad que cierra una vulnerabilidad de escalada de privilegios capaz de otorgar acceso root a un usuario de bajo privilegio en entornos de hosting compartido. La falla afecta todas las versiones anteriores a 6.3.7 y puede eludir controles de aislamiento de cuentas, incluido CageFS, la capa de CloudLinux diseñada para restringir la vista del sistema de archivos de cada cuenta y evitar que un usuario acceda a configuraciones de otros inquilinos o del servidor mismo. cPanel emitió un aviso de seguridad advirtiendo que un atacante con acceso a una cuenta de sitio web de bajo privilegio podría potencialmente acceder o alterar otros sitios alojados y el servidor completo.
Por qué un salto de CageFS cambia las reglas del juego en hosting compartido
En un servidor de hosting compartido típico, decenas o cientos de clientes coexisten en la misma máquina. CageFS funciona como una jaula virtual que otorga a cada cuenta una vista restringida del sistema de archivos, impidiendo que un usuario vea configuraciones de otros usuarios o del servidor. Si una vulnerabilidad derrota esa barrera, un solo inquilino malicioso puede leer o modificar otros sitios y tomar control de la máquina completa. La falla en LiteSpeed Enterprise permite exactamente eso: un usuario con privilegios mínimos puede escapar de su entorno restringido y obtener acceso root al servidor, lo que convierte un riesgo teórico en un compromiso cross-tenant completo.
Ni cPanel ni LiteSpeed divulgaron detalles técnicos sobre la vulnerabilidad. El anuncio de LiteSpeed del 11 de septiembre para la versión 6.3.7 menciona únicamente mejoras de seguridad, correcciones de errores y más, y el registro de cambios lista tres cambios de seguridad sin especificar un problema de escalada de privilegios. No se ha asignado un CVE ni una calificación de severidad, y no está claro si atacantes ya están explotando la falla en la práctica.
Cómo actualizar cuando la versión estable aún no refleja el parche
LiteSpeed y cPanel recomiendan a los administradores ejecutar el comando de actualización forzada /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7 para aplicar el parche de inmediato. LiteSpeed advirtió que la versión 6.3.7 puede tardar en llegar al canal de actualización automática estable. Al 15 de septiembre, la página de descargas todavía listaba 6.3.6 como la versión estable más reciente. Forzar la actualización a 6.3.7 implica salir temporalmente del canal estable, que puede restaurarse más adelante. No existe un workaround para sistemas que no puedan parchearse de inmediato.
El aviso cubre únicamente la edición Enterprise. OpenLiteSpeed, la variante de código abierto, no tenía una actualización correspondiente al 15 de septiembre, lo que deja a los usuarios de esa versión sin un camino claro de mitigación documentado.
El patrón de tres escapes root en cinco meses vinculados a LiteSpeed
Desde mayo de 2024, se han vinculado tres escapes a nivel root en servidores cPanel de hosting compartido a fallos relacionados con LiteSpeed. Este año, LiteSpeed corrigió dos vulnerabilidades en su plugin para cPanel, CVE-2026-48172 y CVE-2026-54420, que fueron explotadas activamente en la naturaleza. CISA agregó ambas vulnerabilidades al catálogo de Vulnerabilidades Conocidas Explotadas, lo que indica que atacantes ya las habían incorporado a campañas reales. La nueva falla en LiteSpeed Enterprise representa el tercer caso en cinco meses donde un componente de LiteSpeed permite a un atacante romper el aislamiento de cuentas en entornos compartidos.
La recurrencia de este patrón sugiere que el modelo de aislamiento en entornos de hosting compartido que dependen de LiteSpeed enfrenta presión sostenida. Cada escape root en un servidor compartido no afecta a un solo cliente, sino a todos los inquilinos del servidor, lo que multiplica el impacto de cada falla individual.
Exposición en América Latina por dependencia de hosting compartido económico
En América Latina, el hosting compartido sigue siendo la opción dominante para pequeñas y medianas empresas que buscan presencia web a bajo costo. Proveedores regionales en México, Brasil, Argentina y Colombia ofrecen planes compartidos con cPanel y LiteSpeed como combinación estándar, lo que concentra la exposición a esta vulnerabilidad en un segmento amplio del mercado. Un atacante que comprometa un servidor compartido en un proveedor regional puede acceder a decenas de sitios de comercio electrónico, portales de servicios profesionales y aplicaciones de gestión empresarial alojados en la misma máquina.
La falta de actualización para OpenLiteSpeed al 15 de septiembre agrava el riesgo en la región, donde algunos proveedores más pequeños optan por la variante de código abierto para reducir costos de licenciamiento. Sin un parche disponible para esa edición, esos servidores quedan expuestos sin un camino de mitigación claro, lo que amplía la ventana de oportunidad para atacantes que busquen comprometer múltiples sitios de una sola vez.
Nuestro análisis
La falla en LiteSpeed Enterprise confirma un patrón que ya se había manifestado dos veces en 2024: los controles de aislamiento en entornos de hosting compartido que dependen de LiteSpeed están siendo derrotados de manera recurrente. La capacidad de eludir CageFS, una capa de seguridad específicamente diseñada para evitar este tipo de escapes, indica que el problema no es solo una vulnerabilidad puntual en el código, sino una debilidad estructural en cómo se implementa el aislamiento en estos entornos. La ausencia de un CVE asignado y de detalles técnicos públicos al 15 de septiembre dificulta que administradores evalúen el riesgo real y que investigadores independientes auditen la corrección.
La demora en que la versión 6.3.7 llegue al canal estable y la falta de actualización para OpenLiteSpeed crean una ventana de exposición prolongada. Para proveedores de hosting compartido en América Latina, donde la concentración de clientes en servidores compartidos es alta y los márgenes operativos son ajustados, la decisión de forzar una actualización fuera del canal estable implica un riesgo operativo que muchos pueden postergar. Si esta falla ya está siendo explotada en la práctica — algo que no se puede descartar dado el historial de explotación activa de las dos vulnerabilidades previas — la ventana de oportunidad para atacantes se extiende cada día que un servidor permanece sin parche. ¿Cuántos servidores compartidos en la región seguirán expuestos mientras esperan que la actualización llegue al canal estable o que OpenLiteSpeed publique su propio parche?