A vulnerabilidade que derrubou a internet: cPanel atacado em 24 horas

Em 28 de abril de 2026, a WebPros — empresa suíça que mantém o cPanel — publicou um alerta de segurança que deveria ter feito qualquer administrador de servidores parar tudo. A vulnerabilidade CVE-2026-41940, um bypass de autenticação com score CVSS 9.8, afetava todas as versões suportadas do cPanel e WHM. Em menos de 48 horas, milhares de servidores já estavam comprometidos. O Shodan contabilizava 1,4 milhão de instâncias publicamente expostas. Para o Brasil, onde o cPanel domina o mercado de hospedagem compartilhada, o impacto é particularmente grave.

O que é o CVE-2026-41940 e por que ele é tão perigoso

O CVE-2026-41940 é uma falha de missing authentication for critical function (CWE-306) no fluxo de login do cPanel. Em termos práticos: um atacante sem credenciais consegue acessar o painel como root, o usuário de maiores privilégios no sistema.

A técnica usada é uma injeção CRLF (Carriage Return Line Feed) no processamento de senhas via Basic Auth. Quando uma tentativa de login falha, o cPanel cria um arquivo de sessão temporário no servidor. O atacante envia uma requisição GET com o usuário “root” e uma senha especialmente construída com caracteres \r e \n codificados em base64. Esses caracteres não são sanitizados pelo servidor.

O resultado é que valores como hasroot=1, tfa_verified=1 e successful_internal_auth_with_timestamp são escritos diretamente no arquivo de sessão. Quando o servidor interpreta esses valores, assume que a autenticação interna já ocorreu — e libera acesso total sem verificar a senha em /etc/shadow.

A NVD (National Vulnerability Database) classificou o bug como crítico, com CVSS 3.1 score de 9.8. A CISA adicionou ao KEV Catalog em 30 de abril de 2026, com prazo de correção de apenas 3 dias — um sinal claro da gravidade.

O ransomware Sorry: criptografia em 48 horas

O grupo que se autodenomina “Sorry” foi o primeiro a capitalizar a falha. Segundo análise detalhada da ThreatLocker, o ransomware foi deployado em menos de 48 horas após a divulgação do patch.

O binário é escrito em Golang e tem como alvo servidores Linux. Ele criptografa arquivos e adiciona a extensão .sorry. A nota de resgate — README.md — direciona as vítimas para um chat no protocolo Tox para negociações. Curiosamente, o grupo também sugere que as vítimas procurem empresas de recuperação de dados no Taobao, marketplace do Alibaba.

A Censys, empresa de inteligência de ameaças, contabilizou 8.859 hosts expondo arquivos com a extensão .sorry em diretórios abertos — sendo que 7.135 deles rodavam cPanel ou WHM. Esses diretórios simplesmente não existiam no dia anterior. A escala da exploração automatizada é brutal.

Múltiplos atores de ameaça, um único ponto de falha

O CVE-2026-41940 não atraiu apenas ransomware. A HelpNetSecurity relata que múltiplos grupos de ameaças exploraram a falha simultaneamente, cada um com objetivos diferentes:

  • Ransomware Sorry: criptografia em massa de servidores Linux, operação automatizada e oportunista.
  • Mirai Nuclear.x86: botnet DDoS usando servidores comprometidos como nós de ataque. O malware não explora o cPanel diretamente, mas é deployado após o comprometimento inicial.
  • Cyberespionagem: a Ctrl-Alt-Intel identificou campanhas direcionadas contra governos e militares do Sudeste Asiático, incluindo Filipinas, Indonésia e Laos. O mesmo grupo já havia exfiltrado documentos do setor ferroviário chinês em operações anteriores.

A Shadowserver Foundation registrou 44.000 IPs associados a servidores comprometidos no pico dos ataques. Esse número caiu para 3.540 após alguns dias — indicando que o patching avançou, mas milhares de servidores permanecem vulneráveis.

