Empresas de hospedagem reiniciaram tudo por causa deste bug

Ver no idioma original →

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Hosting Companies Rebooted EVERYTHING Because of This Bug · Canal: Better Stack · 02:36 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Infraestrutura e hardware de IA, Open source e ecossistemas de software

Resumo

Uma vulnerabilidade antiga no código de rede do Linux permitiu que uma máquina virtual pudesse escapar do isolamento e assumir o controle do host. Pesquisadores encontraram a falha em três dias, com análise de código auxiliada por GPT-5.6 Soul, e demonstraram que ela podia levar a acesso root no host. Após a divulgação, provedores de hospedagem correram para aplicar correções e reiniciar servidores. A correção precisa ser instalada no host: atualizar apenas as máquinas virtuais convidadas não resolve o problema.

Pontos-chave

• A falha está no código de rede do Linux no host, não no hypervisor.
• A vulnerabilidade remonta ao Linux 2.6.27, lançado em 2008.
• Um pacote de rede especialmente criado pode explorar uma etapa atrasada de processamento e expor memória do host.
• Os pesquisadores transformaram o vazamento de memória em acesso root ao host em ambiente de laboratório.
• A falha foi identificada como CVE-2026-9999, com severidade 9,3 de 10.
• Vários provedores realizaram manutenção emergencial; a fly.io fez reinicializações escalonadas que duraram quase 33 horas.
• A AWS informou que EC2, Lambda e Fargate não foram afetados.
• A correção precisa ser aplicada ao kernel do host; atualizar as VMs convidadas não basta.
• Quem administra hosts KVM próprios deve verificar se o kernel inclui a correção e reiniciar no kernel corrigido.

Capítulos

Início	Capítulo	Resumo
00:00	A falha e a investigação	Pesquisadores encontraram uma forma de escapar da sandbox da Vercel com ajuda de GPT-5.6 Soul.
00:31	Como a vulnerabilidade funciona	A falha está no código de rede do Linux e pode permitir que uma VM exponha memória e obtenha acesso root no host.
01:03	Impacto e divulgação	A vulnerabilidade ameaça o isolamento entre VMs e levou provedores a iniciar manutenção emergencial após a divulgação.
01:34	Provedores aplicam correções	Provedores como fly.io reiniciaram hosts, enquanto a AWS declarou que alguns de seus serviços não foram afetados.
02:05	Como se proteger e a lição do caso	A correção deve ser aplicada ao host, e qualquer administrador de hosts KVM deve verificar o kernel e reiniciar no sistema corrigido.

Citações

Milhares de engenheiros de empresas de hospedagem no mundo todo tiveram que largar tudo e reiniciar seus servidores. — 00:00

A nuvem inteira se baseia na promessa de que sua VM não pode tocar no servidor que está por baixo dela. — 01:03

A correção precisa ser aplicada ao próprio host, porque atualizar suas VMs convidadas não resolve nada. — 02:05

Manter uma VM dentro de sua caixa depende de muito mais do que o hypervisor. — 02:36

Conceitos e entidades

• Vercel (empresa): Empresa que lançou um desafio de US$ 1 milhão para pesquisadores tentarem escapar de seu produto sandbox.
• pwn.ai (empresa): Equipe que investigou a sandbox da Vercel e encontrou a vulnerabilidade com auxílio de pesquisadores humanos e GPT-5.6 Soul.
• GPT-5.6 Soul (modelo): Modelo que ajudou na análise de código durante a investigação da vulnerabilidade.
• CVE-2026-9999 (conceito): Identificador atribuído à vulnerabilidade de rede do Linux que pode permitir a uma VM escapar para o host.
• Linux (conceito): Sistema cujo código de rede no host continha a vulnerabilidade descrita.
• KVM (conceito): Tecnologia de virtualização citada como opção para quem administra hosts próprios com máquinas virtuais.
• fly.io (empresa): Provedor que realizou reinicializações escalonadas dos hosts da plataforma por quase 33 horas.
• AWS (empresa): A empresa informou que EC2, Lambda e Fargate não foram afetados pela vulnerabilidade.
• KernelCare (ferramenta): Serviço da TuxCare mencionado como opção para distribuir correções em tempo real.

Tradução completa (pt-BR)

00:00 Bem, pessoal, no último fim de semana, milhares de engenheiros de empresas de hospedagem do mundo todo tiveram que largar tudo e reiniciar seus servidores por causa de um único bug do Linux que permite que uma máquina virtual escape e assuma o controle da máquina em que está rodando. Deixe-me explicar. Em agosto, a Vercel lançou um desafio de US$ 1 milhão, convidando pesquisadores a escapar do produto de sandbox da empresa. Uma equipe da pwn.ai — acho que se pronuncia “own.ai” — aceitou o desafio e, com pesquisadores humanos orientando o trabalho e o GPT-5.6 Soul ajudando na análise do código, encontrou uma forma de escapar da sandbox em apenas 3 dias. Eles chamaram isso de

00:31 Pawn Escape ou Own Escape, acho, e agora está registrado como CVE-2026-9999, com uma pontuação de gravidade de 9,3 em 10. A parte surpreendente é onde o bug estava escondido. Quando pensamos em segurança de máquinas virtuais, geralmente pensamos no hipervisor, que é o software que mantém as máquinas virtuais isoladas umas das outras. Mas esse bug está no código de rede do Linux no host e remonta ao Linux 2.6.27, de 2008. Em termos simples, uma máquina virtual pode enviar ao host um pacote de rede especialmente preparado. O host verifica

