CVE-2026-41940: Bypass de Autenticação Crítico no cPanel & WHM Permite Acesso Root Sem Senha

Em 28 de abril de 2026, a equipa do cPanel divulgou um boletim de segurança de emergência para uma das vulnerabilidades mais graves já identificadas na história da plataforma. Catalogada como CVE-2026-41940, trata-se de um bypass completo de autenticação que permite a um atacante obter acesso root total ao painel WHM, e por extensão a todos os sites hospedados no servidor, sem necessidade de qualquer senha.

A gravidade é proporcional à escala do problema: o cPanel & WHM gerencia mais de 70 milhões de domínios em todo o mundo, sendo o painel de controlo de hospedagem mais amplamente utilizado por provedores de hosting compartilhado, revendedores e empresas. A vulnerabilidade afeta todas as versões suportadas do software (e inclusive versões fora de suporte a partir da 11.40), e a exploração ativa foi confirmada no mundo real antes mesmo da publicação do patch, configurando um zero-day legítimo.

A pesquisa técnica completa foi publicada pela watchTowr Labs. A confirmação de exploração em ambiente real veio da KnownHost, um dos maiores provedores de hospedagem gerenciada dos Estados Unidos. A cobertura jornalística incluiu BleepingComputer, The Hacker News e a Namecheap, que chegou a bloquear temporariamente as portas TCP 2083 e 2087 em toda a sua rede para proteger os seus clientes antes de o patch estar disponível.

Este artigo do Blog Dolutech apresenta uma análise técnica detalhada do mecanismo de exploração, as medidas de mitigação necessárias, indicadores de comprometimento e as lições que administradores de servidores devem extrair deste incidente.

O Que é o cPanel & WHM e Por Que Esta Falha é Tão Grave

Para contextualizar a gravidade desta vulnerabilidade, é essencial compreender o que o cPanel e o WHM representam na infraestrutura web global.

O WHM (Web Host Manager) é a interface administrativa de nível root. Através dele, o administrador do servidor gere certificados SSL, contas de hospedagem, configurações de segurança, serviços de DNS e toda a infraestrutura do sistema operativo Linux subjacente. Quem tem acesso ao WHM tem, literalmente, as chaves do reino: pode criar e remover contas, aceder a todos os ficheiros de todos os sites, executar comandos como root e alterar qualquer configuração do servidor.

O cPanel é a interface voltada ao utilizador final, ou seja, o proprietário de um site individual. Através dele, o utilizador gere ficheiros, bases de dados, e-mail, domínios e subdomínios associados à sua conta de hospedagem.

A combinação de ambos os painéis está presente numa porção significativa dos servidores de hospedagem web em todo o mundo. Quando a segurança do WHM é comprometida, todos os sites e contas no servidor ficam expostos. Um atacante com acesso root pode inserir backdoors e web shells, redirecionar utilizadores para páginas maliciosas, roubar credenciais armazenadas em ficheiros de configuração (como wp-config.php de instalações WordPress), enviar spam ou phishing através das contas de e-mail, e utilizar o servidor comprometido como ponto de partida para ataques adicionais contra outros alvos.

Visão Geral da CVE-2026-41940

A CVE-2026-41940 recebeu uma pontuação CVSS de 9.8 (Crítica) atribuída pela VulnCheck, enquanto algumas fontes reportam 9.3 com base em vetores ligeiramente diferentes. Em qualquer dos casos, trata-se de uma vulnerabilidade de severidade máxima. É classificada como um bypass de autenticação remoto que não requer qualquer credencial válida, não necessita de interação do utilizador e concede acesso root completo ao servidor.

Segundo o boletim oficial do cPanel, a falha afeta o mecanismo de “session loading and saving”, que é o fluxo responsável por determinar se um utilizador está ou não autenticado. Todas as versões do cPanel & WHM posteriores à 11.40 estão vulneráveis, o que abrange essencialmente todas as instalações existentes no mundo.

Análise Técnica Detalhada do Exploit

A análise técnica completa foi realizada pela watchTowr Labs através da comparação (diff) entre as versões 11.110.0.96 (vulnerável) e 11.110.0.97 (corrigida). Três ficheiros Perl foram modificados no patch: Cpanel/Session.pm (responsável por salvar sessões), Cpanel/Session/Load.pm (responsável por carregar sessões) e Cpanel/Session/Encoder.pm (que recebeu novas primitivas de codificação hexadecimal).

O exploit envolve três fases sequenciais que exploram a interação entre ficheiros de sessão em texto plano, um cache JSON paralelo e a ausência de sanitização adequada de caracteres CRLF no fluxo de autenticação Basic.

