Vulnerabilidade no EDK2 compromete boot seguro da maioria dos servidores do mundo

O que foi descoberto

Pesquisadores encontraram uma vulnerabilidade de execução de código com nota 9.5 em uma escala de 10 no TianoCore EDK II (EDK2), o código de referência open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → usado por praticamente todos os fabricantes de firmware UEFI do mercado. A falha foi catalogada como CVE-2026-97631 e afeta o driver que permite que servidores façam boot pela rede usando o padrão PXE. Segundo a Wired, o bug foi achado por Alex Matrosov, pesquisador da Anthropic, e Dan Holmes, do Google.

A dupla havia combinado com os fabricantes uma divulgação coordenada prevista para janeiro. O plano não durou: a fabricante de placas-mãe AMI publicou, no mês passado, um pull request público detalhando a falha e trazendo a correção. O documento passou despercebido até ser notado pelos próprios descobridores, o que forçou o TianoCore Project a publicar um alerta oficial na semana passada, com meses de antecedência do combinado.

O caso lembra outro episódio recente: seis dias antes, duas vulnerabilidades críticas na linguagem PHP também vazaram antes do previsto e já estavam sendo exploradas em massa quando vieram a público, segundo outra reportagem da própria Wired.

Por que isso é grave para infraestrutura

EDK2 não é um software qualquer: é a base sobre a qual fabricantes como AMI, Insyde e Phoenix constroem o firmware UEFI que roda no primeiro instante em que um servidor liga, antes do sistema operacional e antes de qualquer mecanismo de segurança como o Secure Boot. O fork hardenizado da Microsoft, Project Mu, também herdou o componente vulnerável.

Isso significa que o código comprometido roda num momento em que a cadeia de confiança do boot ainda está sendo construída. Um ataque bem-sucedido executa em ring 0, o nível de privilégio mais alto da CPU, e contorna os processos de atestação que provam, de forma criptográfica, que o hardware está íntegro, inclusive o TPM.

Em resumo: quando a falha é explorada, ela age antes de qualquer defesa do sistema operacional existir, incluindo o Secure Boot.

Onde mora o bug e como ele é disparado

O problema é um buffer overflow com 16 anos de idade no driver NetworkPkg/UefiPxeBcDxe, responsável pelo PXE Base Code usado no boot via rede. Durante esse processo, o driver mantém um listener aberto para mensagens de erro ICMP e copia cada uma delas para um campo fixo de 504 bytes chamado Mode.IcmpError.

O advisory oficial do TianoCore descreve a falha com precisão:

Durante o boot pela rede, o driver PXE Base Code mantém uma requisição de recebimento aberta para mensagens de erro ICMP e copia cada mensagem recebida para o campo fixo de 504 bytes Mode.IcmpError de sua estrutura de contexto privada. O tratamento de limites do loop de cópia está incorreto tanto no handler IPv4 quanto no IPv6 (PxeBcIcmpErrorDpcHandle e PxeBcIcmp6ErrorDpcHandle): para uma mensagem maior que 504 bytes, ele continua copiando bytes para o campo, e avança o ponteiro de destino pelo tamanho cumulativo em vez do tamanho por fragmento, de forma que uma mensagem maior que o esperado escreve bytes controlados pelo atacante além do campo.

TianoCore Project, advisory oficial do EDK2During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop's bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field.

Na prática, um invasor com algum nível de acesso à rede local, durante a sequência de boot PXE de um alvo, pode enviar uma única mensagem ICMP unicast maior que o limite. Sem conhecer a build exata do firmware alvo, o resultado é só um travamento, uma negação de serviço. Conhecendo a build, o invasor pode plantar um evento falsificado que executa código malicioso na CPU dentro do próprio ambiente de firmware UEFI.

Quem precisa se preocupar (e quem não precisa)

A falha não afeta usuários domésticos nem máquinas que fazem boot só a partir do disco. Ela é relevante apenas para organizações com equipamentos que inicializam pela rede local, ou, em tese, por recursos acessíveis pela internet, desde que o firmware use EDK2 e tenha a funcionalidade PXE ativa, o que vem ligado por padrão na maioria dos equipamentos.

