CVE-2026-48172

Falha de escalonamento de privilégios no plugin user-end de cPanel da LiteSpeed (não no plugin WHM, que não foi afetado) permite que qualquer conta cPanel — incluindo uma conta comprometida — execute scripts arbitrários como root através da função lsws.redisAble, usada para habilitar/desabilitar o Redis por usuário. É crítica porque compromete o host completo a partir de uma única conta de hospedagem compartilhada, e já está confirmada como explorada em massa em maio de 2026, com entrada no catálogo KEV da CISA.

A causa raiz, classificada como CWE-266 (atribuição incorreta de privilégio), está na função lsws.redisAble, exposta via cPanel JSON-API sob o parâmetro cpanel_jsonapi_func=redisAble. Essa função é chamada para habilitar ou desabilitar o serviço Redis por usuário em ambientes com cage (CloudLinux ou LiteSpeed Containers), e no fluxo de habilitação/desabilitação ela dispara execução de script/comando privilegiado sem validar corretamente o contexto de chamada ou o conteúdo controlado pelo usuário. O resultado é que uma rotina que roda com privilégio de root para configurar o Redis do usuário pode ser abusada para executar comandos arbitrários com esse mesmo privilégio.

O atacante controla os parâmetros da chamada JSON-API que aciona a função redisAble; a falha está em como o backend confia nesses parâmetros ao montar/executar o script de habilitação. O fornecedor não detalhou publicamente o payload exato (nem deveria), mas o padrão de correção — endurecimento de manuseio de arquivos redis.size/redis.package por usuário, restrição da tela de Redis a ambientes cage totalmente configurados, hardening de scripts auxiliares de Redis — indica que o vetor envolvia manipulação de caminhos/arquivos de configuração por usuário que eram depois processados com privilégio elevado sem sanitização suficiente.

Vale registrar uma tensão entre a descrição do fornecedor e o vetor CVSS publicado: o CVSS 4.0 usa PR:N (nenhum privilégio necessário), mas o blog da LiteSpeed é explícito — "qualquer usuário cPanel (incluindo um atacante ou uma conta comprometida)" pode explorar. Ou seja, na prática é necessária uma conta cPanel válida e autenticada; não é uma falha pré-autenticação explorável por um visitante anônimo do site hospedado.

O vetor de exploração observado é a chamada ao endpoint JSON-API do cPanel com cpanel_jsonapi_func=redisAble a partir de uma sessão de usuário cPanel comum — qualquer conta, não é preciso ser reseller ou ter permissões elevadas dentro do painel. Isso é compatível com o cenário mais comum de abuso: um provedor de hospedagem compartilhada onde qualquer cliente (ou um atacante que compre/comprometa uma conta barata) consegue rodar comandos como root no servidor físico, afetando todos os outros clientes hospedados ali.

A pré-condição real, portanto, é acesso autenticado a uma conta cPanel no servidor alvo com o plugin user-end da LiteSpeed instalado em versão vulnerável — e, pelo padrão de correção, ambiente com suporte a Redis habilitado/configurável (cage CloudLinux ou LiteSpeed Containers). Ambientes sem esse recurso de Redis exposto para usuários finais reduzem a superfície, mas o fornecedor não afirma que isso elimina o risco totalmente, e a correção de v2.4.7 endureceu múltiplos pontos além do Redis.

A exploração ativa em maio de 2026 foi identificada por assinatura de log (chamadas ao endpoint redisAble), o que sugere um exploit relativamente direto de reconhecer/automatizar em massa contra servidores cPanel expostos — não foi um ataque teórico. Não há confirmação pública, nas fontes usadas, sobre a técnica exata usada para ir de "chamar a função" a "executar como root" (não deve ser reconstruída aqui), mas o efeito final documentado é execução arbitrária de comando/script com privilégio de root a partir de uma conta de usuário comum.

Atualizar o plugin user-end de cPanel para v2.4.5 ou superior remove o vetor original; o fornecedor recomenda como mínimo v2.4.7 (bundlado com WHM plugin v5.3.1.0), lançado em 21/05/2026 após uma revisão de segurança completa feita com a equipe cPanel/WebPros, que endureceu vetores adicionais (sem exploração confirmada). É importante notar que o release log mostra hardening de segurança contínuo em versões posteriores — v2.4.8 (01/06/2026) corrigiu explicitamente "um exploit relatado que permitia a um usuário cPanel autenticado escalar privilégios para root" via hardening de symlink, e v2.4.9 (18/06/2026) trouxe mais correções de segurança em Redis e outras áreas. Isso é um sinal forte de que travar em 2.4.7 é o mínimo aceitável, não o alvo ideal — recomenda-se a versão mais recente disponível, não apenas a mínima citada na descrição da CVE.

Se a atualização não for possível imediatamente, o próprio fornecedor oferece um paliativo real: desinstalar o plugin user-end com /usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall. O custo é funcional — os usuários finais do cPanel perdem a integração direta com o LiteSpeed (gerenciamento de cache LSCWP, seleção de handler PHP, toggle de Redis pela própria conta); a administração via WHM não é afetada, pois o plugin WHM não contém a falha.

O que não resolve: bloquear IPs identificados no grep de detecção é resposta a incidente, não mitigação da vulnerabilidade — trata sintomas de exploração já ocorrida, não impede novas tentativas enquanto a versão vulnerável estiver instalada. Desabilitar apenas o recurso de Redis pela interface, sem atualizar ou desinstalar o plugin, não foi validado pelo fornecedor como suficiente.

O próprio fornecedor fornece o indicador de comprometimento oficial: grep -rE "cpanel_jsonapi_func=redisAble" /var/cpanel/logs /usr/local/cpanel/logs/ 2>/dev/null. Ausência de saída indica que o servidor não foi alvo dessa exploração específica; presença de saída exige verificar se os IPs de origem são legítimos (usuários reais do próprio servidor) e, caso não sejam, bloqueá-los e investigar logs do sistema por ações realizadas por esses IPs no período.

Esse grep detecta apenas o vetor específico documentado (chamada ao endpoint redisAble) e não cobre necessariamente os vetores adicionais endurecidos em versões posteriores (v2.4.8, v2.4.9) nem eventuais variações do ataque que não passem por esse endpoint exato — trate a ausência de resultado como "não visto por esse indicador", não como garantia absoluta de que o servidor nunca foi comprometido por técnicas relacionadas.