Fase 1: Criação de uma Sessão Preauth

O primeiro passo é trivial. O atacante envia um pedido de login com credenciais deliberadamente incorretas para a porta 2087 (WHM):

POST /login/?login_only=1 HTTP/1.1
Host: target:2087
Content-Type: application/x-www-form-urlencoded

user=root&pass=wrong

O servidor cpsrvd responde com um código HTTP 401 e define um cookie de sessão no cabeçalho Set-Cookie. Ao descodificar o URL do cookie, obtém-se um valor como :QSJN_sFdKZtCi2o_,4d257abc371539dfebdf7d3a3e64de0b. A parte antes da vírgula (:QSJN_sFdKZtCi2o_) é o nome da sessão e é usada como nome do ficheiro em disco. Os 32 caracteres hexadecimais após a vírgula constituem o segredo <ob>, utilizado internamente pelo Cpanel::Session::Encoder para codificar o campo de password no ficheiro de sessão, evitando que fique em texto claro.

Mesmo com o login falhado, o servidor cria um ficheiro de sessão “preauth” no caminho /var/cpanel/sessions/raw/<nome_sessão>. Este comportamento é intencional, pois o cPanel usa ficheiros de sessão como máquina de estados entre pedidos HTTP. O ficheiro preauth contém campos como needs_auth=1, tfa_verified=0, um token de segurança pré-atribuído (cp_security_token), o endereço IP de origem e outros metadados.

Fase 2: Injeção CRLF via Cabeçalho Authorization

A segunda fase é o coração do exploit e explora duas falhas distintas que se combinam de forma devastadora.

O atacante constrói um pedido HTTP com um cabeçalho Authorization: Basic cujo conteúdo, após descodificação Base64, contém root:<payload>. O payload na parte da password inclui bytes \r\n (CRLF, ou seja, carriage return seguido de line feed) que, ao serem escritos no ficheiro de sessão, criam novas linhas e, consequentemente, novos registos de nível superior.

Primeira falha: ausência de sanitização de CRLF. A função set_pass do cpsrvd, que processa a password recebida do cabeçalho Basic, apenas remove bytes nulos (\0). Não filtra \r nem \n. Existia uma função chamada filter_sessiondata que fazia essa sanitização, mas ela não era chamada neste fluxo específico. Cada chamador da função saveSession era individualmente responsável por invocar filter_sessiondata, e o código de autenticação Basic simplesmente não o fazia.

Segunda falha: bypass da codificação de password. Ao enviar o cookie de sessão sem a parte <ob> (ou seja, omitindo a vírgula e os 32 caracteres hexadecimais, enviando apenas %3aQSJN_sFdKZtCi2o_), a variável $ob fica vazia dentro da função saveSession. Quando $ob é vazio, o codificador (Cpanel::Session::Encoder) não é instanciado e a password é escrita no ficheiro de sessão em texto plano, exatamente como recebida. Importante: o nome do ficheiro de sessão em disco é resolvido da mesma forma com ou sem a parte <ob>, pois a função get_ob_part remove a cauda antes de resolver o caminho. Portanto, o ficheiro de destino é o mesmo.

O payload completo da password fica, por exemplo:

x\r\nhasroot=1\r\ntfa_verified=1\r\nuser=root\r\ncp_security_token=/cpsess9999999999\r\nsuccessful_internal_auth_with_timestamp=1777462149

O primeiro byte (x) é armazenado como valor legítimo do campo pass=. Todos os \r\n subsequentes são interpretados pelo formato key=value do ficheiro de sessão como separadores de linha, criando novos registos de nível superior: hasroot=1, tfa_verified=1, user=root e successful_internal_auth_with_timestamp=1777462149.

Contudo, existe um obstáculo nesta fase. O cPanel mantém dois ficheiros por sessão: o ficheiro de texto em /var/cpanel/sessions/raw/<id> e um cache JSON em /var/cpanel/sessions/cache/<id>. A função saveSession escreve ambos simultaneamente: o ficheiro de texto (linha a linha, key=value\n) e o cache JSON (serialização do hash em memória via Cpanel::AdminBin::Serializer::Dump). No hash em memória, a injeção CRLF está contida dentro de uma única string no campo pass, porque o hash foi preenchido antes da escrita em disco. Quando o JSON é gerado, os \r\n ficam escapados como caracteres internos da string pass.

A função loadSession, invocada em cada pedido subsequente, prefere o cache JSON. Portanto, ao carregar a sessão, ela vê a injeção empacotada dentro do valor pass e não como chaves separadas de nível superior. O exploit ainda não está completo.

