A parede entre inquilinos tinha uma fenda

A promessa silenciosa de todo o servidor na nuvem e de todo o servidor privado virtual é a separação. A sua máquina e a do desconhecido que paga ao mesmo fornecedor correm no mesmo hardware físico, e uma camada chamada KVM, integrada no kernel do Linux, é o que as mantém apartadas. Januscape, registada como CVE-2026-53359, é uma fenda nessa parede. É uma condição de corrida na forma como o KVM gere as shadow page tables, o mapa interno que traduz a memória de uma máquina convidada em memória real. Com a falha, o host pode associar uma dessas entradas ao frame de convidado errado, uma confusão de número de frame e de tipo que, conduzida com cuidado, permite a uma máquina virtual hostil empurrar o host a mapear a memória que o atacante escolhe. Isto é uma fuga de convidado para host: o inquilino sai da sua caixa para o chão que todos partilham.

O que a torna grave é o alcance. A falha está em código comum aos processadores Intel e AMD, pelo que dispara com VMX e EPT de um lado e SVM e NPT do outro. Foi introduzida em 2010 e ficou latente dezasseis anos, o que significa que quase todos os kernels Linux lançados nesse período a levam. Foi divulgada a 6 de julho na lista pública oss-security, corrigida a montante a 16 de junho, e os kernels estáveis corrigidos, as versões 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 e 5.10.260, só chegaram a 4 de julho.

Porque corrigimos agora tem duas respostas

O perigo invulgar aqui não é a falha, é a forma do remédio. Fechar Januscape exige dois commits acoplados a montante, não um: a correção da fuga que leva CVE-2026-53359 e uma correção acompanhante de número de frame que leva CVE-2026-46113. Aplicando apenas a primeira, a do nome memorável, a porta fica entreaberta. Um administrador que leu o aviso em destaque, aplicou esse único patch e fechou o pedido fez o razoável e continua exposto. Por isso uma frase de rotina, já corrigimos, deixa de resolver o assunto nesta falha.

Para um proprietário a exposição raramente é o seu próprio rack de servidores. É o fornecedor por baixo dos seus fornecedores: o host VPS que corre o seu site, a nuvem privada que corre o seu software de negócio, a plataforma gerida que corre os seus dados. Em Portugal, o Centro Nacional de Cibersegurança é a via de notificação, e a NIS2 impõe a mesma expectativa: continua a responder pela segurança dos serviços prestados em seu nome. Uma fuga de hipervisor é exatamente o tipo de falha de infraestrutura partilhada para que essas regras foram escritas, porque um host sem patch pode desfazer a separação por que mil clientes estavam a pagar.

A pergunta ao seu fornecedor de alojamento esta semana

Para a maioria dos proprietários isto não é uma tarefa de compilar kernel, é uma pergunta de compras feita com clareza. Coloque a quem corre as suas máquinas virtuais, seja um host VPS, uma equipa interna de nuvem privada ou um fornecedor de plataforma gerida, três coisas: o kernel do host está agora numa versão estável corrigida ou num patch a quente; essa correção inclui os dois commits, o da fuga e o seu acompanhante; e quando foi aplicada. Não há nenhum interruptor de configuração que torne isto seguro. Um kernel corrigido com reinício, ou um patch a quente aplicado sem ele, é a única resposta completa, e até estar no lugar, todo o host multi-inquilino deve ser tratado como alcançável a partir de um vizinho hostil.

A mudança prática é pequena mas real. O inquilino ao seu lado, um nome que nunca conhecerá, passou este mês de uma preocupação abstrata a uma linha do seu modelo de ameaça. Os proprietários que transformam isso numa resposta escrita e concreta do fornecedor, em vez de uma suposição cómoda, são os que não estarão a adivinhar se esta falha for algum dia encadeada numa intrusão real.

Leia a seguir: CitrixBleed regressa, explorado em menos de um dia  |  Um token falso abre cada PC que a ferramenta gere