A CVE-2026-67401 é uma SQL injection no recurso EmailTrack do cPanel. Uma conta autenticada que possua privilégios relacionados a e-mail pode manipular a consulta, criar arquivo arbitrário e encadear o resultado até execução de código como root. O cPanel publicou builds corrigidos em cada tier suportado e recomenda atualização imediata.
O que aconteceu
O EmailTrack consulta dados de rastreamento de mensagens para contas cPanel. Um parâmetro não era tratado de modo seguro antes de alcançar o banco. Segundo o boletim, o invasor pode abusar da consulta para gravar arquivo controlado e transformar uma conta comum de hospedagem em controle total do servidor.
O requisito de autenticação não torna a falha de baixo risco: credenciais de painel são alvos frequentes de phishing e malware, e uma aplicação comprometida pode revelar tokens ou sessões. Em servidor compartilhado, uma conta contratante também é uma fronteira de confiança; nenhum tenant deve obter capacidade de escrever como root.
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 linha | Afetado / exposto | Corrigido / protegido |
|---|---|---|
| LTS 110 | anterior a 11.110.0.143 | 11.110.0.143+ |
| LTS 134 | anterior a 11.134.0.55 | 11.134.0.55+ |
| Release 136 | anterior a 11.136.0.39 | 11.136.0.39+ |
| Current 138 | anterior a 11.138.0.4 | 11.138.0.4+ |
| WP2 138.1 | anterior a 11.138.1.9 | 11.138.1.9+ |
O atacante precisa de uma conta cPanel válida com permissões de e-mail. Desabilitar shell não bloqueia a cadeia publicada, pois a ação parte da interface/API. Servidores dedicados com um único cliente também continuam vulneráveis se a credencial dessa conta for comprometida.
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 pelo impacto operacional. O registro oficial ainda não apresenta uma nota numérica consolidada, por isso este alerta não inventa um CVSS. A combinação de SQL injection, gravação arbitrária e execução final como root representa comprometimento completo do host e exige a mesma prioridade de um RCE crítico.
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
Compare o build completo do cPanel com o mínimo da sua linha e confira o tier. Depois, revise usuários com acesso ao painel e recursos de e-mail. Não teste a SQL injection: a prova pode gravar dados ou arquivos no servidor.
/usr/local/cpanel/cpanel -V
grep -E '^(CPANEL|RPMUP|SARULESUP|STAGING)=' /etc/cpupdate.conf
/usr/local/cpanel/bin/whmapi1 listaccts want=user,domain,suspended | head -80
tail -n 100 /usr/local/cpanel/logs/access_log
Compare ramo e build, não apenas o número principal. Por exemplo, 11.138.0.3 continua vulnerável e 11.138.0.4 contém a correção indicada. Pacote atualizado mas daemon antigo deve ser reiniciado pelo fluxo oficial. A presença de contas de e-mail aumenta a população capaz de satisfazer a pré-condição.
Como corrigir ou mitigar
Execute o update completo do cPanel para o build corrigido mais recente disponível no tier. Se o ciclo automático estiver bloqueado, descubra e resolva a causa em vez de mudar de tier sem avaliação. Como contenção curta, suspenda contas suspeitas e restrinja acesso ao painel, mas não trate isso como correção.
/usr/local/cpanel/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/scripts/check_cpanel_rpms --fix
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 WHM, login cPanel, webmail, envio, recebimento e rastreamento de mensagens. Revise access_log, error_log, histórico de atualizações, arquivos criados por processos do painel, tarefas root e conexões externas. Se uma conta não confiável teve acesso durante a janela, investigue todo o host e troque credenciais administrativas e de integração.
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
A WebinHost acompanha os tiers, força o upcp quando necessário e valida serviços web, DNS, banco, e-mail e painel após a atualização. Nos planos gerenciados, monitoramento, Imunify360, isolamento CloudLinux/CageFS e regras de firewall diminuem a probabilidade de obter a conta inicial; o build cPanel corrigido continua sendo a proteção determinante para esta CVE.
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.
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.