Isso recorta o problema para exatamente o público que opera servidores, storage e outros equipamentos de infraestrutura: data centers próprios, provedores de colocation e nuvens privadas que usam boot pela rede para provisionamento em massa, prática comum em operações de bare metal em qualquer lugar do mundo, inclusive no Brasil.

A Intel disse à Wired que nenhum de seus "produtos comerciais atualmente sob suporte de segurança" é conhecido por estar afetado, embora reconheça que fabricantes de placas podem integrar o código vulnerável por conta própria; documentação pública da própria Intel referencia o EDK2 extensivamente. A Arm deu resposta parecida, afirmando que a CVE "não se aplica diretamente" ao portfólio da empresa, apesar de seu firmware de referência também usar código herdado do EDK2.

AMD, Phoenix Technologies, AMI, Microsoft e Amazon não responderam aos pedidos de posicionamento da Wired até a publicação da matéria original. Sem uma lista oficial e completa de quem usa o quê, cabe a cada equipe de infraestrutura auditar o próprio parque de hardware.

Nem toda exploração é trivial

HD Moore, criador do Metasploit e chief research officer da Dragos, explicou à Wired por que o bug é especialmente incômodo para quem depende de criptografia de disco:

Essa vulnerabilidade no parser ICMP da pilha de rede do EDK2 é interessante pela forma como afeta a cadeia de confiança e o ecossistema mais amplo. Um atacante com intenção de comprometer um endpoint ou servidor próximo poderia usar esse bug para sequestrar o fluxo do programa num ponto em que o processo de boot ainda tem acesso a componentes sensíveis, como o TPM do endpoint. Isso poderia ser usado para quebrar a criptografia de disco em casos em que o atacante tem acesso de rede por curto prazo, e seria ainda mais fácil num cenário de roubo físico.

HD Moore, criador do Metasploit e chief research officer na DragosThis vulnerability in the ICMP parser of the EDK2 network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem. An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint's TPM. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario).

Jesse Michael, pesquisador principal da Eclypsium, pondera que não é um exploit genérico de um clique para todos os alvos: o invasor precisa adivinhar endereços de memória específicos, o que exige calibrar o ataque para cada modelo, versão e configuração de firmware. Ele nota ainda uma vantagem rara neste caso: diferente de falhas anteriores em Secure Boot como BootHole e BlackLotus, a correção de CVE-2026-97631 não exige revogação de chaves nem atualização de mídia de provisionamento, apenas a aplicação de uma atualização convencional de BIOS/UEFI.

Um capítulo a mais numa lista que não para de crescer

CVE-2026-97631 entra para uma lista extensa de falhas em UEFI ou em código próximo dele. A mais grave até hoje, LogoFail, veio de bugs de renderização nas imagens de logo incluídas no UEFI de praticamente todo fabricante de hardware. PixieFail, o caso mais parecido com o atual, também nasceu de falhas no boot PXE do EDK2, e motivou rodadas de fuzzing que, evidentemente, não pegaram este bug. A lista segue com PKFail, falha de supply chain ligada a chaves de teste que vazaram por mais de uma década, além de BootHole, Bootkit e BlackLotus.

HD Moore classificou CVE-2026-97631 como um bug "para sempre": dado o volume de dispositivos com EDK2 embarcado e fora de suporte, ele deve sobreviver por anos em sistemas que nunca vão receber o patch.

O que fazer

Para quem administra servidores, bare metal ou infraestrutura de nuvem privada no Brasil ou fora dele, a lista de ações possíveis é curta, mas concreta:

• Verificar com o fabricante do firmware (motherboard, servidor ou appliance) se o equipamento usa EDK2 e se já existe atualização de BIOS/UEFI disponível;
• Desligar temporariamente o boot por rede (PXE) em máquinas que não dependem dele no dia a dia de provisionamento;
• Manter TPM e Secure Boot ativos mesmo sabendo que eles não bloqueiam este ataque específico, porque seguem protegendo contra outras classes de ameaça;
• Monitorar logs de rede em busca de tentativas de exploração durante sequências de boot PXE.

Como a correção já está pública desde a publicação não planejada da AMI, o tempo para agir é curto: qualquer pessoa com acesso de leitura ao pull request consegue reconstruir o caminho até um exploit funcional, mesmo que, como lembra Michael, cada exploit precise ser ajustado ao alvo específico.

Fonte: Wired