Kernel do Linux permite leitura de memória do host a partir de uma VM; adesivo CVE-2026-99999.

A comunidade de segurança confirmou uma vulnerabilidade crítica no código de rede do kernel Linux que permite a código que já é executado dentro de uma máquina virtual (VM) ler memória do equipamento físico que a hospeda e, em laboratório, avançar até provocar falhas e executar código nesse host. A falha foi descoberta por pesquisadores de pwn.ai durante um desafio de segurança organizado por Vercel, foi relatada em privado aos responsáveis e recebeu a referência CVE-2026-99999 e a qualificação 9.3 (Crítica) no registro público.

O que aconteceu (fatos confirmados): Paulos Yibelo, pesquisador de pwn.ai, demonstrou que pacotes de rede especialmente construídos enviados do interior de uma microVM podiam filtrar bytes da memória do host; cada pacote podia devolver cerca de 32 bytes e o processo podia ser repetido. Vercel confirmou a demonstração contra seus sandboxes em produção e disse que não há indícios de que ninguém leu dados de clientes no programa de recompensas. Os mantenedores do kernel aplicaram um adesivo (commit 6785011f8b16) que adiciona verificações para que os dados de checksum de um pacote não apontem dentro do cabeçalho IPv4; essa mudança foi integrada no ramo principal e retroportada a ramos estáveis. O registo público da falha classifica-o como vectores “locales”: o atacante precisa de poder executar código dentro da VM afetada; não é um vetor de exploração remoto simplesmente enviando pacotes da Internet.

Como funciona tecnicamente (explicado com cautela): O problema reside na validação insuficiente de certas estruturas usadas pela pilha de rede do kernel ao processar checksums e referências dentro de pacotes IPv4. Se o kernel seguir referências dentro do próprio pacote sem verificar que não apontam regiões indevidas do cabeçalho, um pacote malformado pode induzir leituras fora dos limites previstos. Essas leituras podem exfiltrar fragmentos de memória do espaço do kernel do host para a VM, e em condições controladas a mesma falha pode provocar corrupção de memória que derive em quedas do host ou em possibilidade de controle de execução. O adesivo introduz uma verificação adicional em cinco pontos do código de rede para bloquear referências de checksum que apontem dentro do cabeçalho IPv4; a solução é qualificada por seu autor como uma medida de "defesa em profundidade" e requer trabalho adicional para uma verificação mais precoce na entrada de pacotes.

Quem afeta e por que importa: O risco principal recai sobre ambientes de nuvem e qualquer infraestrutura em que vários inquilinos compartilhem o mesmo kernel do Linux no host (ou seja, a camada que executa e gerencia VMs ou microVMs). Vercel usa microVMs Firecracker sobre hosts bare-metal na Amazon EC2; o falha não está no Firecracker, mas no kernel que corre no host, pelo que qualquer fornecedor que use uma pilha similar pode ser afetado até que o adesivo esteja aplicado em seus kernels de host. Por outro lado, o vetor requer que o atacante já execute código dentro de uma VM; não é uma vulnerabilidade explorável simplesmente de fora por um atacante que envia pacotes da Internet.

O que demonstraram em laboratório e o que é incerto: Em laboratório pwn.ai mostrou leitura contínua de memória (~32 bytes por pacote), dois pacotes bastaram para fazer cair um host e, com configurações replicadas, conseguiram controle administrativo do host. Vercel confirma a fuga de memória em sua produção, mas esclarece que não há evidência de que dados de clientes fossem lidos em seus relatórios ao desafio. Esses avanços em “eixocução de código no host” e “controle administrativo” foram reproduzidos pelo pesquisador em máquinas configuradas para imitar a plataforma de Vercel; ambos os pontos são reclamações da equipe pesquisador e, como eles mesmos sublinham, correspondem a resultados laboratoriais mais do que a explorações observadas fora do ambiente controlado. Não há, até agora, relatórios públicos verificados de exploração no mundo real.

Parche e estado de implantação: A mudança principal está disponível no ramo principal do kernel e foi retroportado para ramos estáveis; seu autor foi Michael S. Tsirkin (Red Hat). Administradores de sistemas e fornecedores devem aplicar a atualização do kernel nos hosts físicos ou builds do fornecedor que incluam o adesivo e reiniciar os hosts para que a correção entre em vigor. É importante verificar os avisos da própria distribuição ou do fornecedor da imagem, porque algumas distribuições introduzem correcções sem alterar o número de versão declarado por umame; por conseguinte, confirme que o adesivo concreto está presente no binário que corre o host e não se baseia apenas na versão numérica. Para referência técnica do patch consulte o repositório do kernel: commit 6785011f8b16, e para o contexto de microVM usado por Vercel veja Firecracker: https://github.com/firecracker-microvm/firecracker. Consulte também a entrada pública do CVE na base de dados nacional: https://nvd.nist.gov/vuln/detail/CVE-2026-99999.

Recomendações concretas para administradores e responsáveis pela nuvem: atualize quanto antes os kernels de host aos builds que incluam o adesivo e reprograme/reinicie hosts para arrancar com a versão corrigida; verifique com seu fornecedor que os hosts públicos receberam a correção. Não basta atualizar kernels de convidados: o falha está no kernel do host. Se você não puder corrigir imediatamente, reduza o risco de escalada: limite a capacidade de inquilinos não verificados para executar código arbitrário em VMs, desative recursos desnecessários como virtualização aninhada, aplique controles de rede estritos a VMs que executem código não confiável e use mecanismos de isolamento adicionais (jailers, políticas de permissões mínimas). Audite logs e padrões de tráfego das VMs para detectar rajadas incomuns de pequenos pacotes originados em convidados (indicadores coerentes com a técnica de exfiltração por pacotes repetidos).

Recomendações para desenvolvedores e usuários de serviços na nuvem: Se você usar plataformas gerenciadas, consulte seus avisos e confirme que o fornecedor aplicou a correção aos hosts que alojam seus encargos. Para operações críticas que exijam confidencialidade máxima, considere solicitar alojamento em hosts dedicados ou em instâncias físicas isoladas até que a maioria dos fornecedores tenha colocado o adesivo. Mantenha segredos e chaves rotadas periodicamente como prática de mitigação ante possíveis vazamentos não detectadas.

A descoberta é também um lembrete de que a dimensão “compartilhada” do kernel em ambientes multiinquilino é uma superfície de risco e que a manutenção e implantação rápida de correções na camada de host são essenciais. O caso ilustra ainda como ferramentas avançadas, incluindo modelos de linguagem no processo de pesquisa, estão acelerando a identificação de vulnerabilidades: pwn.ai afirma ter usado sua plataforma assistida por IA para encontrar e encadear a falha em dias e com custo reduzido, nota relevante para organizações que defendem infra-estruturas comuns.