A BadGarbage (CVE-2026-53361) é uma corrida no garbage collector de sockets Unix do kernel. Um usuário local ou processo dentro de container pode explorar a falha para alcançar root no host. Há prova de conceito pública e o CloudLinux 10 possui kernel e livepatch corretivos.
O que aconteceu
O coletor identifica sockets Unix não mais alcançáveis. Uma corrida envolvendo gc_in_progress pode liberar um socket que continua em uso, produzindo use-after-free. O exploit público transforma a corrupção em elevação de privilégio.
Containers não devem ser tratados como barreira suficiente porque o kernel é compartilhado com o host. O advisory CloudLinux destaca que o processo dentro de container pode escapar e tornar-se root. Linhas CloudLinux anteriores não carregam o código no mesmo escopo e foram classificadas como não afetadas.
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 |
|---|---|---|
| CloudLinux 10 | kernel anterior a 6.12.0-211.47.1.el10_2 | kernel-6.12.0-211.47.1.el10_2+ |
| CloudLinux 7/7h/8/9 | não afetado segundo advisory | manter atualizações normais |
| KernelCare no CL10 | sem patch CVE confirmado | livepatch no main feed |
Não existe mitigação runtime prática: o código de sockets Unix é central e não pode ser removido sem quebrar serviços. SELinux e containerização não impedem a cadeia descrita.
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
Alto. CloudLinux informa CVSS 7,0 e proof of concept funcional. O resultado root/escape tem impacto total e transforma uma conta ou container comprometido em incidente do host.
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
Compare o kernel ativo com o build e, se usa KernelCare, consulte --patch-info, não apenas --info.
cat /etc/cloudlinux-release
uname -r
rpm -q kernel --last | head
kcarectl --patch-info 2>/dev/null | grep CVE-2026-53361
CloudLinux 10 abaixo do build e sem linha CVE no KernelCare está exposto. Kernel corrigido apenas instalado exige reboot. Saída vazia no livepatch deve ser investigada e atualizada.
Como corrigir ou mitigar
Instale kernel-6.12.0-211.47.1.el10_2 ou posterior e reinicie, ou rode a atualização KernelCare e confirme a CVE. Não confie em SELinux ou em retirar acesso shell como correção completa.
dnf update 'kernel*'
kcarectl --update
kcarectl --patch-info | grep CVE-2026-53361
Antes 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
Após reboot/livepatch, valide versão e serviços. Procure alterações de SELinux, usuários UID 0, namespaces, containers, módulos e arquivos privilegiados. Se houve código não confiável local durante a janela, amplie a análise.
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 planos gerenciados, a WebinHost confirma automaticamente o livepatch no main feed ou programa o kernel corrigido. CloudLinux/CageFS controla recursos e isolamento, e Imunify360 previne o comprometimento inicial de sites; como não há mitigação runtime equivalente, o patch recebe prioridade.
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.