A CVE-2026-65639 é uma injeção de comandos no parser de regras avançadas do ConfigServer Security & Firewall, distribuído pelo cPanel. Um atacante que controla o conteúdo de um feed remoto já confiado pelo administrador pode fazer o CSF executar comandos arbitrários como root. O cPanel lançou o CSF 16.30 para eliminar a falha.
O que aconteceu
O CSF aceita fontes externas por opções como GLOBAL_DENY e GLOBAL_ALLOW. Ao baixar e interpretar uma regra avançada malformada, versões vulneráveis não neutralizavam corretamente metacaracteres antes de construir a operação executada com privilégio administrativo. O problema transforma o comprometimento do provedor do feed, do domínio ou do caminho de entrega em execução de comandos no servidor.
Uma instalação padrão não possui feed remoto configurado e, portanto, não oferece diretamente a pré-condição descrita. Isso não reduz a necessidade de atualizar: configurações antigas podem ter sido mantidas após migrações, e feeds legítimos também podem ser comprometidos. O inventário deve verificar tanto a versão instalada quanto a origem efetivamente cadastrada.
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 linha | Afetado / exposto | Corrigido / protegido |
|---|---|---|
| CSF 2.15 a 16.29 | vulnerável; exploração remota exige controle de feed configurado | CSF 16.30 ou superior |
| CSF sem GLOBAL_ALLOW/GLOBAL_DENY remoto | código vulnerável, mas sem a rota remota conhecida | atualizar mesmo assim |
| CSF 16.30+ | corrigido para este parser | manter pacotes e feeds sob revisão |
O servidor fica materialmente exposto quando uma URL externa está configurada e o conteúdo dessa origem pode ser influenciado pelo atacante. Endereço HTTPS reduz adulteração em trânsito, mas não protege contra comprometimento do domínio ou do repositório fornecedor. Listas locais não criam a mesma rota remota, embora ainda devam ser revisadas.
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
Crítico — CVSS v4.0 9,5. A consequência é execução de comando como root, com impacto potencial sobre todas as contas, bancos, e-mails e credenciais do host. A necessidade de controlar um feed previamente configurado limita o conjunto de alvos, mas a ausência de interação humana e o privilégio final justificam resposta emergencial em ambientes expostos.
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
Consulte a versão do CSF e procure apenas as diretivas relevantes, sem baixar ou testar conteúdo desconhecido. Registre a URL, o responsável pela lista, a data da última alteração e o hash do arquivo em cache para posterior investigação.
csf -v
grep -E '^[[:space:]]*(GLOBAL_ALLOW|GLOBAL_DENY)[[:space:]]*=' /etc/csf/csf.conf
ls -l /var/lib/csf/csf.gallow /var/lib/csf/csf.gdeny 2>/dev/null
sha256sum /var/lib/csf/csf.gallow /var/lib/csf/csf.gdeny 2>/dev/nullQualquer versão de 2.15 até 16.29 deve ser atualizada. Se GLOBAL_ALLOW ou GLOBAL_DENY aponta para HTTP/HTTPS, trate a máquina como exposta à cadeia e confirme a confiança na origem. Arquivos de cache inesperados, regras com sintaxe incomum ou alterações coincidentes com processos privilegiados exigem preservação de evidências.
Como corrigir ou mitigar
Atualize os pacotes do cPanel até receber CSF 16.30 ou posterior. Enquanto a manutenção não termina, remova ou comente feeds remotos que não sejam estritamente necessários, limpe o cache correspondente somente depois de preservá-lo para análise e reinicie CSF/LFD. Não substitua uma URL por outra lista desconhecida.
csf -v
/usr/local/cpanel/scripts/update-packages
csf -r
systemctl restart lfd
csf -vAntes 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
Confirme que o resultado mostra 16.30 ou superior e valide firewall, portas liberadas, bloqueios, acesso WHM/SSH e entrega de e-mail. Compare regras atuais com backup conhecido, investigue comandos executados como root, crons, chaves SSH, usuários UID 0, serviços e arquivos recentes. Se o feed ou seu fornecedor foi comprometido, a atualização sozinha não elimina persistência.
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
Nos servidores cPanel gerenciados, a WebinHost inventaria feeds do CSF, força o ciclo oficial de pacotes, reinicia e testa o firewall e procura alterações privilegiadas durante a janela de exposição. Imunify360 acrescenta WAF, detecção de malware e defesa proativa; KernelCare mantém correções de kernel sem reinício quando disponíveis. Essas camadas reduzem caminhos adjacentes, mas a correção específica é o CSF 16.30+.
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.
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.
Assistente IA WGS