Um único request HTTP dava acesso root ao seu servidor

Imagina acordar numa terça-feira e descobrir que todos os sites do seu servidor estão com os arquivos renomeados para .sorry. Sem backup. Sem aviso. Sem negociação — só um bilhete pedindo para entrar em contato via Tox. Isso aconteceu com administradores de 44.000 servidores cPanel entre o final de fevereiro e o começo de maio de 2026.

E o pior? A falha que permitiu tudo isso era tão simples que cabe numa explicação de dois parágrafos.

O que é o CVE-2026-41940

O cPanel é o painel de controle mais popular do planeta para hospedagem web. Estima-se que ele rode em mais de 70 milhões de domínios — algo como um terço de todos os sites que usam painel de gerenciamento. Hostinger, HostGator, Namecheap, KnownHost… a lista de provedores que dependem dele é absurda.

No dia 28 de abril de 2026, a WebPros (empresa que desenvolve o cPanel) publicou um advisory de segurança para o CVE-2026-41940. Score CVSS: 9.8 de 10. Classificação: bypass de autenticação. Traduzindo: qualquer pessoa na internet podia se logar como root no WHM sem saber a senha. Sem brute force, sem phishing, sem engenharia social. Um request HTTP bem montado era suficiente.

A equipe da watchTowr Labs publicou a análise técnica completa, e o mecanismo é quase poético na sua simplicidade — e assustador na sua gravidade.

CRLF Injection: a falha de 1996 que derrubou 44 mil servidores em 2026

O ataque explora uma técnica chamada CRLF Injection — injeção de caracteres de retorno de carro e nova linha (\r\n). É uma classe de vulnerabilidade que existe desde os primórdios da web, literalmente dos anos 90. E em 2026, o cPanel ainda não filtrava esses caracteres no lugar certo.

Aqui está como funciona, passo a passo:

A arquitetura de sessão do cPanel

O cPanel armazena sessões em dois formatos simultâneos:

• Arquivo raw (/var/cpanel/sessions/raw/): formato texto, uma propriedade por linha
• Arquivo cache (/var/cpanel/sessions/cache/): formato JSON serializado

Quando você faz login, o cPanel gera um cookie de sessão no formato :sessionID,hexsecret. O hexsecret (chamado internamente de ob) é o segredo per-session que autentica requests subsequentes.

O vetor de ataque

O problema está na função set_pass do módulo Session.pm. Ela filtra apenas caracteres nulos (\0), mas ignora completamente \r e \n. Um atacante pode enviar um header de Basic Authorization assim:

Authorization: Basic base64(user:password\r\nhasroot=1\r\nuser=root\r\nsuccessful_internal_auth_with_timestamp=1777462149)

Quando o cPanel processa esse header, a “senha” contendo os caracteres \r\n é gravada no arquivo de sessão raw. Como o formato é uma propriedade por linha, cada injeção vira um campo separado no arquivo.

O truque da promoção de cache

Aqui entra a parte inteligente. Inicialmente, o JSON do cache trata a injeção inteira como uma string dentro do campo pass — então os campos injetados ficam invisíveis. Mas quando o atacante faz um request sem o security token (forçando uma validação), o cPanel executa Cpanel::Session::Modify::new() seguido de Modify::save().

Esse processo lê o arquivo raw (onde as linhas injetadas são campos separados), parseia cada uma como um par chave-valor legítimo, e reescreve o cache JSON com os campos promovidos para top-level. Agora hasroot=1 e successful_internal_auth_with_timestamp existem como propriedades reais da sessão.

O bypass final

No código de autenticação do cPanel, existe um check direto:

if ($successful_internal_auth_with_timestamp) {
    return AUTH_OK;
}

Quando esse timestamp existe na sessão, o sistema retorna AUTH_OK incondicionalmente. O /etc/shadow nem é consultado. O 2FA é ignorado. O atacante tem acesso root ao WHM.

Em resumo: mint session → injeta CRLF no Basic Auth → força resync do cache → root sem senha. Quatro requests. Menos de 5 segundos.

O ransomware “Sorry”: Go, ChaCha20 e zero remorso

Os atacantes não perderam tempo. Assim que tinham acesso root via WHM, deployavam o “Sorry” — um encryptor escrito em Go, compilado para Linux, com as seguintes características:

A escolha de Go não é casual. Um binário Go compila para um executável estático que roda em qualquer distribuição Linux sem dependências — perfeito para servidores de hosting que rodam desde CentOS 7 até AlmaLinux 9.

