CVE-2026-41940 — cPanel & WHM Bypass de Root Pré-Autenticação via Injeção CRLF em Arquivo de Sessão

Um Mergulho Técnico Profundo Focado em Defensores

1. Resumo Executivo

cPanel & WHM é o software de painel de controle dominante para hospedagem compartilhada e revenda. cPanel é a interface da conta do cliente; WHM é a interface administrativa de nível root usada por provedores de hospedagem e administradores de servidores. Ambos são servidos pelo mesmo daemon Perl, cpsrvd, ouvindo em portas pareadas para cada superfície (cPanel: 2082/2083, WHM: 2086/2087, Webmail: 2095/2096).

O CVE-2026-41940 permite que um atacante sem nenhuma credencial manipule o estado da sessão em disco antes da autenticação, fazendo com que o cpsrvd posteriormente reinterprete dados fornecidos pelo atacante como atributos legítimos de sessão totalmente autenticada com privilégios root. O resultado é o comprometimento total do plano de gerenciamento de todos os sites e contas hospedados na máquina — não é um problema de um único inquilino, mas sim do host inteiro, do provedor inteiro e, em conjunto, do setor inteiro, dada a concentração de mercado da cPanel.

2. Por que esta Vulnerabilidade Importa Além de sua Pontuação CVSS

Uma pontuação CVSS 9.8 é comum o suficiente para se tornar entorpecente. Três fatores estruturais tornam o CVE-2026-41940 excepcionalmente grave na prática:

1. O raio de explosão é o servidor inteiro, não uma conta. O comprometimento do WHM é um comprometimento root. Cada conta de cliente, cada banco de dados, cada chave privada TLS, cada backup e cada zona DNS naquele servidor está imediatamente em escopo.

2. Foi um verdadeiro zero-day por cerca de dois meses. A telemetria da KnownHost situa a exploração inicial por volta de 23 de fevereiro de 2026, bem antes do patch de 28 de abril. Qualquer organização que estava exposta à Internet durante essa janela deve assumir que o comprometimento é possível, não apenas teórico, e deve conduzir uma avaliação de comprometimento retrospectiva, em vez de confiar em "nós aplicamos o patch, então estamos bem".

3. A maioria das organizações afetadas não pode aplicar este patch sozinha. O cPanel é tipicamente implantado por provedores de hospedagem em nome dos inquilinos. Os clientes finais não têm controle sobre a correção em nível de código e dependem inteiramente da cadência de patches de seu provedor — que é exatamente por que vários grandes provedores (Namecheap, KnownHost, HostPapa, InMotion) optaram por bloquear proativamente o tráfego de entrada para as portas afetadas, em vez de esperar que todos os inquilinos atualizassem.

Este terceiro ponto merece atenção. O cPanel detém cerca de 94% do mercado de painéis de controle. Uma única falha lógica no código de tratamento de sessão de um fornecedor se tornou, por um período de semanas, uma vulnerabilidade de acesso root de fato em todo o setor. Esse risco de concentração é um tema recorrente que vale a pena internalizar independentemente deste CVE específico.

3. Histórico Arquitetural

3.1 cpsrvd e o modelo de portas

O cpsrvd é um daemon Perl de longa execução que serve todas as três superfícies de produto do cPanel a partir do mesmo binário e, crucialmente, do mesmo caminho de código de tratamento de sessão:

Como todas as três superfícies compartilham a lógica de sessão vulnerável, a exposição de qualquer uma dessas seis portas é suficiente para exploração — não há uma superfície significativamente "menos exposta" entre elas. Em ambientes bem segmentados, nenhuma dessas portas deveria ser diretamente acessível pela Internet em primeiro lugar; na prática, conveniência de gerenciamento, arranjos de hospedagem híbrida e desvios de firewall significam que muitas estavam.

3.2 A representação dupla da sessão

As sessões do cPanel são persistidas em duas representações paralelas em disco, aparentemente por razões de desempenho:

1. Arquivo de sessão raw (/var/cpanel/sessions/raw/<session-id>) — um formato de texto plano orientado a linhas, chave=valor, um atributo por linha.
2. Cache JSON (/var/cpanel/sessions/cache/<session-id>, conceitualmente) — um documento JSON estruturado, lido preferencialmente pelo caminho de requisição normal porque é mais barato de analisar.

