O boletim reúne duas falhas de kernel: Januscape (CVE-2026-53359), use-after-free no shadow paging KVM x86, e Bad Epoll (CVE-2026-46242), use-after-free em eventpoll. Ambas receberam kernels corretivos nas linhas AlmaLinux 8, 9 e 10.
O que aconteceu
Januscape afeta a gestão de páginas de memória usada pelo KVM. Sob concorrência e invalidação, uma página de shadow paging pode ser liberada enquanto ainda é referenciada. Em hosts de virtualização, a fronteira guest/host torna o cenário especialmente sensível.
Bad Epoll afeta o subsistema que acompanha eventos de descritores de arquivo. Uma condição de corrida pode deixar o kernel operar sobre memória já liberada, oferecendo corrupção e possível elevação de privilégio a um processo local. São bugs distintos e o patch de um não deve ser presumido como correção do outro sem o release indicado.
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 |
|---|---|---|
| AlmaLinux 8 | kernel anterior a 4.18.0-553.141.2.el8_10 | 4.18.0-553.141.2.el8_10+ |
| AlmaLinux 9 | kernel anterior a 5.14.0-687.23.1.el9_8 | 5.14.0-687.23.1.el9_8+ |
| AlmaLinux 10 | kernel anterior a 6.12.0-211.31.1.el10_2 | 6.12.0-211.31.1.el10_2+ |
Januscape é mais relevante onde KVM está disponível e há guests; Bad Epoll exige execução local. Um shared host pode transformar invasão de um site em ponto inicial local, enquanto um hypervisor deve considerar tenants potencialmente hostis.
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. Januscape recebeu CVSS 8,8 e Bad Epoll 7,8. Os efeitos incluem corrupção, queda do host, elevação local e possível violação da fronteira de virtualização.
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
Confirme kernel e presença do KVM. Em hypervisors, inventarie guests e nested virtualization antes de qualquer tentativa de descarregar módulos.
uname -r
rpm -q kernel --last | head
lsmod | grep -E '^kvm|eventpoll'
ls -l /dev/kvm 2>/dev/null
Kernel abaixo do release da própria major exige atualização. A ausência de KVM reduz a rota Januscape, mas não elimina Bad Epoll. Não descarregue KVM com máquinas virtuais ativas.
Como corrigir ou mitigar
Instale o kernel corrigido e reinicie. Quando o servidor não executa VMs, restringir ou bloquear KVM pode reduzir exposição durante a janela, mas avalie dependências. Em hypervisor, drene guests e preserve capacidade de rollback.
dnf update 'kernel*'
reboot
uname -r
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
Valide inicialização dos guests, rede bridge, storage, módulos, cgroups e serviços. Procure panics, oops, reinicializações sem causa e alterações administrativas. Preserve dumps antes de reiniciar novamente se houve crash.
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
A resposta gerenciada inclui inventário de KVM, comparação do kernel e aplicação via reboot ou KernelCare quando houver livepatch confirmado. O isolamento CloudLinux ajuda na contenção de usuários, e Imunify360 reduz o risco de um site comprometido fornecer o primeiro estágio local.
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.