LiteSpeed Enterprise antes da 6.3.7: falha crítica permite root e escape do CageFS

cPanel & WHM Risco Crítico

LiteSpeed Enterprise antes da 6.3.7: falha crítica permite root e escape do CageFS

LiteSpeed Web Server Enterprise anterior à versão 6.3.7 possui falha crítica de escalação de privilégio: um usuário web de baixo privilégio pode escapar do CageFS e alcançar root no servidor.

Revisado em 14/09/2026 Leitura técnica
Sem CVE público atribuído até 14/09/2026
SeveridadeCrítico
Versões afetadasLiteSpeed Web Server Enterprise em todas as versões anteriores à 6.3.7, inclusive em servidores cPanel com CageFS
Versões corrigidasLiteSpeed Web Server Enterprise 6.3.7 ou superior
Status WebinHostCorreção crítica disponível; atualização imediata recomendada

O cPanel publicou um alerta emergencial sobre uma falha crítica de escalação de privilégio no LiteSpeed Web Server Enterprise. Um usuário malicioso de site, mesmo operando com baixo privilégio, pode ultrapassar os limites esperados da conta, escapar do CloudLinux CageFS e obter acesso root ao servidor. Todas as versões anteriores à 6.3.7 devem ser atualizadas.

O que aconteceu

O cenário divulgado é especialmente grave para hospedagem compartilhada: uma conta web comprometida por plugin vulnerável, senha roubada ou código enviado pelo próprio cliente pode ser usada como ponto de partida para controlar o host. Com root, o invasor pode ler ou alterar outros sites, bancos, e-mails, backups montados, chaves e configurações do painel.

O changelog da LiteSpeed 6.3.7 registra reforço na autenticação e validação de requisições do lscgid, validação mais forte de redirecionamentos internos e bloqueio de variáveis de ambiente reservadas em .htaccess. O fornecedor não publicou detalhes suficientes para mapear com segurança toda a cadeia a um único componente; por isso, não é correto presumir que uma configuração isolada elimine a exposição. Até esta revisão, também não havia CVE público atribuído no boletim.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

Produto ou linhaAfetado / expostoCorrigido / protegido
LiteSpeed Enterprise 6.3.6 e anterioresafetadoatualizar para 6.3.7+
LiteSpeed Enterprise 6.3.7corrigido para o advisoryvalidar binário ativo e reinício
LiteSpeed Enterprise 6.4.0 RC2+contém os mesmos reforços, mas é ramo RCusar ramo aprovado pela política operacional
OpenLiteSpeednão incluído no escopo publicadoacompanhar boletins próprios

O risco não depende de uma conta possuir shell SSH. Aplicações PHP e outros processos web já executam no contexto do usuário e podem satisfazer o ponto de partida de baixo privilégio. CageFS continua sendo uma camada importante de isolamento, mas o próprio boletim afirma que a falha pode contorná-lo; vê-lo ativo não prova proteção contra este advisory.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Crítico, sem CVSS público no boletim. A consequência documentada é root com acesso cruzado entre contas. Mesmo sem pontuação numérica ou prova pública detalhada, o impacto é perda total de confidencialidade, integridade e disponibilidade do servidor. A classificação crítica do fornecedor deve prevalecer para priorização operacional.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Confirme a edição Enterprise, a versão do binário realmente carregado, o pacote do plugin cPanel e a data do processo. Não tente reproduzir a escalação em produção. Um painel que mostra 6.3.7 enquanto os workers antigos continuam em memória requer reinício e nova conferência.

/usr/local/lsws/bin/lshttpd -v
/usr/local/lsws/bin/lshttpd -V 2>/dev/null | head -30
ps -eo pid,lstart,user,cmd | grep '[l]itespeed'
/usr/local/cpanel/bin/whmapi1 servicestatus service=lsws 2>/dev/null

Qualquer resultado Enterprise inferior a 6.3.7 está vulnerável segundo o cPanel. Se o comando não existir, identifique se o host usa Apache, NGINX ou OpenLiteSpeed antes de concluir que não está afetado. Versões divergentes entre WebAdmin, binário e processos exigem concluir o ciclo de atualização.

Faça somente inventário defensivo. Não execute prova de conceito em produção. Um exploit pode derrubar o host, alterar dados, apagar vestígios ou atingir outros clientes. Se o resultado for ambíguo, preserve as saídas e compare-as com o boletim do fornecedor.

Como corrigir ou mitigar

Use o atualizador oficial para instalar exatamente 6.3.7 ou uma versão estável posterior aprovada. Preserve configuração e licença, garanta uma rota administrativa alternativa e acompanhe o restart. Não faça downgrade para uma versão antiga após o teste. Se a atualização estiver impedida, restrinja temporariamente contas não confiáveis e avalie retornar ao Apache, com janela e plano de rollback.

/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7
/usr/local/lsws/bin/lshttpd -v
/usr/local/cpanel/scripts/restartsrv_httpd --check

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Teste HTTP/HTTPS, HTTP/2 e HTTP/3, aplicações PHP, LSCache, WebAdmin, ModSecurity, redirects e todos os virtual hosts. Revise processos root iniciados a partir do serviço web, alterações em sudoers, crons, systemd, chaves SSH, módulos PHP e arquivos fora das contas. Um host possivelmente explorado precisa de resposta a incidente; apenas atualizar não remove persistência anterior.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Nos servidores gerenciados, a WebinHost identifica o binário ativo, atualiza o LiteSpeed pela ferramenta oficial, acompanha o restart e testa sites e protocolos. Imunify360 ajuda a bloquear o comprometimento inicial e detectar webshells, enquanto CloudLinux/CageFS limita contas em condições normais. Como este advisory declara bypass do CageFS, a versão 6.3.7+ e a investigação da janela exposta são indispensáveis.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Escopo dos planos gerenciados: a WebinHost prioriza falhas críticas e altas na infraestrutura administrada. Sites, temas, plugins, código e credenciais do cliente continuam exigindo atualização e revisão pelo responsável da aplicação, salvo contratação específica. O status deve ser confirmado por servidor; possuir KernelCare ou Imunify360 não é, isoladamente, prova de que todo CVE foi corrigido.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais e técnicas

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.

Precisa validar seu ambiente?

Conte com gerenciamento técnico de servidores

A atualização de aplicações do cliente e a administração do servidor têm escopos diferentes. Fale com a equipe para avaliar o ambiente e o plano adequado.