Sob operação normal, o cache JSON é autoritativo e o arquivo raw é um backstop de durabilidade. A vulnerabilidade existe precisamente porque há circunstâncias nas quais o arquivo raw é reanalisado e usado para regenerar o cache JSON, e os dois formatos discordam sobre o que um caractere de nova linha embutido significa.

4. Causa Raiz: Quatro Falhas Independentes que se Encadeiam

O CVE-2026-41940 não é um erro único. É o produto de quatro fraquezas separadas, cada uma individualmente plausível como uma decisão de design isolada, que se alinham para produzir um bypass de autenticação completo. Esta estrutura de "queijo suíço" é instrutiva para defensores e revisores de código muito além deste produto específico.

4.1 Camada 1 — Sanitização imposta por convenção, não pelo próprio caminho de escrita

O subsistema de sessão do cPanel já possuía uma rotina de sanitização responsável por remover caracteres perigosos — retornos de carro, quebras de linha e = — dos valores de sessão antes de serem persistidos. O problema está onde essa rotina era invocada: ela residia dentro das funções wrapper de nível superior (a API de "criar"/"modificar" sessão), e era responsabilidade do chamador passar por esses wrappers em vez de escrever dados de sessão diretamente.

O manipulador de Autenticação Básica HTTP dentro do cpsrvd — o caminho de código que aceita credenciais diretamente do cabeçalho HTTP Authorization — persistia a senha submetida no arquivo de sessão pré-autenticação através de uma rotina de salvamento de nível inferior que ignorava o wrapper de sanitização completamente. Como a sanitização era opt-in em vez de obrigatória no ponto de escrita em disco, este chamador a pulou silenciosamente.

Este é o modo de falha clássico de "validar na fonte, não no destino": enquanto um controle de segurança puder ser ignorado simplesmente chamando uma função diferente, ele eventualmente será, seja por descuido, refatoração ou um caminho de código que ninguém pensou em auditar contra este controle específico. A correção permanente que o cPanel enviou move a chamada de sanitização para dentro da própria função de salvamento, para que não possa mais ser ignorada por nenhum chamador, presente ou futuro.

4.2 Camada 2 — Criptografia que a entrada controlada pelo atacante podia desabilitar

O escritor de sessão criptografa campos sensíveis (notadamente o campo de senha) usando uma chave simétrica por sessão. Essa chave é derivada de um componente embutido no cookie de sessão que o cliente apresenta. No código vulnerável, se esse componente de chave estava ausente da requisição — algo inteiramente sob controle de um atacante, já que ele escolhe qual cookie enviar — a etapa de criptografia era silenciosamente ignorada em vez de a escrita ser recusada.

Em outras palavras: um atacante que deliberadamente omite ou trunca parte de seu cookie de sessão pode fazer com que seus próprios dados submetidos sejam escritos em disco sem criptografia. Criptografia cuja ativação pode ser desligada pela parte não confiável que fornece a entrada não é uma fronteira de segurança significativa; ela deveria falhar de forma fechada (recusar persistir ou recusar a requisição) em vez de falhar de forma aberta (persistir sem proteção).

4.3 Camada 3 — Discordância de formato entre o arquivo raw e o cache JSON

Este é o cerne da "injeção" na Injeção CRLF. O arquivo de sessão raw é delimitado por linhas: uma sequência de retorno de carro / quebra de linha termina um registro chave=valor e começa o próximo. O formato de cache JSON, por outro lado, representa a mesma sequência de caracteres como uma substring escapada dentro de um único valor de string JSON — semanticamente inerte, apenas dados.

Enquanto uma sessão existir apenas no cache JSON, um CRLF embutido em um campo como a senha é inofensivo — são apenas bytes dentro de uma string. O perigo aparece no caminho de código que reanalisa o arquivo raw e regenera o cache. Isso ocorre, de acordo com análises técnicas públicas, quando uma requisição é rejeitada por falhar em uma verificação de token de segurança vinculado à URL; o manipulador responsável por essa rejeição recarrega a sessão ignorando o cache e relendo o arquivo raw linha por linha, e então reescreve o cache JSON a partir dessa reanálise.