O ChaCha20 com chave RSA-2048 torna a descriptografia impossível sem a chave privada dos atacantes. Diferente de alguns ransomwares que tiveram falhas na implementação criptográfica (como o antigo Akira), o Sorry não deixa brechas.

A Censys identificou 8.859 hosts com diretórios abertos contendo arquivos .sorry, dos quais 7.135 foram confirmados como servidores cPanel ou WHM. A Shadowserver Foundation reportou 44.000 IPs únicos envolvidos na campanha — entre escaneamento, exploração e brute force.

Dois meses de silêncio: o período zero-day

Essa é talvez a parte mais perturbadora de toda a história. A exploração ativa do CVE-2026-41940 começou em 23 de fevereiro de 2026. O patch só saiu em 28 de abril de 2026. São mais de 60 dias de exploração zero-day antes que qualquer correção existisse.

23/02/2026 ──── Primeira exploração observada
     │
     │         ~60 dias de exploração ativa sem patch
     │
28/04/2026 ──── Advisory público + patch liberado
30/04/2026 ──── 44.000+ servidores comprometidos confirmados
01/05/2026 ──── CISA adiciona à lista KEV (Known Exploited Vulnerabilities)
04/05/2026 ──── Múltiplos grupos de ameaça explorando ativamente
08/05/2026 ──── 3 novos CVEs descobertos e patcheados

Durante esses dois meses, qualquer servidor cPanel exposto à internet era um alvo aberto. E como o cPanel roda na porta 2083 (HTTPS) e 2087 (WHM), que frequentemente ficam abertas no firewall por padrão, a superfície de ataque era gigantesca.

Os provedores de hosting que reagiram mais rápido — Namecheap, HostGator e KnownHost — fizeram firewall temporário nas portas do WHM e cPanel até aplicar o patch. Mas muitos provedores menores e servidores autogerenciados ficaram expostos por dias ou semanas após a publicação da correção.

A semana ficou pior: 3 novos CVEs em 10 dias

Como se uma vulnerabilidade CVSS 9.8 não fosse suficiente, o cPanel liberou um segundo patch de emergência em 8 de maio de 2026 — exatos 10 dias depois do primeiro. Dessa vez, três falhas novas:

CVE-2026-29201 (CVSS 4.3) — Leitura arbitrária de arquivos

Validação insuficiente no parâmetro de nome de arquivo de feature na função feature::LOADFEATUREFILE. Um atacante autenticado podia ler qualquer arquivo do sistema — incluindo /etc/shadow, configurações de banco de dados, e chaves SSH.

Parece “baixa severidade” pelo score CVSS? Na prática, é a porta de entrada para escalonamento de privilégio. Com acesso a /etc/shadow e chaves SSH, o atacante sai do painel e entra no sistema operacional.

CVE-2026-29202 (CVSS 8.8) — Execução de código Perl arbitrário

Manuseio inseguro do parâmetro plugin na API create_user. Qualquer titular de conta em hosting compartilhado podia injetar código Perl malicioso com acesso a nível de sistema. Leu certo: não precisa ser admin. Qualquer cliente de hosting compartilhado podia comprometer o servidor inteiro.

Isso é particularmente assustador em ambientes de hosting compartilhado, onde um único servidor pode hospedar centenas de sites de clientes diferentes. Um cliente malicioso (ou uma conta comprometida) bastava para derrubar todo o servidor.

CVE-2026-29203 (CVSS 8.8) — Symlink inseguro com chmod

Manuseio inseguro de symlinks permite que atacantes modifiquem permissões de arquivos arbitrários via operações chmod. O resultado é denial-of-service ou escalonamento de privilégio.

O ataque clássico de symlink: crie um link simbólico apontando para /etc/passwd, execute um chmod via interface do cPanel, e as permissões são aplicadas ao arquivo real. Dependendo do contexto, isso pode tornar arquivos críticos legíveis por qualquer usuário ou completamente inacessíveis.

Quem audita o código de 70 milhões de domínios?

Eu fico pensando numa coisa. O cPanel tem 25 anos. É um dos softwares mais críticos da infraestrutura da web. Hospeda um terço dos sites com painel de controle. E a falha principal — CRLF injection no handler de autenticação — é o tipo de bug que qualquer scanner de segurança automatizado deveria pegar.

A watchTowr Labs descreveu a vulnerabilidade como “quase poética na sua simplicidade”. E é verdade. Filtrar \r e \n em input de autenticação é segurança básica — tão básica que muitos frameworks web fazem isso automaticamente há mais de uma década.

O fato de que o módulo Session.pm do cPanel filtrava apenas \0 e ignorava \r\n sugere que, em algum momento da evolução do código, alguém assumiu que esses caracteres seriam sanitizados em outra camada. Spoiler: não eram.

