<

Três vulnerabilidades corrigidas pelo cPanel em 29 de setembro atingiam todas as versões suportadas do cPanel & WHM. A mais grave permite execução de comandos como root; as outras duas usam XSS armazenado para agir dentro da sessão de um administrador do WHM.
O cPanel publicou correções para três falhas que merecem atenção especial de provedores de hospedagem, empresas que mantêm servidores próprios e equipes responsáveis por ambientes gerenciados com cPanel & WHM. O problema não está apenas na existência de três CVEs no mesmo ciclo de atualização, mas no caminho de escalada que elas abrem dentro de uma plataforma que concentra administração de contas, sites, certificados, bancos de dados e serviços do servidor.
A CVE-2026-93698 é a de maior impacto. Segundo o próprio cPanel, uma validação insuficiente no Multilang adminbin permite a execução de comandos arbitrários. Se a exploração for bem-sucedida, o código é executado como root, dando ao atacante controle completo do servidor e de todas as contas, sites e bancos de dados hospedados nele.
Uma falha deixa de ser “de uma conta” quando o alvo é o painel de controle
Em hospedagem compartilhada, a separação entre contas é uma das barreiras que impede o comprometimento de um site de alcançar os demais clientes. A CVE-2026-93698 rompe justamente essa expectativa: um problema no componente administrativo pode transformar uma posição inicial restrita em acesso ao sistema operacional com o nível máximo de privilégio.
Esse tipo de cenário amplia o impacto muito além da aplicação originalmente comprometida. Com privilégios de root, um invasor pode modificar arquivos de múltiplos sites, acessar bancos de dados, criar mecanismos de persistência, alterar configurações de serviços, coletar credenciais armazenadas no servidor e interferir em logs que seriam usados na investigação. A indisponibilidade é apenas uma das possibilidades; perda de confidencialidade e integridade pode ocorrer antes de qualquer interrupção visível.
Duas XSS armazenadas miram a sessão administrativa do WHM
As outras duas vulnerabilidades exploram um mecanismo diferente. A CVE-2026-93697 afeta as interfaces de modificação de contas do WHM, incluindo o recurso Mass Modify Accounts. A CVE-2026-93029 está na interface Manage SSL Hosts. Nos dois casos, o cPanel classifica a falha como XSS armazenado.
O ponto tecnicamente relevante é onde o código malicioso é executado. O fabricante informa que um titular de conta sem privilégios pode fazer com que um script seja executado no contexto da sessão de um administrador do WHM. A partir daí, o código passa a operar com os direitos daquele administrador e pode realizar ações administrativas em seu nome.
Isso também explica por que autenticação multifator, embora continue importante para impedir o roubo direto de credenciais, não substitui o patch. Em uma XSS armazenada, o administrador pode ter se autenticado corretamente com MFA; o problema aparece depois, quando a própria sessão legítima processa conteúdo malicioso dentro de uma interface vulnerável.
| Vulnerabilidade | Componente | Impacto principal |
|---|---|---|
| CVE-2026-93698 | Multilang adminbin | Execução de comandos como root |
| CVE-2026-93697 | Account Modification / Mass Modify Accounts | XSS armazenado na sessão de administrador |
| CVE-2026-93029 | Manage SSL Hosts | XSS armazenado na sessão de administrador |
Quais versões precisam ser verificadas
O aviso oficial informa que todas as versões suportadas estavam afetadas antes dos builds corrigidos. A proteção não deve se basear apenas na percepção de que o servidor “está atualizado”: a equipe precisa confirmar o número exato do build instalado e compará-lo com a linha suportada em uso.
- 11.110.0.148 ou posterior;
- 11.134.0.61 ou posterior;
- 11.136.0.45 ou posterior;
- 11.138.0.11 ou posterior;
- WP2: 11.138.1.13 ou posterior.
Atualizar é a primeira resposta; investigar é a segunda
A medida imediata é atualizar o cPanel & WHM para um dos builds corrigidos ou para a versão mais recente disponibilizada pelo fornecedor. Como a CVE-2026-93698 pode terminar em execução como root, servidores que permaneceram vulneráveis e expostos merecem mais do que uma simples confirmação de que o update foi aplicado.
Equipes responsáveis pelo ambiente devem revisar autenticações e acessos administrativos, alterações de contas e privilégios, criação de usuários, chaves SSH, tarefas agendadas, processos e serviços incomuns, modificações em DNS e certificados, arquivos de sites e eventos que indiquem execução de comandos fora do padrão. Em ambientes com centralização de logs, vale comparar os eventos do host com registros externos que um invasor com root não conseguiria alterar no mesmo servidor.
A interface administrativa do WHM também deve permanecer acessível somente a quem realmente precisa dela. Restrições por VPN, rede de gestão, allowlists ou controles de acesso baseados em identidade reduzem exposição desnecessária. Contas de revenda e administração devem seguir menor privilégio, e MFA continua recomendado para limitar comprometimentos por senha — com a ressalva de que ele não corrige as falhas de XSS.
Backups precisam estar isolados do servidor administrado pelo cPanel e ter restauração testada. Se houver evidência confiável de execução como root, a resposta deve considerar a possibilidade de comprometimento integral do host: preservar evidências, rotacionar credenciais e segredos a partir de um ambiente confiável e avaliar reconstrução do servidor a partir de uma base conhecida, em vez de assumir que remover um arquivo malicioso encerra o incidente.
O risco está na concentração de autoridade
Painéis de controle simplificam a operação porque reúnem muitas funções administrativas. A mesma concentração aumenta o dano potencial quando uma falha atravessa a fronteira entre conta, sessão administrativa e sistema operacional. No conjunto divulgado pelo cPanel, essa relação aparece com clareza: duas vulnerabilidades podem usar a sessão do administrador; a terceira alcança diretamente o nível root.
A correção de setembro deve ser tratada como uma atualização prioritária, especialmente em ambientes com múltiplos clientes ou aplicações. Depois do patch, a pergunta útil não é apenas se o servidor voltou a ficar “atualizado”, mas se existem registros e controles suficientes para demonstrar que nenhuma conta vulnerável foi usada como ponto de partida enquanto a falha estava aberta.
<
Referências
<
ol>


Be the first to comment