Um administrador de TI relatou que, após o comprometimento, o malware instalou webshells como mecanismo de persistência, roubou credenciais de carteiras de criptomoedas, chaves da AWS e Stripe, além de tentar adicionar senhas hardcoded a todos os bancos MySQL.

Como funciona o exploit: anatomia técnica

O ataque acontece em três estágios, conforme documentado pela ThreatLocker:

  1. Captura do cookie de sessão: o atacante faz um login com credenciais inexistentes. O cPanel cria um arquivo de sessão pré-autenticação e retorna o nome da sessão como cookie. Isso é comportamento padrão de servidores web.
  2. Injeção CRLF: uma requisição GET é enviada com o campo de senha contendo os caracteres \r\n e valores maliciosos como hasroot=1 e tfa_verified=1. Como o cPanel não sanitiza esses caracteres no processamento de Basic Auth, os valores são gravados no arquivo de sessão dentro do campo “pass”.
  3. Ativação dos valores injetados: uma segunda requisição com um security token ausente força o servidor a reler o arquivo de sessão, parseando os caracteres CRLF e transformando os valores injetados em entradas JSON válidas. Com successful_internal_auth_with_timestamp presente, o servidor pula a verificação contra /etc/shadow — e o atacante tem acesso root.

O mais impressionante é que o ataque começa com zero acesso prévio. Um único campo de entrada não sanitizado, combinado com fluxos de código legítimos do próprio cPanel, resulta em controle total do servidor.

Por que o Brasil está na linha de frente

O cPanel é o painel de controle mais usado em hospedagens brasileiras. Grande parte das pequenas e médias empresas de hosting no país oferece cPanel como padrão. Isso significa que milhares de servidores com sites de comércio eletrônico, blogs, portais de prefeituras e sistemas governamentais estão potencialmente expostos.

O problema é agravado por três fatores específicos do mercado brasileiro:

  • Janela de patching longa: muitas hospedagens brasileiras ainda rodam versões antigas do cPanel por incompatibilidade com customizações ou simples falta de processo de atualização.
  • Exposição pública massiva: o modelo de hospedagem compartilhada brasileiro frequentemente mantém portas de administração (2082, 2083, 2086, 2087) acessíveis publicamente.
  • Falta de monitoramento: a maioria das pequenas hospedagens não tem SIEM, nem detecção de comportamento anômalo no painel.

A falha afeta todas as versões do cPanel após a 11.40 — lançada em março de 2014. Ou seja, mais de uma década de software vulnerável.

Como se proteger: o que fazer agora

Se você administra servidores com cPanel, as ações são urgentes e não negociáveis:

  1. Atualize imediatamente. Os patches foram lançados em 28 de abril de 2026 para todas as versões suportadas. Verifique as versões corrigidas no advisory oficial do cPanel.
  2. Restrinja o acesso ao painel. Bloqueie as portas 2082, 2083, 2086 e 2087 para acesso externo. Use VPN ou allowlist de IPs para acesso administrativo.
  3. Verifique sinais de comprometimento. Procure por arquivos com extensão .sorry, webshells inesperados, processos suspeitos em Golang, e sessões root anômalas nos logs.
  4. Revogue credenciais. Se o servidor foi exposto, troque todas as senhas — MySQL, FTP, SSH, chaves de API e certificados.
  5. Habilite autenticação multifator. Embora o bypass contorne o 2FA via manipulação de sessão, o patch corrigiu esse comportamento. MFA agora funciona como camada adicional.

Ferramentas como o scanner gratuito da Pentest-Tools podem identificar instâncias vulneráveis na sua rede.

Uma lição sobre monocultura digital

A Hadrian, empresa de segurança ofensiva, resume bem: 94% dos painéis de controle de hospedagem dependem de um único fornecedor. Quando esse fornecedor tem uma falha de autenticação, o impacto é sistêmico.

O CVE-2026-41940 não é só mais um CVE. É um lembrete de que a infraestrutura de internet depende de software que poucos auditam e muitos confiam. Um único campo sem sanitização, em um painel que controla milhões de servidores, pode paralisar operações globalmente. A correção existe. A questão é quantos servidores ainda estão esperando.

Referências