E isso levanta uma questão mais ampla sobre a dívida técnica de softwares legados que se tornaram infraestrutura crítica. O cPanel é escrito predominantemente em Perl — uma linguagem que, apesar de poderosa, não oferece as proteções de memória e tipo que linguagens modernas trazem. O código cresce, as camadas se acumulam, e suposições antigas se tornam vulnerabilidades novas.

O que fazer agora se você usa cPanel

Se você administra servidores com cPanel, aqui está o checklist mínimo de sobrevivência:

1. Atualize imediatamente

# Como root no servidor
/scripts/upcp --force

# Reinicie o daemon
/scripts/restartsrv_cpsrvd

# Verifique a versão
/usr/local/cpanel/cpanel -V

Versões patcheadas: 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, 11.136.0.5 ou superior.

2. Audite os logs desde 23 de fevereiro

# Buscar tentativas de exploração no access log do cPanel
grep -i "authorization.*basic" /usr/local/cpanel/logs/access_log | \
  awk '$0 ~ /2026-02-2[3-9]|2026-0[3-4]/' | head -50

# Verificar se há arquivos .sorry
find / -name "*.sorry" -type f 2>/dev/null | head -20

# Checar sessões suspeitas
ls -la /var/cpanel/sessions/raw/ | head -30

3. Restrinja acesso ao WHM

# Firewall: permitir WHM/cPanel apenas de IPs conhecidos
iptables -A INPUT -p tcp --dport 2087 -s SEU_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 2087 -j DROP
iptables -A INPUT -p tcp --dport 2083 -s SEU_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 2083 -j DROP

Ou melhor: use CSF (ConfigServer Security & Firewall) que já é padrão em muitos servidores cPanel.

4. Verifique contas de hosting compartilhado

O CVE-2026-29202 permite que qualquer cliente de hosting compartilhado execute código no nível do sistema. Se você tem clientes em hosting compartilhado, audite todas as contas e processos rodando.

5. Considere alternativas

Talvez seja hora de repensar se o cPanel é realmente a melhor opção. Algumas alternativas:

Eu sei que migrar de cPanel é uma dor enorme — especialmente quando você tem dezenas de sites configurados, contas de email, certificados SSL. Mas 4 CVEs em 10 dias, sendo que um deles deu acesso root sem senha por dois meses, é o tipo de coisa que faz a gente reconsiderar.

O elefante na sala: Perl em 2026

Não é justo culpar a linguagem por bugs de lógica. Um CRLF injection pode acontecer em qualquer linguagem. Mas existe um motivo pelo qual frameworks modernos — Django, Rails, Express — sanitizam inputs automaticamente em suas camadas de autenticação. E existe um motivo pelo qual bases de código com 25 anos acumulam esse tipo de dívida técnica.

O cPanel é escrito predominantemente em Perl, com algumas partes em C e shell script. O módulo Session.pm que continha a falha principal é Perl puro. A função set_pass que deveria sanitizar a entrada apenas removia \0 — um filtro que faz sentido nos anos 2000, mas que hoje é comicamente insuficiente.

A real é que o cPanel cresceu organicamente durante duas décadas e meia. Camadas foram adicionadas sobre camadas. Suposições de segurança feitas em 2003 ainda estão embutidas em código que roda em produção em 2026. E quando alguém da watchTowr finalmente olhou com atenção, encontrou uma falha que dá acesso root com quatro requests HTTP.

O código do cPanel não é open source. Não pode ser auditado pela comunidade. Não passa por revisões públicas de segurança. E agora sabemos que suas revisões internas deixaram um auth bypass trivial passar por pelo menos 60 dias de exploração ativa.

Lições de uma semana negra

A saga do cPanel em abril-maio de 2026 vai entrar para os livros como um dos maiores incidentes de segurança em infraestrutura web. 44.000 servidores comprometidos. 70 milhões de domínios potencialmente afetados. Uma falha de CRLF injection — técnica conhecida desde os anos 90 — no handler de autenticação de um dos softwares mais usados do planeta.

Se o seu servidor ainda não foi atualizado, pare de ler e vá rodar /scripts/upcp --force agora. Sério. Cada minuto conta quando o exploit é público e qualquer script kiddie com acesso ao PoC da watchTowr pode tentar.

E se você está pensando “meu servidor é pequeno, ninguém vai atacar”… os 44.000 servidores comprometidos provavelmente pensavam a mesma coisa.

Fonte de inspiração: CPanel’s Black Week: 3 New Vulnerabilities Patched After Attack on 44k Servers via Hacker News