GhostLock CVE-2026-43499: elevação local de privilégio no kernel Linux

A GhostLock (CVE-2026-43499) é uma falha use-after-free no caminho de rtmutex/futex do kernel Linux. Um usuário local com poucos privilégios pode explorar o ponteiro pendente durante rollback de proxy lock e tentar elevar privilégios. AlmaLinux publicou kernels corrigidos para as linhas 8, 9 e 10.

O que aconteceu

O problema ocorre na operação de requeue de futex com proxy locking. Em uma sequência de erro e rollback, uma estrutura de espera podia manter referência para uma tarefa que já não deveria ser usada. O acesso posterior caracteriza use-after-free e abre caminho para corrupção de memória do kernel.

Futex é uma primitiva central de sincronização. A correção não deve ser substituída por desabilitar aplicações individuais, porque bibliotecas, runtimes e serviços legítimos usam esse mecanismo. A rota é local, mas hospedagem compartilhada e servidores de aplicações executam código de múltiplas origens.

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

A falha requer execução local. Em um servidor dedicado apenas com administradores confiáveis, a barreira é maior; em hosting, CGI/PHP comprometido ou shell de cliente pode fornecer o ponto de partida.

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. CVSS 7,8, com potencial de confidencialidade, integridade e disponibilidade totais após elevação a root. A exigência de acesso local não reduz o impacto em hosts multiusuário.

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

Identifique distribuição, kernel em execução, kernel mais novo instalado e estado do KernelCare. O kernel instalado só protege após reboot, salvo livepatch específico confirmado.

cat /etc/almalinux-release
uname -r
rpm -q kernel --last | head
kcarectl --patch-info 2>/dev/null | grep CVE-2026-43499

Compare o uname com a linha da tabela. Se o RPM novo está instalado, mas uname ainda mostra o antigo, falta inicializar o kernel corrigido. Para livepatch, exija confirmação explícita da CVE no feed aplicável.

Como corrigir ou mitigar

Atualize os pacotes de kernel pelo repositório oficial e reinicie em janela controlada, ou aplique livepatch suportado e valide a cobertura. Não use um kernel de outra major.

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

Após o reboot, valide rede, storage, firewall, cPanel, LVE e aplicações. Revise eventos de kernel, crashes, usuários root, módulos e persistência. Um panic anterior deve ser investigado, não atribuído automaticamente a hardware.

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 gerenciados, a WebinHost compara o kernel ativo com o advisory, confirma KernelCare quando compatível e agenda reboot quando necessário. CloudLinux/CageFS e Imunify360 limitam e detectam etapas do ataque, mas a correção da memória do kernel continua obrigatória.

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

• AlmaLinux — advisory GhostLock
• CVE.org — CVE-2026-43499

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.