Um usuário local sem privilégio nenhum. Cinco segundos. Root completo. E o pior: isso funciona em basicamente toda distribuição Linux que existe desde 2011.

A vulnerabilidade se chama GhostLock (CVE-2026-43499) e ficou escondida no kernel Linux por mais de 15 anos, desde a versão 2.6.39. Pesquisadores da Nebula Security encontraram o bug usando uma ferramenta automatizada chamada VEGA, desenvolveram um exploit com 97% de taxa de sucesso e ainda ganharam US$ 92.337 do Google pelo achado. O proof-of-concept já está público no GitHub.

Se você administra servidores Linux, roda containers em produção ou simplesmente usa Linux no desktop, esse artigo é leitura obrigatória.

O que é o GhostLock?

GhostLock é uma vulnerabilidade do tipo use-after-free no código de mutex em tempo real (rtmutex) do kernel Linux. Mais especificamente, o problema está na função remove_waiter() dentro do arquivo kernel/locking/rtmutex.c, que faz parte do subsistema de futex com herança de prioridade (PI).

Em termos simples: quando uma thread desiste de esperar por um lock, o kernel precisa fazer uma “limpeza” nos registros internos. Essa rotina de limpeza foi escrita com uma suposição que parecia razoável na época: que a thread fazendo a limpeza é sempre a mesma que “donos” do pedido de lock.

Acontece que existe um caminho específico no código, o requeue-PI proxy path, onde essa suposição não vale. Quando o kernel detecta um deadlock e tenta desfazer a operação, ele limpa os registros da thread errada. O resultado? Um ponteiro fica “pendurado” apontando para uma região de memória do kernel que já foi liberada.

Esse ponteiro fantasma (daí o nome “GhostLock”) é a porta de entrada para o exploit.

Por que isso é tão grave?

Três motivos fazem o GhostLock ser especialmente perigoso:

1. Não precisa de privilégio nenhum

O atacante não precisa ser root, não precisa de capabilities especiais, não precisa de acesso à rede. Basta ser um usuário local comum, executando syscalls de threading que qualquer programa pode chamar. O CVSS é 7.8 (alto), classificado assim apenas porque exige acesso local.

2. Funciona em praticamente todo Linux

A única dependência é CONFIG_FUTEX_PI=y, uma opção de compilação que vem ativada por padrão em essencialmente toda distribuição. Ubuntu, Debian, Fedora, RHEL, SUSE, Arch, Alpine: todos vulneráveis. Se roda Linux e foi lançado depois de 2011, está no escopo.

3. Escapa de containers

Não é só escalar privilégio na máquina local. O exploit também permite escapar de ambientes containerizados. Para quem roda workloads em Docker, Kubernetes (ou Podman) ou qualquer runtime de container, isso significa que um processo dentro de um container pode virar root no host. Em ambientes multi-tenant e cloud, isso é um cenário de pesadelo.

Como o exploit funciona (sem simplificar demais)

A cadeia de exploração do GhostLock envolve várias etapas criativas. Vou descrever cada uma porque o trabalho técnico da Nebula Security é genuinamente impressionante.

Passo 1: Obter o ponteiro fantasma

O atacante usa syscalls normais de threading (FUTEX_WAIT_REQUEUE_PI e companhia) para acionar o bug no remove_waiter(). Quando o kernel faz o rollback de uma operação de lock que detectou deadlock, ele limpa pi_blocked_on na thread errada (o requeuer, ao invés do waiter).

O resultado: a task do waiter volta para o userspace com pi_blocked_on ainda apontando para um rt_mutex_waiter que estava na stack frame da chamada FUTEX_WAIT_REQUEUE_PI. Essa stack frame já foi liberada. Ponteiro fantasma no kernel, acessível via syscalls comuns.

Passo 2: Vazar KASLR via prefetch

Com o ponteiro fantasma em mãos, os pesquisadores usaram técnicas baseadas em prefetch para vazar o layout de memória do kernel, quebrando o KASLR (Kernel Address Space Layout Randomization). Isso é necessário porque o kernel randomiza endereços de memória justamente para dificultar exploits.

Passo 3: Manipular a CPU entry area

O exploit manipula a CPU entry area do kernel, uma região de memória usada durante transições entre userspace e kernel. Isso permite controlar o fluxo de execução durante operações críticas do kernel.

Passo 4: Recuperar o stack frame via PR_SET_MM_MAP

