CVE-2026-93698 no Multilang Adminbin do cPanel permite execução de comandos como root

cPanel & WHM Risco Crítico

CVE-2026-93698 no Multilang Adminbin do cPanel permite execução de comandos como root

Validação insuficiente no Multilang Adminbin permite executar comandos como root e controlar todo o servidor. O cPanel corrigiu todas as linhas suportadas nos builds de 29 de setembro.

Revisado em 30/09/2026 Leitura técnica
CVE-2026-93698
SeveridadeCrítico
Versões afetadasTodas as linhas suportadas do cPanel/WHM anteriores a 11.110.0.148, 11.134.0.61, 11.136.0.45, 11.138.0.11 ou WP2 11.138.1.13, conforme o ramo instalado
Versões corrigidas11.110.0.148+, 11.134.0.61+, 11.136.0.45+, 11.138.0.11+ ou WP2 11.138.1.13+
Status WebinHostBuilds corrigidos disponíveis; atualização prioritária em servidores compartilhados

A CVE-2026-93698 é uma falha de validação no Multilang Adminbin do cPanel/WHM. O boletim oficial informa que ela permite a execução de comandos arbitrários com privilégios root. O resultado possível é controle integral do servidor, incluindo todas as contas, aplicações, bancos de dados e e-mails hospedados. Instale o build corrigido da sua linha sem esperar pelo ciclo normal de manutenção.

O que aconteceu

Um adminbin é um componente do painel que executa operações administrativas para funcionalidades específicas. No Multilang Adminbin, os dados usados para formar uma operação não eram validados suficientemente. O cPanel confirma que essa deficiência pode permitir a execução de comandos arbitrários e que a exploração bem-sucedida termina no usuário root.

O fornecedor não divulgou o parâmetro, a sequência de chamadas nem os privilégios iniciais necessários. Por isso, não é correto afirmar que a falha seja explorável sem autenticação ou que uma configuração isolada a bloqueie. A avaliação defensiva deve usar o intervalo de versões publicado e não tentar provar vulnerabilidade em produção com payloads que poderiam executar comandos privilegiados.

Em hospedagem compartilhada, root ultrapassa todas as fronteiras entre contas. O invasor poderia ler dados e backups, substituir binários, alterar tarefas agendadas, criar usuários, instalar persistência e afetar sites de outros clientes. A atualização fecha o caminho conhecido, mas não desfaz alterações que tenham ocorrido antes.

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
cPanel/WHM 11.110anterior a 11.110.0.14811.110.0.148 ou posterior
cPanel/WHM 11.134anterior a 11.134.0.6111.134.0.61 ou posterior
cPanel/WHM 11.136anterior a 11.136.0.4511.136.0.45 ou posterior
cPanel/WHM 11.138anterior a 11.138.0.1111.138.0.11 ou posterior
cPanel/WHM WP2 11.138.1anterior a 11.138.1.1311.138.1.13 ou posterior

O escopo oficial é “todas as versões suportadas” anteriores aos respectivos builds. O cPanel não condiciona a recomendação de atualização a uma configuração do recurso multilíngue, à presença de shell SSH ou a uma opção do WHM. A ausência de detalhes técnicos públicos impede concluir que desativar uma interface seja mitigação suficiente.

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 root; CVSS ainda não publicado nas bases consultadas em 30/09/2026. O resultado documentado é execução de comandos como root e controle total do host. Embora o boletim não especifique a condição inicial de acesso nem uma nota numérica, a consequência para um servidor multi-tenant exige aplicação emergencial dos builds corretivos e revisão de indicadores de comprometimento.

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

Identifique o ramo e o build completos do cPanel em execução e compare com a tabela. Confirme a política de atualização e possíveis bloqueios do upcp. A existência de um pacote recém-instalado não prova que os processos do painel já executam o código novo; conclua a atualização e valide os serviços.

/usr/local/cpanel/cpanel -V
grep -E '^(CPANEL|RPMUP|STAGING)=' /etc/cpupdate.conf
/usr/local/cpanel/scripts/check_cpanel_rpms --list-only
ps -eo pid,lstart,user,cmd | grep -E '[c]psrvd|[w]hmsrv' | head -20

Compare o build dentro da mesma linha: 11.138.0.10 está abaixo do mínimo, enquanto 11.138.0.11 contém a correção publicada. Em WP2, o mínimo é 11.138.1.13; não compare esse sufixo com o ramo 11.138.0. Se o upcp falhou ou o servidor usa linha sem manutenção, corrija o bloqueio ou planeje migração para uma linha suportada.

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

Execute o atualizador oficial do cPanel/WHM e confirme um dos builds mínimos ou versão posterior. Faça backup restaurável antes da mudança, garanta acesso administrativo alternativo e reserve uma janela para validar serviços. Reduzir o acesso ao painel ou ao recurso pode diminuir superfície durante a manutenção, mas não é correção confirmada pelo fornecedor.

/usr/local/cpanel/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/scripts/check_cpanel_rpms --list-only

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 login WHM/cPanel, contas, interface multilíngue, sites, DNS e correio após o update. Investigue processos privilegiados anormais, alterações em sudoers, systemd e cron, novas chaves SSH, usuários UID 0, módulos e arquivos recentes fora do padrão. Preserve logs do cPanel e do sistema se houver evidência de execução suspeita; faça rotação de credenciais a partir de ambiente confiável e considere reconstrução do host se root tiver sido comprometido.

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 cPanel cobertos por gerenciamento contratado, a WebinHost prioriza os builds do fornecedor, verifica o resultado do upcp e testa os serviços após a manutenção. Imunify360 acrescenta proteção de aplicação e varredura de malware; CloudLinux/CageFS limita atividades de contas em condições normais; KernelCare corrige falhas de kernel quando existe livepatch. Esta CVE está no painel, portanto nenhuma dessas camadas comprova correção sem o build cPanel atualizado.

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.