Fase 3: Promoção dos Campos Injetados via do_token_denied

Para ultrapassar a barreira do cache JSON, o atacante precisa forçar o servidor a reler o ficheiro de sessão em texto plano (onde os campos injetados existem como linhas separadas) e reescrever o cache JSON a partir desse conteúdo já corrompido.

A solução está na classe Cpanel::Session::Modify. A função Modify::new lê o ficheiro de sessão em texto com a opção nocache => 1, ignorando completamente o cache JSON e fazendo parse direto do ficheiro key=value. Neste parse, cada linha do ficheiro (incluindo as linhas injetadas) é interpretada como uma chave de nível superior. A função Modify::save invoca write_session, que reescreve tanto o ficheiro de texto quanto o cache JSON a partir do hash resultante. Desta vez, o cache JSON conterá hasroot, tfa_verified e successful_internal_auth_with_timestamp como campos de nível superior.

O atacante dispara este fluxo simplesmente enviando um pedido HTTP a qualquer URL sem incluir o token de segurança cp_security_token no caminho:

GET /scripts2/listaccts HTTP/1.1
Host: target:2087
Cookie: whostmgrsession=%3aQSJN_sFdKZtCi2o_

Quando o cpsrvd recebe um pedido sem token de segurança, a função check_security_token detecta a ausência e chama do_token_denied. Esta função cria um objecto Cpanel::Session::Modify (invocando new, que lê o ficheiro raw) e chama save() (que reescreve o cache). O servidor responde com HTTP 401 “Token Denied”, mas o efeito colateral desejado já foi alcançado: o cache JSON foi reescrito com os campos injetados promovidos a nível superior.

Resultado Final: Acesso Root Sem Senha

A partir deste momento, qualquer pedido que carregue esta sessão verá successful_internal_auth_with_timestamp definido no hash de sessão. A função docheckpass_whostmgrd, que é executada em cada pedido para revalidar a autenticação, verifica este campo antes de consultar /etc/shadow para validar a password. Se successful_internal_auth_with_timestamp estiver definido, a função retorna AUTH_OK imediatamente sem verificar qualquer password.

O atacante pode então aceder a qualquer endpoint do WHM como root:

GET /cpsessXXXXXXXXXX/json-api/version HTTP/1.1
Host: target:2087
Cookie: whostmgrsession=%3aQSJN_sFdKZtCi2o_

E recebe uma resposta HTTP 200 com os dados solicitados. Pode igualmente abrir uma shell root interativa via WebSocket em /websocket/Shell, obter controlo total sobre todas as contas de hospedagem, e executar qualquer comando no servidor com privilégios de superutilizador.

Em resumo, três pedidos HTTP sequenciais são suficientes para transformar um servidor cPanel completamente protegido por senha num servidor com acesso root aberto a qualquer atacante na Internet.

Exploração Confirmada no Mundo Real

A KnownHost confirmou publicamente nos seus fóruns comunitários que a vulnerabilidade foi explorada como zero-day antes de qualquer patch estar disponível. A empresa tomou a decisão imediata de bloquear as portas 2082, 2083, 2086, 2087, 2095, 2096, 2077 e 2078 em toda a sua rede, interrompendo temporariamente o acesso de todos os clientes aos painéis de controlo até que o patch pudesse ser aplicado em milhares de máquinas.

De acordo com o staff da KnownHost, de entre a sua rede de milhares de servidores, aproximadamente 30 mostraram sinais de tentativas de acesso exploratório. Na maioria dos casos, o comportamento observado foi de teste de conceito: o atacante validava que o acesso root funcionava consultando endpoints como /json-api/myprivs e /json-api/version, sem necessariamente instalar payloads adicionais. No entanto, em alguns casos foi observada a abertura de uma shell root via WebSocket (/websocket/Shell). A KnownHost enfatizou que não encontrou sinais de comprometimento ativo, payloads injetados ou backdoors instaladas nos servidores afetados.

A Namecheap, um dos maiores registadores de domínios e provedores de hosting do mundo, bloqueou igualmente as portas 2083 e 2087 de forma proativa antes da disponibilização do patch. A empresa publicou um status update público informando os clientes sobre a situação e restaurou o acesso somente após aplicar o patch, o que foi concluído em 29 de abril de 2026 às 02:42 UTC.

A KnownHost partilhou ainda exemplos concretos de logs que indicam exploração bem-sucedida, mostrando uma sequência característica: um GET /login/ com resposta 401, seguido de um GET /json-api/loadavg com resposta 403 (o passo de injeção/promoção), seguido de pedidos a endpoints como /cpsessXXXX/json-api/myprivs e /cpsessXXXX/json-api/version com resposta 200 (confirmando acesso root), e em alguns casos o acesso à shell WebSocket. O user-agent python-requests/2.28.1 foi identificado nas primeiras ondas de exploração.

