Uma falha crítica recém-divulgada no kernel do Linux permite que código executado dentro de uma máquina virtual leia a memória do computador hospedeiro. Um pesquisador demonstrou o vazamento nas sandboxes de produção da Vercel, que confirmou o problema.
Identificada como
CVE-2026-99999
e apelidada de PwnEscape, a falha está no código de rede do kernel do Linux, e não na configuração de um serviço específico de cloud. Por isso, afeta uma camada compartilhada que provedores de cloud usam para isolar as cargas de trabalho dos clientes.
A vulnerabilidade foi descoberta durante um desafio de segurança da Vercel e comunicada à empresa de forma privada, antes de qualquer divulgação pública. Não há indícios de que tenha sido usada em ataques reais.
O que o pesquisador demonstrou
Paulos Yibelo, da empresa de segurança pwn.ai, identificou que pacotes de rede especialmente preparados e enviados de dentro de uma máquina virtual poderiam permitir três ações, segundo um relatório técnico: ler a memória da máquina hospedeira, derrubá-la e executar código nela. As três possibilidades decorrem da mesma falha no kernel.
Em seu relatório sobre o desafio, a Vercel informou que o vazamento de memória foi demonstrado em suas sandboxes de produção. Cada pacote enviado pela máquina virtual podia retornar cerca de 32 bytes da memória da máquina hospedeira. O processo poderia continuar enquanto novos pacotes fossem enviados.
A queda da máquina hospedeira e a execução de código foram observadas apenas nos equipamentos do pesquisador, configurados para reproduzir o ambiente da Vercel. Dois pacotes especialmente preparados foram suficientes para derrubar uma máquina hospedeira e interromper todas as sandboxes em execução nela.
Com a mesma falha, o pesquisador também obteve controle administrativo da máquina hospedeira, escapando da máquina virtual. Ele ressaltou que esse resultado foi obtido em laboratório e “não é uma afirmação de execução de comandos como superusuário em ambientes de produção de qualquer fornecedor”.
“ Nossa pesquisa foi conduzida por meio do Omega-Pwn, uma estrutura interna que combina nossas próprias ferramentas de pesquisa de segurança com elementos da arquitetura OmegaClaw, da SingularityNET. Ela nos permitiu reunir hipóteses, rastros de código, tentativas malsucedidas e resultados experimentais ao longo de sessões de pesquisa prolongadas. O GPT-5.6 Sol foi o principal mecanismo de raciocínio. Nós conduzimos a investigação, questionamos as descobertas e validamos as mais relevantes com base no comportamento real do kernel em sistemas sob nosso controle”, disse Paulos Yibelo ao The Hacker News.
A Vercel afirmou que nenhum relatório enviado ao desafio demonstrou a leitura de arquivos, segredos ou dados de aplicações de clientes.
Gravidade e condições para explorar a falha
Os mantenedores do kernel atribuíram à vulnerabilidade a identificação
CVE-2026-99999
e, no registro publicado, uma nota de 9,3 em 10, classificada como Crítica. A NVD já havia recebido o registro, mas ainda não concluído sua própria análise.
O mesmo registro classifica o vetor de ataque como local. Em outras palavras, o invasor precisa primeiro conseguir executar código dentro de uma máquina virtual, como fez o pesquisador. Não é uma falha que possa ser explorada por alguém de fora apenas com o envio de pacotes pela internet pública.
A vulnerabilidade não consta no catálogo da CISA de falhas exploradas ativamente, e não há relatos de uso no mundo real.
Por que o problema vai além da Vercel
O Vercel Sandbox executa o código de cada cliente em sua própria microVM Firecracker, uma máquina virtual pequena com uma cópia própria do kernel do Linux, hospedada em servidores físicos da Amazon EC2. Essa microVM funciona como uma barreira entre cada cliente e a máquina hospedeira, além de separar os ambientes dos diferentes clientes.
A falha não está nessa barreira, mas no código de rede do kernel do Linux executado pela máquina hospedeira. A pwn.ai afirmou que o ambiente da Vercel já tinha proteções acima dos padrões normalmente adotados pelo setor e que não identificou erros de configuração.
Como quase todos os grandes provedores de cloud isolam as cargas de trabalho dos clientes na mesma camada do kernel do Linux, a Vercel alertou que uma falha nesse componente representa um risco para a infraestrutura compartilhada, e não apenas para um provedor específico.
A correção e as versões corrigidas
A correção consiste em uma única alteração no kernel do Linux, identificada pelo commit 6785011f8b16, de autoria de Michael S. Tsirkin, da Red Hat, e incorporada ao kernel principal. Ela verifica se os metadados de checksum de um pacote apontam para o cabeçalho IPv4 antes de o kernel processá-lo. A verificação foi aplicada em cinco pontos do código de rede.
A correção é intencionalmente parcial. Seu autor a descreve como “uma medida de defesa em profundidade” e observa que ainda é necessário aprimorar uma verificação mais abrangente na entrada dos pacotes no kernel.
Os mantenedores incorporaram a correção aos ramos estáveis do kernel. De acordo com o registro da CVE, estas são as primeiras versões corrigidas em cada ramo com suporte:
| Ramo estável | Primeira versão corrigida |
|---|---:|
| 5.10 | 5.10.272 |
| 5.15 | 5.15.223 |
| 6.1 | 6.1.190 |
| 6.6 | 6.6.159 |
| 6.12 | 6.12.113 |
| 6.18 | 6.18.57 |
| 7.2 | 7.2.11 |
As distribuições do Linux fornecem seus próprios kernels e, muitas vezes, incluem esse tipo de correção sem alterar o número da versão. Por isso, consulte o aviso de segurança da sua distribuição e confirme se a correção está no kernel realmente executado pela máquina hospedeira, em vez de verificar apenas o número exibido pelo comando `uname`.
O que fazer
Atualize o kernel da máquina hospedeira para uma das versões corrigidas acima ou para uma versão fornecida pelo fabricante que inclua a correção. Em seguida, reinicie o sistema usando o kernel atualizado. Atualizar apenas o kernel da máquina virtual não corrige o problema na máquina hospedeira. As fontes não indicam uma solução alternativa específica para essa falha caso a atualização ainda não seja possível.
Enquanto a instalação da correção não for possível, a medida habitual é limitar o que uma invasão poderia alcançar. A Vercel afirmou que mantém os kernels das máquinas hospedeiras atualizados, desativa a virtualização aninhada e executa cada microVM com o mecanismo de isolamento do Firecracker, que concede ao processo da máquina virtual apenas as permissões necessárias. Essas medidas não corrigem a falha, mas restringem o que um invasor poderia fazer caso a explorasse.
Falha descoberta em desafio de US$ 1 milhão
A vulnerabilidade foi encontrada durante um desafio de duas semanas promovido pela Vercel em agosto. A empresa ofereceu até US$ 1 milhão no total a quem conseguisse escapar de sua sandbox, mas nenhum pagamento individual chegou a esse valor. A maior recompensa por um único relatório foi de US$ 50.000. Ao todo, a Vercel pagou US$ 242.000 por 1.285 relatórios, e essa vulnerabilidade foi a única descoberta classificada como Crítica.
A pwn.ai afirmou ter encontrado a falha em três dias, usando seu próprio sistema de pesquisa assistida por IA. O modelo analisou o código-fonte, enquanto pesquisadores humanos conduziram o trabalho. A empresa estimou o custo em menos de US$ 700 em tokens de API. O caso é o mais recente em que pesquisadores usam um modelo de linguagem de grande porte para ajudar a encontrar e combinar falhas reais. No início deste ano, outra equipe usou um modelo desse tipo para acessar sistemas internos da OpenAI.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...