Usando a syscall prctl com PR_SET_MM_MAP, os pesquisadores conseguem “reclamar” a região de stack liberada, colocando dados controlados no lugar do ponteiro fantasma. Agora o kernel vai ler dados que o atacante escolheu quando tentar usar aquele ponteiro.

Passo 5: DirtyMode para root

A técnica final, chamada “DirtyMode” pelos pesquisadores, altera bits de permissão para transformar o usuário sem privilégio em root. O exploit inteiro leva cerca de 5 segundos para executar e tem 97% de taxa de sucesso nos testes.

A timeline: de 2011 até hoje

Repara que entre o report e o fix foram apenas 2 dias. A equipe do kernel foi rápida. O problema é que entre a introdução do bug e sua descoberta foram 15 anos. Quinze anos em que qualquer pessoa com acesso local a uma máquina Linux poderia, em tese, ter explorado isso.

IonStack: a cadeia completa

GhostLock não existe isolado. Ele é a segunda metade de uma cadeia de exploit que a Nebula Security batizou de IonStack.

A primeira metade é o CVE-2026-10702, uma vulnerabilidade no Firefox que permite executar código e escapar do sandbox do navegador. Combinando as duas:

1. Usuário clica em um link malicioso no Firefox
2. CVE-2026-10702 executa código fora do sandbox do navegador
3. GhostLock escala para root no sistema operacional

Do clique ao root, tudo automatizado. A Nebula já demonstrou isso funcionando no Firefox rodando em Android. Um toque na tela, root completo no dispositivo (lembra do exploit do Pixel 10?). Isso afeta desde celulares até servidores, passando por dispositivos IoT.

Quem é a Nebula Security e o que é o VEGA?

A Nebula Security é uma empresa de pesquisa em cibersegurança que desenvolveu o VEGA, uma ferramenta de análise automatizada de vulnerabilidades no kernel. Foi o VEGA que encontrou o GhostLock, e esse detalhe merece atenção.

O kernel Linux tem mais de 30 milhões de linhas de código. Milhares de desenvolvedores contribuem ativamente. O subsistema de rtmutex é revisado por alguns dos engenheiros mais experientes do mundo. Mesmo assim, um bug crítico sobreviveu 15 anos sem ninguém notar. A ferramenta automatizada encontrou em análise o que revisão humana não pegou em uma década e meia.

Isso levanta uma questão cada vez mais relevante: estamos entrando em uma era onde análise automatizada (e possivelmente assistida por IA) é necessária para manter a segurança de codebases gigantes. A complexidade do software moderno já passou do ponto onde revisão manual é suficiente.

O Google premiou a equipe com US$ 92.337 pelo programa kernelCTF, o que dá uma ideia do impacto: não é todo dia que um bug-bounty de kernel paga quase cem mil dólares. Para referência, o valor médio de bounties do kernelCTF fica bem abaixo disso.

O que você precisa fazer agora

Se você administra servidores

# Verificar a versão do kernel
uname -r

# Verificar se CONFIG_FUTEX_PI está ativo (spoiler: provavelmente sim)
zcat /proc/config.gz 2>/dev/null | grep CONFIG_FUTEX_PI || grep CONFIG_FUTEX_PI /boot/config-$(uname -r)

As versões corrigidas são:

# No Ubuntu/Debian
sudo apt update && sudo apt upgrade -y linux-image-generic

# No Fedora/RHEL
sudo dnf upgrade kernel -y

# No Arch
sudo pacman -Syu linux

Priorize máquinas compartilhadas, servidores multi-tenant, hosts de containers e runners de CI/CD. Esses são os alvos mais atraentes porque têm muitos usuários locais ou processos não confiáveis rodando.

Se você usa containers em produção

O fato de o GhostLock escapar de containers significa que atualizar a imagem do container não resolve. Você precisa atualizar o kernel do host. Orquestrador de containers (Kubernetes, Docker Swarm, ECS) não protege contra isso porque a vulnerabilidade está no kernel, abaixo de qualquer camada de isolamento que o container runtime oferece.

# Verificar kernel do host (não do container)
uname -r

# Em clusters Kubernetes, verificar cada node
kubectl get nodes -o wide

Mitigações parciais

Se por algum motivo você não pode atualizar o kernel imediatamente, duas opções de build oferecem proteção parcial (mas incompleta):