Naquele momento, as sequências CRLF que o atacante embutiu em sua "senha" submetida deixam de ser bytes inertes dentro de um campo e se tornam separadores de registro, dividindo o que deveria ser um único valor em múltiplas linhas independentes chave=valor. Cada uma dessas linhas — incluindo aquelas cujo nome e valor o atacante controla completamente — é então promovida a uma entrada de nível superior no cache JSON de sessão regenerado, indistinguível para o resto do código de um atributo de sessão definido legitimamente.

A lição geral: sempre que dois analisadores sintáticos puderem ser levados a interpretar a mesma sequência de bytes de forma diferente — raw vs. cache, codificado em formulário vs. JSON, uma convenção de escape vs. outra — essa discordância é uma primitiva de injeção latente. Não importa qual analisador é "mais correto"; o que importa é que dados não confiáveis podem cruzar entre as duas representações sem serem revalidados contra a gramática do segundo analisador.

4.4 Camada 4 — Um sinalizador "já autenticado" sem vínculo criptográfico

O elo final na cadeia está na própria lógica de verificação de senha. Se uma sessão já carrega um campo registrando um carimbo de data/hora de autenticação interna bem-sucedida recente, o desafio de senha é ignorado completamente — a presença desse campo sozinha é tratada como prova suficiente de que a autenticação já ocorreu. Um sinalizador companheiro de verificação de dois fatores suprime similarmente o desafio de 2FA baseado puramente em sua presença.

Ambos os campos existem para fins internos legítimos (hand-offs de login único entre componentes do cPanel, ferramentas internas que já validaram um usuário por outro meio). A falha de design é que nenhum dos campos está criptograficamente vinculado a um evento de autenticação real — eles são atributos de sessão simples que, uma vez que a Camada 3 permite que um atacante escreva atributos de sessão arbitrários, podem ser simplesmente forjados. Um sinalizador que significa "confie em mim, isso já foi verificado" só é significativo se não puder ser definido pela parte que está sendo confiada.

4.5 Efeito Composto

Nenhuma dessas quatro fraquezas é independentemente catastrófica:

• Uma chamada de sanitização ausente é um bug latente até que algo leia os dados contaminados de forma diferente do que foram escritos.
• Criptografia ignorada por chave ausente é uma preocupação de confidencialidade até que o conteúdo de texto simples se torne explorável.
• Uma incompatibilidade de formato de representação dupla é inerte até que algo derive uma representação da outra.
• Um sinalizador de confiança não autenticada é seguro enquanto nada mais permitir que um atacante o defina.

Juntas, elas produzem um comprometimento remoto root completo e não autenticado. Este é precisamente o tipo de vulnerabilidade que testes unitários restritos a funções individuais não detectarão, porque nenhuma função isolada está "errada" — a falha vive na interação entre subsistemas que foram raciocinados independentemente.

5. Fluxo de Ataque Conceitual

O seguinte descreve os estágios lógicos da exploração, no nível de detalhe já público em avisos de fornecedores e da indústria, sem reproduzir bytes literais de payload, cabeçalhos codificados ou uma sequência de requisições executável.

A partir do Estágio 5, um atacante possui acesso à API WHM comum e totalmente autorizado. O conjunto legítimo de funcionalidades do WHM — hooks personalizados, gerenciamento de pacotes/modelos, configuração de manipulador PHP, gerenciamento de cron e contas, edição de zonas DNS — é mais que suficiente para escalar isso para execução interativa de código root através de funcionalidades administrativas inteiramente "suportadas", sem necessidade de vulnerabilidade adicional.

Relatórios públicos notam que a cadeia ponta a ponta requer apenas um pequeno número de requisições HTTP e envolve uma condição de corrida benigna em torno da ordenação não determinística de chaves hash do Perl durante a regeneração do cache — significando que um pequeno número de tentativas pode ser necessário para total confiabilidade, um detalhe com valor de detecção (veja §7.3).

6. Linha do Tempo

7. Engenharia de Detecção

7.1 Indicadores baseados em sistema de arquivos (maior sinal)

A evidência mais forte reside no próprio armazenamento de sessão raw, /var/cpanel/sessions/raw/. Uma sessão que se originou de um login falho ou não privilegiado nunca deve conter legitimamente nenhum dos seguintes campos de nível superior:

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<valor>

...a menos que essa sessão tenha genuinamente completado uma autenticação root adequada e desafio 2FA através do fluxo de login normal. A presença desses campos em uma sessão cujos metadados de origem mostram uma tentativa de senha falha é um forte indicador de exploração.

