Em hospedagem compartilhada, uma conta cPanel deveria controlar apenas os próprios domínios, arquivos e bancos. A CVE-2026-65643 quebra exatamente essa fronteira. Segundo o advisory publicado pela cPanel em 27 de agosto de 2026, um usuário autenticado que possa adicionar domínios estacionados ou adicionais consegue criar arquivos arbitrários no servidor. A exploração bem-sucedida termina em execução de código como root, com controle sobre todas as contas, sites e bases hospedadas na máquina.
O registro público da CVE classifica a falha como eval injection, CWE-95, e atribui CVSS 4.0 de 8,7, com o vetor CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. A nota é alta, não crítica, porque exige uma conta de baixo privilégio. No modelo comercial de shared hosting, porém, entregar essa conta a um cliente é comportamento normal do produto. O pré-requisito reduz o universo de atacantes, mas não reduz o impacto de uma passagem direta de tenant para root.
O que está confirmado, e o que ainda não está
As fontes oficiais confirmam a condição de entrada, a criação arbitrária de arquivos e o resultado como root. O registro CVE acrescenta a classificação de eval injection. Elas não publicam o parâmetro vulnerável, o caminho do arquivo criado, uma sequência de requisições, indicadores de comprometimento ou uma PoC. Sem esses dados, qualquer payload detalhado seria especulação. Por isso, a validação segura começa por versão, permissão e exposição da funcionalidade, sem tentar reconstruir um exploit em produção.
- Atacante necessário: usuário remoto autenticado no cPanel
- Permissão necessária: capacidade de adicionar parked domains ou addon domains
- Primitiva confirmada: criação de arquivos arbitrários no servidor
- Impacto confirmado: execução de código como root e controle integral do host
- Interação de outra pessoa: nenhuma depois que o atacante possui a conta e a permissão
- Detalhes não publicados: payload, arquivo de destino, IOC e estado de exploração em campo
Por que uma credencial de tenant não é uma barreira forte
Em uma aplicação corporativa comum, exigir autenticação pode restringir uma falha a funcionários ou parceiros. Em hospedagem compartilhada, a conta de baixo privilégio faz parte do serviço vendido. Ela pode pertencer a um cliente legítimo malicioso, ser criada com identidade fraudulenta, vazar por phishing ou ser tomada por reutilização de senha. O teste de risco precisa usar o modelo real de aquisição da credencial, e não tratar PR:L como sinônimo de acesso interno confiável.
Depois da elevação, o isolamento entre contas deixa de proteger os demais tenants. Root pode alcançar webroots, configurações de bancos, caixas de e-mail, chaves, backups, tarefas agendadas e credenciais mantidas por serviços locais. A cPanel resume o impacto como controle de cada conta, website e banco no servidor. Em um host com dezenas de clientes, portanto, o raio de ação é definido pela densidade do servidor, não pelo tamanho da conta usada como ponto de entrada.
CVSS 8,7, impacto operacional crítico
O vetor CVSS 4.0 combina ataque pela rede, baixa complexidade, ausência de requisito especial e nenhuma interação de usuário com privilégio prévio baixo. Confidencialidade, integridade e disponibilidade do sistema vulnerável recebem impacto alto. Não há impacto subsequente pontuado no vetor, mas isso não significa que outros clientes estejam protegidos. As contas hospedadas fazem parte do mesmo sistema sob autoridade do root, e o próprio fornecedor declara que todas ficam ao alcance.
Esse é um caso em que o número precisa ser lido junto do modelo de negócio. Um filtro que priorize apenas CVEs acima de 9,0 pode colocar a falha atrás de problemas sem caminho real até produção. Para um provedor com cadastro aberto, revendedores ou muitas contas geridas por terceiros, a combinação de credencial acessível e impacto total merece tratamento de emergência mesmo com base score 8,7.
Versões corrigidas e como confirmar a atualização
A cPanel afirma que todas as versões suportadas estavam afetadas e publica um build corrigido para cada linha. O resumo da CVE menciona 11.138.0.0 e anteriores, mas não devemos transformar esse texto curto em um corte único para todas as branches. Para remediar, compare a instalação com a linha correspondente da tabela do fornecedor e atualize para um dos builds abaixo ou posterior.
- cPanel & WHM 11.110: build 11.110.0.141 ou posterior
- cPanel & WHM 11.134: build 11.134.0.53 ou posterior
- cPanel & WHM 11.136: build 11.136.0.37 ou posterior
- cPanel & WHM 11.138: build 11.138.0.2 ou posterior
- WP Squared, identificado como WP2 no advisory: build 11.138.1.7 ou posterior
- Versões fora de suporte: migrar primeiro para uma linha suportada, pois versões EOL não recebem correções de segurança
# Check the version that is actually installed
/usr/local/cpanel/cpanel -V
# As root, apply the update recommended by cPanel
/usr/local/cpanel/scripts/upcp --force
# Confirm the version again after the update
/usr/local/cpanel/cpanel -VNão basta confirmar que o repositório ou a política de updates aponta para uma linha segura. A evidência é a versão retornada no host depois da execução. Em frotas, colete esse resultado por servidor e trate qualquer nó sem resposta como pendência, porque um único painel esquecido preserva o caminho para todos os tenants daquele equipamento.
Triagem sem IOC pronto
O patch fecha a condição vulnerável, mas não prova que o servidor nunca foi usado. Como o advisory não fornece IOC, a investigação precisa partir do comportamento confirmado: sessões de contas capazes de gerenciar domínios, adições inesperadas de aliases ou addon domains, arquivos fora do espaço esperado do tenant e qualquer persistência posterior com privilégio de root. Preserve logs e snapshot antes de remover artefatos.
# Inventory accounts on the host
whmapi1 --output=jsonpretty listaccts
# For each relevant account, list every known domain
uapi --output=jsonpretty --user=CPUSER DomainInfo list_domains
# Review recent sessions for the account under investigation
grep 'CPUSER' /usr/local/cpanel/logs/session_log | grep NEW | tail -n 50
# List altered cPanel-managed packages
/usr/local/cpanel/scripts/check_cpanel_pkgs --list-only- Correlacionar sessões recentes com mudanças de domínio solicitadas pelo cliente ou pela equipe
- Comparar aliases, addon domains e document roots atuais com inventário, tickets e backups anteriores
- Revisar novos usuários administrativos, chaves SSH, crons, serviços, web shells e alterações em webroots
- Auditar acessos a bancos, exportações, mudanças de grants e uso de credenciais armazenadas no host
- Rotacionar senhas, tokens e chaves acessíveis ao servidor quando houver sinal de comprometimento
- Expandir a resposta a todos os tenants do host, sem limitar a análise à conta que iniciou o evento
O que testar em painéis de hospedagem
Um pentest de ambiente cPanel não deveria avaliar apenas o site de cada cliente. O painel é o plano de controle e precisa de um objetivo explícito de isolamento multitenant. Com uma conta de menor privilégio fornecida para o teste, verificamos quais funções alteram configuração global, onde nomes de domínio e caminhos chegam ao filesystem, quais processos privilegiados consomem esses dados e se um tenant consegue produzir efeito fora do próprio diretório. Em produção, a confirmação deve usar marcadores inofensivos e parar antes de qualquer tentativa de root.
- Separação entre conta cPanel, reseller, WHM e root
- Autorização para criar parked domains, addon domains, subdomínios e document roots
- Canonicalização de caminhos, symlinks e destinos gravados por processos privilegiados
- Validação de dados antes de chegarem a templates, interpretadores ou chamadas dinâmicas
- Isolamento de filesystem, banco, e-mail, backups e segredos entre tenants
- Logs capazes de atribuir cada mudança de domínio à sessão, conta e origem corretas
- Detecção de criação de arquivo e execução privilegiada originadas por fluxos de autosserviço
A lição para quem contrata pentest
CVE-2026-65643 mostra por que o escopo deve seguir fronteiras de confiança, não apenas URLs. Um portal de hospedagem pode parecer um sistema administrativo auxiliar, mas ele coordena processos privilegiados e concentra o acesso a dezenas de ambientes. Se o teste cobre somente as aplicações publicadas e deixa o painel fora, a principal passagem entre um cliente e todos os outros permanece sem validação.
A ação imediata é objetiva: identificar a linha instalada, aplicar o build corrigido correspondente e confirmar a versão em cada servidor. Depois, revise atividade de domínios e sinais de persistência conforme a exposição real das contas. Para o próximo pentest, trate o cPanel e qualquer outro plano de controle multitenant como ativo de impacto máximo, mesmo quando a exploração começa com uma credencial de privilégio baixo.