• RANDOMIZE_KSTACK_OFFSET: randomiza o offset da stack do kernel, dificultando a reclamação do stack frame
• STATIC_USERMODE_HELPER: limita quais binários usermode o kernel pode executar

Essas não são soluções definitivas. São band-aids enquanto você agenda a atualização.

O contexto maior: kernel bugs estão acelerando

GhostLock não está sozinho. 2026 trouxe uma safra preocupante de vulnerabilidades de escalonamento de privilégio no kernel Linux:

• Bad Epoll (CVE-2026-46242): outro bug no subsistema de epoll que permite root. Primo do GhostLock em termos de impacto.
• Copy Fail (CVE-2026-31431): já observado em ataques reais segundo a CISA. Esse é o mais preocupante porque passou da teoria para a prática.

O padrão é claro: ferramentas automatizadas de análise (como o VEGA) estão encontrando classes inteiras de bugs que revisão humana de código não pegou por décadas. Já vimos isso com o Squidbleed no Squid Proxy, que ficou 29 anos escondido. Isso é simultaneamente assustador (quantos mais existem?) e promissor (pelo menos estão sendo encontrados antes que atacantes os explorem em massa).

Para quem trabalha com segurança ou infraestrutura, a lição prática é que o ciclo de patching precisa ser mais agressivo. Esperar a “janela de manutenção mensal” para aplicar patches de kernel não é mais aceitável quando exploits saem com PoC público dias após o disclosure. O tempo entre “vulnerabilidade publicada” e “exploit weaponizado” está diminuindo a cada ano.

O PoC está público. E agora?

A Nebula Security publicou o proof-of-concept no GitHub: github.com/NebuSec/CyberMeowfia/tree/main/IonStack/CVE-2026-43499.

Código de exploit público é uma faca de dois gumes. Por um lado, permite que defensores testem se seus sistemas estão vulneráveis. Por outro, baixa drasticamente a barreira para atacantes. Até agora, não há evidência de exploração ativa no wild, mas com o PoC circulando, é questão de tempo.

A recomendação é simples e urgente: atualize o kernel. Não amanhã, não na próxima janela de manutenção. Hoje. Se você tem um processo de aprovação para patches de kernel, esse é o tipo de CVE que justifica uma exceção.

Impacto em cloud providers e serviços gerenciados

Se você usa serviços gerenciados como AWS EC2, Google Compute Engine ou Azure VMs, a responsabilidade de atualizar o kernel é sua (no modelo de responsabilidade compartilhada). O cloud provider cuida da infraestrutura física, mas o kernel dentro da sua VM é problema seu.

Já para serviços serverless (Lambda, Cloud Functions, Cloud Run), o patching do kernel é responsabilidade do provider. AWS, Google e Azure já aplicaram correções nos seus ambientes gerenciados, mas vale confirmar se o seu provider específico já atualizou. Serviços menores podem demorar mais.

Para quem usa Kubernetes gerenciado (EKS, GKE, AKS), verifique a versão do kernel nos nodes:

# GKE
gcloud compute ssh NODE_NAME -- uname -r

# EKS
aws ssm start-session --target INSTANCE_ID
uname -r

# AKS
kubectl debug node/NODE_NAME -it --image=busybox -- uname -r

A maioria dos providers já tem patches disponíveis, mas a atualização dos nodes nem sempre é automática. No GKE, por exemplo, você pode precisar forçar um upgrade do node pool.

Um detalhe que quase ninguém mencionou

O patch inicial que corrigiu o GhostLock introduziu um bug separado (CVE-2026-53166) que causava crash em determinadas condições. Correções adicionais ainda estavam sendo estabilizadas no upstream no início de julho. Por isso, ao atualizar, verifique se está pegando o pacote mais recente da sua distribuição, não apenas “um kernel com o fix do GhostLock”. As distros geralmente esperam os fixes complementares antes de liberar o pacote final.

# Verificar o changelog do pacote do kernel
apt changelog linux-image-generic 2>/dev/null | head -30
# ou
rpm -q --changelog kernel | head -30

Quinze anos. Um bug dormindo em bilhões de dispositivos, de smartphones Android a servidores que processam transações financeiras. Encontrado não por um humano revisando código, mas por uma ferramenta automatizada. Explorado em 5 segundos com 97% de sucesso. Se isso não é motivo para levar patching a sério, eu sinceramente não sei o que seria.

Fonte de inspiração: IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years