Falha de 16 anos no firmware UEFI permite execução de código em servidores antes do Secure Boot

A CVE-2026-97631 (CVSS 9.5) é um buffer overflow de 16 anos no driver PXE Base Code (NetworkPkg/UefiPxeBcDxe) do TianoCore EDK II, base de referência usada por praticamente todos os fornecedores de UEFI, como AMI, Insyde e Phoenix. O Project Mu, fork endurecido da Microsoft, também usava o componente vulnerável. Durante o network boot, o driver mantém uma requisição aberta para mensagens de erro ICMP e copia cada uma para um campo fixo de 504 bytes (Mode.IcmpError). Os handlers de IPv4 e IPv6 tratam mal os limites: copiam além do campo e avançam o ponteiro de destino pelo tamanho acumulado, não pelo do fragmento. Nada antes na cadeia de recepção restringe o tamanho da mensagem.

O resultado é execução de código em ring 0, antes de Secure Boot e da cadeia de confiança do TPM. O payload final não tem persistência, mas pode abrir caminho para outros que rodem a cada boot. Há limites claros: é preciso acesso à rede local, o ataque ocorre só durante a sequência PXE (ligada por padrão) e o invasor precisa adivinhar endereços específicos de cada modelo, versão e configuração. Quem boota só por disco não é afetado. Segundo a Eclypsium, a correção é simples no código e exige só atualização de BIOS/UEFI, sem revogações nem gestão de chaves PK/KEK/db/dbx, ao contrário de BootHole, BlackLotus e Baton Drop. O problema é que um pull request da AMI expôs o patch meses antes da divulgação coordenada de janeiro. Intel diz que seus produtos comerciais sob suporte não são conhecidos como afetados, mas que um OEM pode integrar a função. A Arm disse que a falha não se aplica diretamente ao seu portfólio. AMD, Phoenix, AMI, Microsoft e Amazon não responderam.

Para quem opera servidores com PXE, a leitura é prática: inventarie quais máquinas bootam pela rede, pergunte ao fornecedor de firmware sobre EDK2 e desligue o PXE onde não for essencial. Com o patch público, a janela entre o vazamento e a atualização de firmware tende a ser o ponto de maior risco, e em sistemas sem suporte o bug provavelmente fica para sempre, como avaliou HD Moore. Monitorar ICMP anômalo nos segmentos de boot é barato e já vale.