Fly.io aplica patch e reinicia toda a frota após bug no kernel Linux que expunha memória do host

O CVE-2026-99999 nasce de um recurso de performance: o checksum offload. Em vez de calcular o checksum de TCP ou UDP na hora, o kernel guarda metadados dizendo de onde ler e onde escrever. Em VMs, a placa de rede virtual aceita esses metadados do guest e os repassa ao host, que trata o pacote como qualquer outro offloaded. As verificações que deveriam rejeitar metadados ruins estavam erradas para IPv4.

Para explorar, o invasor aponta o checksum para outro campo do cabeçalho, escolhe uma mensagem que gere o valor desejado e força o host a calcular o checksum em software. O resultado é a escrita de dois bytes num cabeçalho IPv4 que o host já havia validado. Um rewrite no IP de origem ou destino cai depois de roteamento e firewall, o que dá o bypass. Um rewrite no tamanho do cabeçalho faz o host tratar memória adjacente como opções do pacote, capturando 32 bytes de memória (pacotes do host, estruturas do kernel, tráfego da VM vizinha). A Fly.io diz que dados de clientes provavelmente não foram expostos, mas não descarta a possibilidade teórica e recomenda rotacionar credenciais enviadas sem criptografia entre 15 e 17 de outubro, inclusive na rede privada 6PN.

Por que reiniciar tudo? Detectar é difícil: pacotes de bypass podem ser bem formados, e o rewrite acontece depois das regras XDP existentes. Desligar o checksum offload no host também exigiria reboot, então a empresa foi direto para o kernel com patch. Cada host leva de 15 a 20 minutos para voltar, e a colocação aleatória de Machines impedia reiniciar mais de um host por vez sem derrubar apps inteiros. A solução foi dividir cada região em ondas, de modo que nenhum cluster de Managed Postgres tivesse os dois nós na mesma onda. Só a região iad precisou de 17 ondas. Alguns hosts travaram na BIOS ou precisaram de reinstalação, e um chassi de quatro nós em gru perdeu a fonte, deixando Machines fora até 20 de outubro.

A cobertura anterior ajuda a ligar os pontos. Em 20 de outubro de 2026, o CEVIU noticiou "Falha Crítica em KVM Permite Escape de Máquina Virtual para Host", sobre a vulnerabilidade batizada de PwnEscape, que permite a uma VM guest não confiável manipular cabeçalhos IPv4 após a validação no kernel do host. A descrição bate com o mecanismo relatado pela Fly.io, mas o material não confirma que PwnEscape e CVE-2026-99999 sejam o mesmo identificador. Agora o que temos é o lado operacional: como um provedor aplicou o patch em produção, em 10 horas, e o que ficou de fora do plano.

Em 26 de agosto de 2026, o CEVIU noticiou "DigitalOcean Corrige Vulnerabilidades Críticas em Hypervisors Sem Interrupção para Clientes", com correção de frota sem impacto aparente. O caso da Fly.io é o contraste: reboot de host com downtime de 15 a 20 minutos por Machine.

Para quem opera plataforma, o recado é que o isolamento por virtualização não é garantia absoluta, e a mitigação de um bug de host pode ser um reboot em massa. Para quem roda na Fly.io ou em provedor parecido, vale testar agora se a rotação de credenciais cabe em minutos, se o tráfego interno está cifrado e se apps com uma única Machine toleram janela de manutenção. É uma leitura editorial, mas o ponto de plaintext na rede privada tende a ser o mais barato de corrigir.