Dirty Frag reúne a CVE-2026-43284 no processamento ESP/IPsec e a CVE-2026-43500 no rxrpc. Ambas envolvem alteração em lugar de fragmentos de memória paginada pertencentes a outro contexto, criando risco de corrupção e elevação local de privilégio.
O que aconteceu
O kernel pode construir pacotes com fragmentos referenciando páginas que também pertencem ao page cache ou a outro subsistema. Esses fragmentos deveriam ser copiados antes de descriptografar ou modificar. Nos caminhos vulneráveis, a escrita ocorria diretamente e alterava memória compartilhada.
A CVE-2026-43284 alcança AlmaLinux 8, 9 e 10 pelo ESP. A CVE-2026-43500 alcança 9 e 10 quando kernel-modules-partner fornece rxrpc; AlmaLinux 8 não distribui esse módulo. As duas correções foram coordenadas nos releases listados.
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 — ESP | anterior a 4.18.0-553.123.2.el8_10 | 4.18.0-553.123.2.el8_10+ |
| AlmaLinux 9 — ESP/rxrpc | anterior a 5.14.0-611.54.3.el9_7 | 5.14.0-611.54.3.el9_7+ |
| AlmaLinux 10 — ESP/rxrpc | anterior a 6.12.0-124.55.3.el10_1 | 6.12.0-124.55.3.el10_1+ |
| AlmaLinux Kitten 10 | anterior a 6.12.0-226.el10 | 6.12.0-226.el10+ |
A CVE-2026-43284 tem CVSS 8,8; a CVE-2026-43500, 7,8. Mesmo sem rxrpc, o caminho ESP mantém as linhas suportadas em escopo conforme o advisory.
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. O resultado pode incluir exposição/corrupção de dados e privilégio local elevado. A complexidade difere entre caminhos, mas hosts compartilhados executam código não confiável por definição operacional.
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
Leia o kernel ativo, pacotes disponíveis e o módulo parceiro. Não interprete ausência de módulo carregado como prova de patch.
uname -r
rpm -q kernel --last | head
rpm -q kernel-modules-partner 2>/dev/null
lsmod | grep -E 'rxrpc|esp4|esp6'
Compare o release completo com a tabela. Um kernel novo apenas instalado ainda exige reboot, a menos que o livepatch esteja confirmado. AlmaLinux 8 não ter rxrpc elimina somente a segunda CVE nessa rota.
Como corrigir ou mitigar
Aplique a atualização oficial e reinicie. Evite desabilitar IPsec em servidores que dependem de VPN. Se usar KernelCare, consulte a cobertura do kernel e da CVE, pois a presença do agente não garante que todo patch exista para todo build.
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 VPN, firewall, rede, aplicações e módulos. Procure erros de memória e eventos inesperados no journal. Uma falha anterior pode exigir coleta de vmcore e investigação de privilégio, não apenas novo reboot.
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
Ambientes gerenciados são comparados com os builds do advisory e recebem livepatch ou kernel completo conforme compatibilidade. Imunify360 ajuda a impedir que uma aplicação vulnerável vire o ponto de entrada local, enquanto CloudLinux/CageFS reduz movimentos entre contas.
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.