Um sinal de confiança ainda maior: múltiplas linhas pass= dentro de um único arquivo de sessão. Sob operação normal, uma sessão tem exatamente um campo de senha. Múltiplas ocorrências são produzidas apenas pelo comportamento de divisão CRLF subjacente a esta vulnerabilidade e devem ser tratadas como um indicador de comprometimento quase certo.```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 Correlação de logs de acesso (quando os arquivos de sessão não são encaminhados centralmente)

Se os arquivos brutos de sessão não forem retidos por tempo suficiente, ou não forem encaminhados para um sistema central de logs, os logs de acesso do `cpsrvd` podem servir como substituto. Dois padrões de correlação são úteis:

**Padrão A — falha de login seguida imediatamente por um cabeçalho Basic-auth fora de lugar.** Um cliente normal não envia um cabeçalho `Authorization: Basic` em uma requisição para uma URL arbitrária que não seja de login imediatamente após um POST de senha com falha da mesma fonte. Esta sequência — um `401` no endpoint de login seguido, dentro de uma janela curta, por uma requisição contendo Basic-auth em outro local, correlacionada pelo IP de origem e/ou cookie de sessão — é anômala e merece alerta.

**Padrão B — um token do tipo `cpsess` aparecendo em uma URL antes de ser emitido legitimamente.** Tokens de segurança legítimos por sessão são gerados no servidor e aparecem primeiro em uma resposta `Set-Cookie`/redirecionamento *antes* de serem usados em URLs de requisições subsequentes. Um token que aparece em uma URL de requisição de entrada sem uma ocorrência anterior emitida pelo servidor é inconsistente com o comportamento normal do cliente e merece ser sinalizado, particularmente se o token não corresponder ao formato esperado gerado pelo servidor.

### 7.3 Sinal comportamental / de repetição

Como a regeneração do cache está sujeita à ordenação não determinística das chaves hash do Perl, foi observado que a exploração bem-sucedida em campo às vezes requer um pequeno número de tentativas antes que os campos desejados "vençam" no cache regenerado. Uma curta rajada de requisições estruturalmente semelhantes (mesma origem, mesma sessão, mesmo padrão de URL alvo, ocorrendo dentro de alguns segundos uma da outra) imediatamente seguida pelo uso bem-sucedido de uma API administrativa é um sinal corroborante secundário que vale a pena ponderar junto com §7.1 e §7.2 — por si só é muito genérico para alertar, mas fortalece a confiança quando combinado com os indicadores de sistema de arquivos ou de log de acesso acima.

### 7.4 Indicadores pós-comprometimento

Como o acesso ao WHM é acesso root, trate a exploração confirmada como uma investigação completa de comprometimento do host, não como um incidente de aplicação web. Procure por:

- Contas de usuário inesperadas no nível WHM/root ou contas de revendedor criadas fora dos processos de gerenciamento de mudanças
- Chaves públicas SSH novas ou não reconhecidas em `root`'s ou em qualquer conta hospedada `~/.ssh/authorized_keys`
- Entradas cron não reconhecidas, tanto no sistema como um todo quanto por conta hospedada
- "Hooks" personalizados do WHM que não foram provisionados por administradores conhecidos
- Alterações inesperadas na configuração do manipulador PHP, definições de pacotes/modelos ou arquivos de zona DNS
- Conexões de saída ou processos executando como root que não correspondem a serviços conhecidos do cPanel/WHM

---

## 8. Mitigação e Manual de Resposta a Incidentes

### 8.1 Ações imediatas

1. **Inventarie** todas as instâncias cPanel/WHM/WP Squared sob seu controle ou sob o controle de seu provedor.
2. **Determine a exposição à internet** para cada instância durante as janelas de divulgação e pré-divulgação (considere 23 de fevereiro a 28 de abril de 2026 como a janela de exposição de preocupação).
3. **Atualize para uma versão corrigida:**

   | Branch | Minimum patched version |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. **Verifique** a versão aplicada com `/usr/local/cpanel/cpanel -V`.
5. **Reinicie o `cpsrvd`** após a atualização — um daemon não reiniciado pode continuar executando código vulnerável na memória (`/scripts/restartsrv_cpsrvd`).
6. Se você depende de um host de terceiros, **confirme o status da correção diretamente com o provedor** em vez de presumir que foi aplicada.
7. Servidores com **atualização automática desabilitada ou versão fixada** não se autocorrigirão — estes requerem intervenção manual explícita e devem ser priorizados, pois são estatisticamente os mais propensos a ainda estarem vulneráveis.

### 8.2 Curto prazo (dentro de dias após a correção)

- Execute as consultas de detecção baseadas em sistema de arquivos e logs da §7 contra a janela de exposição completa, não apenas "desde que notamos."
- Audite o WHM em busca de contas inesperadas, chaves SSH, entradas cron e hooks personalizados.
- Verifique a integridade de `/etc/`, `/usr/local/cpanel/` e dos arquivos de configuração do shell/`authorized_keys` do root em relação a baselines ou backups conhecidos como bons.
- Rotacione senhas do WHM de root e revendedor, tokens de API e chaves SSH **independentemente de indicadores de comprometimento terem sido encontrados** — dada a janela de exploração de pré-divulgação de dois meses, a ausência de evidência não é evidência forte de ausência em um host que esteve exposto durante todo esse período.
- Elimine o estado da sessão (`/var/cpanel/sessions/raw/` e o diretório de cache JSON) após a correção, para que nenhuma sessão forjada residual possa ser repetida.

### 8.3 Endurecimento de longo prazo

- Restrinja o acesso de entrada às portas cPanel/WHM/Webmail (2082, 2083, 2086, 2087, 2095, 2096) a faixas de IP administrativas conhecidas através de lista de permissões de firewall. Essas portas do plano de gerenciamento não devem ser amplamente acessíveis pela internet em condições normais de operação.
- Encaminhe os logs de acesso do `cpsrvd` — e idealmente os eventos de gravação de sessão — para um SIEM centralmente retido, já que os arquivos de sessão no host são efêmeros e facilmente perdidos durante a triagem se não forem preservados rapidamente.
- Estabeleça um inventário de base das contas WHM esperadas, chaves SSH e tarefas cron, e monitore por desvios.
- Acompanhe a versão do cPanel/WHM e a cadência de correções como uma métrica de gerenciamento de ativos de primeira classe, particularmente para qualquer instância autogerenciada (não terceirizada).

### 8.4 Se o comprometimento for confirmado

- **Não tente remediação no local de um host comprometido como root.** Uma vez que o root é obtido, o invasor teve a capacidade de modificar qualquer coisa, incluindo as ferramentas que você usaria para investigar. Trate a "limpeza" no local como não confiável.
- **Reconstrua a partir de imagens conhecidas como limpas e corrigidas** em vez de corrigir e continuar executando o sistema potencialmente comprometido.
- **Rotacione todas as credenciais administrativas** em todo o servidor, não apenas as diretamente implicadas.
- **Substitua todas as chaves SSH**, incluindo aquelas pertencentes a contas de clientes hospedados, pois um invasor com nível root poderia ter coletado ou plantado qualquer uma delas.
- **Assuma que todos os dados de clientes hospedados no servidor foram expostos** e siga as obrigações aplicáveis de notificação de violação.
- **Investigue movimentação lateral** para segmentos de rede interna adjacentes, já que infraestrutura de hospedagem comprometida é um ponto de pivô comum para ambientes corporativos (por exemplo, via credenciais, relações de confiança SSH ou segredos compartilhados reutilizados em outros lugares).

---

## 9. Perguntas Frequentes

**Isso é propagável / adequado para exploração automatizada em massa?**
A cadeia subjacente é totalmente não autenticada e envolve um número pequeno e fixo de requisições HTTP, razão pela qual a CISA o elevou ao status KEV e por que ferramentas de varredura em massa referenciando este CVE já surgiram publicamente. Trate qualquer instância não corrigida e acessível pela internet como estando em risco ativo de comprometimento oportunista e automatizado, não apenas de ataque direcionado.

**A autenticação de dois fatores protege contra isso?**
Não. A injeção forja diretamente o sinalizador de sessão "2FA já verificado", portanto o desafio de 2FA nunca é apresentado em primeiro lugar. O 2FA não fornece mitigação para esta vulnerabilidade específica.

**Meu WAF detectará isso?**
Apenas se ele normalizar/inspecionar payloads `Authorization: Basic` em busca de sequências CRLF embutidas *e* inspecionar separadamente os cookies de sessão em busca do padrão malformado/truncado associado à condição de salto de criptografia. Conjuntos de regras genéricos de WAF geralmente não detectaram a exploração pré-divulgação deste problema. A correção continua obrigatória independentemente da postura do WAF.

**Isso afeta implantações cPanel DNSOnly?**
Sim, de acordo com o aviso do fornecedor — instalações DNSOnly estão no escopo.

**Versões mais antigas e não suportadas (pré-11.40) do cPanel são afetadas?**
Não — de acordo com análises públicas, o caminho de código vulnerável não estava presente em versões anteriores ao ramo 11.40, pois versões legadas não suportadas são anteriores à implementação relevante de manipulação de sessão.

**Existe uma solução alternativa disponível se eu não puder corrigir imediatamente?**
Não existe solução alternativa funcional que feche completamente a vulnerabilidade sem a correção. A única mitigação interina eficaz é bloquear o acesso de entrada às portas afetadas (2082/2083, 2086/2087, 2095/2096) no perímetro da rede, ou parar os serviços `cpsrvd`/`cpdavd` completamente, ambas as quais também têm o custo do acesso legítimo.

---

## 10. Lições Mais Amplas para Engenharia de Software e Segurança

Independente do cPanel especificamente, esta vulnerabilidade é um estudo de caso útil para qualquer pessoa revisando código de autenticação e manipulação de sessão em outros lugares:

1. **Desinfecte no ponto de persistência, não a critério do chamador.** Qualquer controle de segurança que possa ser contornado simplesmente chamando uma função diferente no mesmo subsistema acabará sendo contornado — seja por um invasor que encontra a lacuna, ou por um engenheiro futuro que não sabe que ela existe.
2. **Os controles de segurança devem falhar fechados em entradas ausentes ou malformadas, nunca falhar abertos.** Se uma operação criptográfica depende de material fornecido pelo cliente, a ausência desse material deve abortar a operação, não pular silenciosamente a proteção que deveria fornecer.
3. **Toda representação dupla dos mesmos dados é um potencial primitivo de contrabando.** Sempre que um sistema mantém duas serializações do mesmo estado (bruto vs. cache, codificado em formulário vs. JSON, escapado vs. não escapado) e depois deriva uma da outra, audite esse caminho de derivação especificamente para casos onde dados não confiáveis podem cruzar o limite não filtrados.
4. **Os sinalizadores de confiança devem ser criptograficamente vinculados ao evento que afirmam, não meramente presentes.** Um atributo de sessão significando "autenticação já bem-sucedida" só é seguro se um invasor não puder definir esse atributo independentemente — por meio de uma assinatura, MAC ou vinculação equivalente ao evento de autenticação real, não através de armazenamento não autenticado.
5. **Qualquer coisa escrita em disco como consequência de uma requisição não autenticada deve ser tratada como controlada pelo invasor**, incluindo dados que são apenas lidos de volta por *outros* caminhos de código aparentemente não relacionados. O perigo nesta vulnerabilidade não estava no código que escreveu os dados — estava em um caminho de código completamente diferente e posterior que os reinterpretou sob regras de análise diferentes.

---

## 11. Referências

- cPanel Security Advisory — *Vulnerabilidade Crítica com Autenticação de Login do cPanel e WHM*, 28 de abril de 2026 — `docs.cpanel.net/release-notes/release-notes`
- watchTowr Labs — análise original de causa raiz e prova de conceito, Sina Kheirkhah, 29 de abril de 2026 — `labs.watchtowr.com`
- Rapid7 — Relatório de Ameaça Emergente sobre CVE-2026-41940 — `rapid7.com`
- Arctic Wolf — resumo da ameaça CVE-2026-41940 — `arcticwolf.com`
- Hadrian — *CVE-2026-41940: Uma Bypass de Autenticação Crítica no cPanel* — `hadrian.io`
- Picus Security — *CVE-2026-41940 Explicado: A Bypass de Autenticação do cPanel e WHM que Atingiu 1.5 Milhões de Servidores* — `picussecurity.com`
- Entrada do catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA para CVE-2026-41940 — `cisa.gov`
- BleepingComputer, The Hacker News, CyberScoop — cobertura contemporânea da divulgação e exploração no mundo real
- WP Squared changelog — `docs.wpsquared.com/changelogs`
- Aviso da comunidade KnownHost documentando suspeita de exploração pré-divulgação