01:03 esse pacote e decide que ele é seguro, mas uma etapa posterior, que ocorre com atraso, permite que o convidado altere parte desse pacote depois que a verificação já foi feita. Isso engana o host e o faz vazar partes da própria memória. No laboratório da equipe, os pesquisadores transformaram esse vazamento em acesso root completo à máquina host. E isso é muito sério, porque toda a nuvem se baseia na promessa de que sua máquina virtual não pode acessar o servidor em que está hospedada nem as máquinas virtuais dos outros clientes que compartilham o mesmo servidor. A correção foi incorporada ao Linux mainline em 14 de outubro, e o relatório foi publicado no dia seguinte, que era uma quinta-feira. Foi quando começou a

01:34 correria. Paul Yebelo, o pesquisador por trás da descoberta, publicou uma montagem de páginas de status de provedores de hospedagem que estavam todos lidando com o problema ao mesmo tempo. Muitos tiveram que anunciar manutenções emergenciais. A fly.io fez reinicializações graduais dos hosts em toda a plataforma, que duraram quase 33 horas, e um provedor menor chamado Freak Hosting informou que 98 de seus 99 hipervisores tinham recebido a correção, restando apenas um. Mas nem todos foram afetados. A AWS diz que EC2, Lambda e Fargate não foram afetados. E há kernels corrigidos para todas as ramificações estáveis, da 5.10 até a

02:05 7.2. E distribuições como Debian, Ubuntu e RHEL estão incorporando a correção aos próprios kernels. O mais importante é lembrar que o patch precisa ser instalado no próprio host, porque atualizar as máquinas virtuais convidadas não vai resolver nada. E, para quem não pode se dar ao luxo de reiniciar, empresas como a TuxCare estão distribuindo patches em tempo real pelo KernelCare. Então, se você aluga um VPS, é muito provável que seu provedor já tenha resolvido isso. Mas, se você administra seus próprios hosts KVM com máquinas virtuais em que não confia plenamente, verifique se o seu kernel inclui a correção e reinicie usando esse kernel assim que puder. Acho que a lição mais ampla aqui

02:36 é que manter uma máquina virtual dentro dos próprios limites depende de muito mais do que o hipervisor, porque cada parte do host com a qual o convidado pode se comunicar é uma parte que pode ser explorada. Se quiser ficar por dentro das últimas novidades em segurança e engenharia, inscreva-se no canal Better Stack.

Transcrição original

[00:00] Well, folks, last weekend thousands of engineers at hosting companies around the world had to drop everything and reboot their servers all because of one Linux bug that lets a virtual machine break out and take over the machine it’s running on. Let me explain. So, back in August, Vercel launched a $1 million challenge inviting researchers to break out of its sandbox product. And a team at pwn.ai, I guess that is pronounced own.ai, took it on and with human researchers steering the work and GPT-5.6 Soul helping with the code analysis, they found a way out of the sandbox in just 3 days. They called it

[00:31] Pawn Escape or Own Escape, I guess, and it’s now tracked as CVE-2026-9999 with a severity score of 9.3 out of 10. The surprising part is where the bug was hiding. So, when we think about VM security, we usually think about the hypervisor, which is the software that keeps virtual machines walled off from each other. But, this bug lives in the Linux networking code on the host, and it goes all the way back to Linux 2.6.27 from 2008. In simple terms, a virtual machine can send the host a specially crafted network packet. The host checks

[01:03] that packet and decides it’s safe, but a delayed step later on lets the guest change part of that packet after the check has already happened. That tricks the host into leaking pieces of its own memory, and in their own lab, the researchers turned that leak into a full root access on the host machine. And that’s a big deal because the entire cloud is built on the promise that your VM cannot touch the server underneath it or the other customers VMs sharing the same server. The fix was merged into machine Linux on October 14th, and the write-up went public the next day, which was a Thursday, and that’s when the

[01:34] scramble started. Paul Yebelo, the researcher behind it, posted a collage of status pages from hosting providers all dealing with it at the same time. A lot of them had to announce emergency maintenance. fly.io ran platform-wide rolling host reboots that lasted almost 33 hours, and a smaller provider called Freak Hosting reported that 98 of its 99 hypervisors were patched with one still left to go. Not everyone got hit though. AWS says EC2, Lambda, and Fargate aren’t affected. And patched kernels are out for every stable branch from 5.10 up to

[02:05] 7.2. And distributions like Debian, Ubuntu, and RHEL are rolling the fix into their kernels. The most important thing to remember is that the patch has to go on the host itself because updating your guest VMs won’t fix anything. And for anyone who can’t afford a reboot, companies like TuxCare are shipping live patches through KernelCare. So, if you’re renting a VPS, your provider has most likely handled this already. But if you run your own KVM hosts with VMs you don’t fully trust, check that your kernel includes the fix and reboot into it as soon as you can. I guess the bigger lesson here

[02:36] is that keeping a VM inside its box depends on a lot more than the hypervisor because every part of the host that the guest can talk to is a part that can be exploited. If you want to stay up-to-date with the latest in security and engineering, be sure to subscribe to the Better Stack channel.