CVE-2026-93697: XSS persistente no WHM Mass Modify Accounts pode abusar da sessão do administrador

cPanel & WHM Risco Alto

CVE-2026-93697: XSS persistente no WHM Mass Modify Accounts pode abusar da sessão do administrador

Uma conta cPanel sem privilégios administrativos pode armazenar script que executa na sessão de um administrador ao usar Mass Modify Accounts no WHM. Builds corrigidos foram publicados para todas as linhas suportadas.

Revisado em 30/09/2026 Leitura técnica
CVE-2026-93697
SeveridadeAlto
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 WebinHostAtualização disponível; priorizar hosts com contas não confiáveis e uso do WHM

A CVE-2026-93697 é um XSS persistente na interface Mass Modify Accounts do WHM. Segundo o cPanel, um titular de conta sem privilégio administrativo pode fazer um script executar no contexto da sessão de um administrador WHM. Com os direitos dessa sessão, o script pode realizar ações administrativas e comprometer o servidor.

O que aconteceu

Em um XSS persistente, conteúdo controlado por um usuário é armazenado e posteriormente exibido sem proteção suficiente em uma página de outro usuário. Neste caso, a fronteira atravessada é a conta comum para a sessão privilegiada do WHM. O boletim identifica a interface Mass Modify Accounts como local afetado, mas não divulga o campo exato, o payload nem uma cadeia pronta de exploração.

A expressão “execução de código” do título técnico do fornecedor deve ser entendida no contexto da sessão do administrador: trata-se inicialmente de script no navegador/WHM. O boletim não afirma execução direta de comandos root pelo simples armazenamento do dado. Ainda assim, uma sessão WHM comprometida pode alterar contas e configurações e eventualmente acessar funções de alto privilégio, conforme as permissões do administrador que abriu a página.

Não é necessário que o administrador aceite uma solicitação de suporte de origem suspeita para existir risco; abrir a interface de gerenciamento em um ambiente com dados maliciosos pode acionar o script. O patch do fornecedor é o controle que neutraliza a exibição insegura.

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

A cadeia divulgada envolve uma conta cPanel não privilegiada capaz de armazenar dados processados pela interface e uma sessão de administrador WHM que visualize a página afetada. A gravidade operacional depende das permissões efetivas dessa sessão. Desabilitar shell, alterar o navegador ou contar apenas com WAF não corrige o tratamento da saída dentro do WHM.

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

Alto; CVSS ainda não publicado nas bases consultadas em 30/09/2026. Há possibilidade de ações administrativas usando a identidade de quem visualiza a interface. Em hospedagem compartilhada, uma conta hostil pode atingir operadores de alto privilégio e, por consequência, outras contas. Diferentemente da CVE-2026-93698, este boletim descreve XSS na sessão WHM e não confirma execução direta como root sem interação do administrador.

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 do seu ramo. Revise quem tem acesso WHM e se a interface Mass Modify Accounts foi usada no período de exposição. Não abra campos de conta suspeitos em um WHM vulnerável para investigar o payload; preserve evidências e faça a análise depois de atualizar.

/usr/local/cpanel/cpanel -V
grep -E '^(CPANEL|RPMUP|STAGING)=' /etc/cpupdate.conf
grep -Ei 'mass.modify|massmodify|modifyacct' /usr/local/cpanel/logs/access_log 2>/dev/null | tail -50
/usr/local/cpanel/scripts/check_cpanel_rpms --list-only

Build inferior ao mínimo da mesma linha precisa de atualização. A ausência de ocorrência no access_log não prova que não houve acesso: rotação, retenção e nomes de rota podem variar. Logs podem conter informações sensíveis em URLs; restrinja e redija dados antes de compartilhá-los.

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

Atualize o cPanel/WHM para o build corrigido da sua linha. Durante a janela até o patch, restrinja o uso da interface vulnerável por administradores e mantenha sessões privilegiadas protegidas; isso reduz exposição temporária, mas não corrige o XSS. Use o upcp oficial e resolva falhas de repositório ou espaço em disco antes de encerrar a manutenção.

/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, listagem e modificação de contas, revendedores e interfaces relacionadas. Revise ações administrativas fora do padrão, mudanças de senha, suspensões, privilégios de revendedor, DNS e configurações de segurança. Se houver sinal de sessão abusada, revogue sessões, rotacione credenciais e investigue as alterações antes de restaurar a operação normal.

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

Em servidores gerenciados, a WebinHost acompanha os builds corrigidos, aplica o update e valida WHM e contas após a mudança. A equipe pode restringir o uso da interface afetada durante a janela e revisar ações administrativas suspeitas. Imunify360 protege aplicações dos clientes e CloudLinux/CageFS oferece isolamento de processos; a falha ocorre no painel WHM e exige o build corrigido do cPanel.

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.