Versões Afetadas e Patches Disponíveis

A vulnerabilidade afeta todas as versões do cPanel & WHM posteriores à 11.40, o que abrange essencialmente todas as instalações existentes, tanto as versões atualmente suportadas quanto as que já se encontram fora de suporte (End of Life).

O cPanel publicou patches de emergência para as seguintes versões suportadas: 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.130.0.18, 11.132.0.29, 11.134.0.20 e 11.136.0.5. Para o produto WP Squared, a versão corrigida é a 136.1.7.

Servidores que estejam em versões fora de suporte não recebem patch automático. O cPanel informou que está a trabalhar para disponibilizar correções para versões antigas com maior número de instalações, mas até lá recomenda vivamente a atualização para uma versão suportada ou a aplicação das medidas de mitigação temporárias descritas abaixo.

O Que a Correção Técnica Alterou

A análise do diff entre as versões vulnerável e corrigida revela três alterações fundamentais.

Centralização da sanitização CRLF. A função filter_sessiondata, que já existia e é responsável por remover caracteres \r, \n, = e \ dos campos de sessão, foi movida para dentro da própria função saveSession. Anteriormente, a responsabilidade de invocar filter_sessiondata recaía sobre cada chamador individual, e o fluxo de autenticação Basic no cpsrvd não o fazia. Agora, independentemente de quem chame saveSession, a sanitização é sempre aplicada.

Codificação obrigatória da password. Foi adicionada uma verificação explícita if (defined $ob && length $ob) antes de utilizar o codificador. Quando $ob está presente, o codificador original é usado. Quando $ob está ausente, um novo caminho alternativo aplica codificação hexadecimal (hex_encode_only) precedida do prefixo no-ob:. Isto impede que a password seja alguma vez escrita em texto plano no ficheiro de sessão, eliminando a possibilidade de CRLF sobreviver no disco.

Novas primitivas de codificação. O módulo Cpanel::Session::Encoder recebeu funções de round-trip hexadecimal que garantem a codificação segura independentemente do estado do segredo <ob>.

Indicadores de Comprometimento e Detecção

A watchTowr Labs publicou um Detection Artifact Generator no GitHub para auxiliar administradores na verificação de exposição. O repositório está disponível em:

https://github.com/watchtowrlabs/watchTowr-vs-cPanel-WHM-AuthBypass-to-RCE.py

Para detecção manual, os administradores devem verificar os seguintes ficheiros e padrões:

Logs de acesso do WHM/cPanel (tipicamente em /usr/local/cpanel/logs/access_log): procurar sequências de pedidos do mesmo endereço IP que incluam um GET /login/ com resposta 401, seguido de pedidos a /json-api/loadavg com 403, e depois acessos a /json-api/myprivs, /json-api/version ou /websocket/Shell com resposta 200. O user-agent python-requests/2.28.1 foi observado, embora atacantes sofisticados possam alterar este valor.

Ficheiros de sessão em /var/cpanel/sessions/raw/: procurar ficheiros que contenham campos como hasroot=1 ou successful_internal_auth_with_timestamp que não correspondam a logins legítimos documentados nos logs de autenticação.

Logs de sessão (session_log): correlacionar sessões root com horários e IPs conhecidos dos administradores legítimos. Qualquer sessão root proveniente de um IP desconhecido deve ser investigada.

Mitigação: Ações Imediatas

Passo 1: Aplicar o patch. Executar o seguinte comando no servidor:

/scripts/upcp --force

Após a conclusão, verificar a versão instalada e reiniciar o serviço:

/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd

Passo 2: Verificar configurações de atualização. Se o servidor tem atualizações automáticas desativadas ou a versão fixada (pinned) a uma release específica, o patch de emergência não será aplicado automaticamente. Estes servidores devem ser identificados e atualizados manualmente com prioridade máxima.

Passo 3: Mitigação temporária (quando o patch não pode ser aplicado). Existem duas alternativas. A primeira é bloquear o tráfego de entrada nas portas 2083, 2087, 2095 e 2096 ao nível da firewall. A segunda é desativar completamente os serviços cpsrvd e cpdavd:

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0
whmapi1 configureservice service=cpdavd enabled=0 monitored=0
/scripts/restartsrv_cpsrvd --stop
/scripts/restartsrv_cpdavd --stop

Passo 4: Auditoria pós-incidente. Mesmo após a aplicação do patch, os administradores devem realizar uma auditoria completa que inclua: revisão dos logs de acesso e sessão para identificar acessos não autorizados; verificação de todas as contas cPanel para detectar backdoors, web shells ou ficheiros não reconhecidos; inspeção de cron jobs, chaves SSH autorizadas e utilizadores do sistema em busca de adições não autorizadas; revisão de ficheiros de configuração de aplicações (como wp-config.php) para verificar se não foram alterados; e verificação de que não existem contas cPanel ou revendedor criadas pelo atacante.

Passo 5: Rotação de credenciais. Se houver qualquer indício de comprometimento, devem ser rotacionadas todas as passwords de root, contas cPanel, credenciais de bases de dados e chaves de API armazenadas no servidor.

Lições Para Administradores

Este incidente oferece lições valiosas que vão além da aplicação de um patch específico.

Não exponha interfaces administrativas à Internet pública. As portas WHM (2087) e cPanel (2083) não devem estar acessíveis a partir de qualquer endereço IP. O acesso deve ser restrito por firewall a IPs específicos de administradores ou, preferencialmente, disponibilizado apenas através de uma VPN. Se a KnownHost e a Namecheap não tivessem bloqueado proativamente estas portas, o impacto nos seus clientes teria sido significativamente maior.

Monitore sessões e acessos anómalos. Sistemas de detecção de intrusão (IDS) e logs centralizados permitem identificar rapidamente padrões de acesso incomuns, como sessões root provenientes de IPs desconhecidos ou acessos a endpoints de API em horários atípicos.

Mantenha atualizações automáticas ativas. Servidores com atualizações do cPanel desativadas ou fixadas em versões específicas não receberam o patch de emergência automaticamente, permanecendo vulneráveis por mais tempo.

Implemente defesa em profundidade. WAFs (Web Application Firewalls) com regras de detecção de injeção de cabeçalhos, sistemas de monitorização de integridade de ficheiros e alertas sobre criação de novas contas ou sessões root podem fornecer camadas adicionais de proteção mesmo perante vulnerabilidades zero-day.

Tenha um plano de resposta a incidentes. A rapidez com que a KnownHost e a Namecheap reagiram, bloqueando portas em toda a rede em questão de minutos, foi crucial para minimizar o impacto. Organizações que não tinham um plano similar ficaram expostas durante horas até o patch ser disponibilizado e aplicado.

Impacto Global e Perspetiva

Com mais de 70 milhões de domínios sob gestão do cPanel & WHM, esta é uma das vulnerabilidades de maior alcance potencial dos últimos anos na infraestrutura web. A combinação de três fatores torna-a especialmente perigosa: a exploração é trivial (três pedidos HTTP sem credenciais), o impacto é máximo (acesso root total) e a superfície de ataque é imensa (todas as versões desde a 11.40).

A VulnCheck atribuiu o identificador CVE-2026-41940 com CVSS 9.8, e é provável que a CISA adicione esta vulnerabilidade ao seu catálogo KEV (Known Exploited Vulnerabilities) nos próximos dias, dada a confirmação de exploração ativa.

Administradores de servidores que utilizem cPanel & WHM em qualquer versão devem tratar esta atualização como prioridade absoluta e imediata.

Referências

1. cPanel Security Bulletin (Oficial): https://support.cpanel.net/hc/en-us/articles/40073787579671-Critical-Vulnerability-with-cPanel-WHM-Login-Authentication
2. watchTowr Labs (Análise Técnica Completa): https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/
3. watchTowr Detection Artifact Generator (GitHub): https://github.com/watchtowrlabs/watchTowr-vs-cPanel-WHM-AuthBypass-to-RCE.py
4. BleepingComputer: https://www.bleepingcomputer.com/news/security/cpanel-whm-emergency-update-fixes-critical-auth-bypass-bug/
5. The Hacker News: https://thehackernews.com/2026/04/critical-cpanel-authentication.html
6. VulnCheck Advisory: https://vulncheck.com/advisories/cpanel-and-whm-authentication-bypass-via-login-flow
7. NVD (CVE-2026-41940): https://nvd.nist.gov/vuln/detail/CVE-2026-41940
8. KnownHost Community Forum (Confirmação de Exploração Zero-Day): https://www.knownhost.com/forums/threads/cpanel-zero-day-exploit-network-wide-protections-in-place-for-cpanel-and-whm-logins-ports.6599/
9. Namecheap Status Update: https://www.namecheap.com/status-updates/ongoing-critical-security-vulnerability-in-cpanel-april-28-2026/