Falha crítica no EDK II permite execução de código antes do sistema operacional carregar

Uma vulnerabilidade de gravidade extrema foi descoberta no EDK II (EFI Development Kit 2), o ambiente de desenvolvimento de firmware mais utilizado no mundo para plataformas UEFI. Rastreada como CVE-2026-97631 e classificada com nota CVSS 4.0 de 9,5 — quase o máximo possível —, a falha reside no driver PXE Base Code (NetworkPkg/UefiPxeBcDxe) e pode permitir que um atacante não autenticado execute código arbitrário durante a fase pré-boot, antes que o Secure Boot ou o measured boot tenham verificado qualquer componente do sistema operacional.

Como a falha funciona

O problema está nos manipuladores de erro ICMP (Internet Control Message Protocol) dos handlers IPv4 e IPv6 do driver de boot de rede. Durante o boot via rede, o driver mantém uma solicitação de recepção aberta para mensagens de erro ICMP e copia cada mensagem recebida para um campo fixo de 504 bytes chamado `Mode.IcmpError` em sua estrutura de contexto privada.

O loop de cópia possui uma falha de tratamento de limites em ambos os manipuladores IPv4 e IPv6: para mensagens com mais de 504 bytes, o código continua copiando bytes para além do campo, avançando o ponteiro de destino pelo comprimento cumulativo em vez do comprimento por fragmento. Nada no caminho de recepção anterior restringe o tamanho da mensagem. Isso configura um buffer overflow clássico (CWE-120) combinado com cálculo incorreto de tamanho de buffer (CWE-131) e escrita fora dos limites (CWE-787).

O resultado é duplo: uma corrupção determinística dos dados privados do driver, causando uma exceção de CPU dentro do core DXE no próximo erro ICMP (hanging do boot, negação de serviço), e a possibilidade, para um atacante que conhece a configuração de firmware do alvo, de injetar um evento falso no mesmo pacote e fazer com que o `CoreSignalEvent()` despache bytes controlados pelo atacante na fase DXE — anel 0, antes de qualquer controle de segurança do sistema operacional existir.

Quem está afetado

O EDK II é mantido pela fundação TianoCore e é a implementação de referência de-facto para a especificação UEFI. Vendedores incluem American Megatrends (AMI), Intel, Insyde Software, Phoenix Technologies e Microsoft. Máquinas usando EDK II que fazem boot de rede via PXE — e, crucialmente, estão configuradas para usar IPv6 — são todas vulneráveis à exploração.

A Intel informou ao Ars Technica que não conhece produtos comerciais atualmente sob suporte de segurança que sejam afetados, mas observou que OEMs ou fabricantes de sistema podem integrar a funcionalidade vulnerável.

O alcance exato dos produtos afetados permanece incerto, e várias empresas contatadas pelo Ars Technica não responderam na publicação. Sistemas que bootam exclusivamente de disco não são afetados — a exposição exige acesso à rede relevante durante a sequência de boot PXE.

Descoberta e correção

A vulnerabilidade foi descoberta por Alex Matrosov, da Anthropic, e Dan Holmes-Mitra, do Google, que também forneceram a correção recomendada. A revelação veio antes do planejado depois que a fabricante de placas-mãe AMI publicou um pull request contendo os detalhes da correção — o que, ironicamente, facilita o trabalho de atacantes avançados que desejarem aprender como a vulnerabilidade é acionada.

O pull request (#13302) adiciona lógica de validação de tamanho antes da cópia e inclui testes unitários para as condições que a correção resolve. A versão afetada do EDK II é a master a partir de 2026-09-14. A versão estável mais recente, `edk2-stable202608` (21 de agosto de 2026), também foi listada como afetada.

O que observar

Com código de patch publicamente disponível, será trivial para hackers avançados aprenderem como a vulnerabilidade é acionada e construírem exploits funcionais. A janela de exposição é a duração do boot PXE — o que significa que o risco é concentrado em momentos específicos, mas a superfície de ataque é ampla em ambientes de datacenter onde o boot de rede é parte do fluxo normal de provisionamento.

O que torna esta vulnerabilidade particularmente perigosa é que ela opera em um nível abaixo de qualquer proteção do sistema operacional. Um exploit bem-sucedido comprometeria a plataforma inteira, incluindo a capacidade de modificar ou implantar malware que sobrevive reinstalações do sistema operacional. A analogia com o caso BlackLotus — o primeiro bootkit UEFI publicamente documentado que derrotou o Secure Boot em uma máquina Windows 11 de fábrica — ilustra o tipo de cenário que administradores de infraestrutura desejam evitar.

A questão é se a comunidade de firmware open-source, que tem trabalhado diligentemente com o processo de divulgação coordenada, conseguirá produzir correções para distribuição OEM em tempo hábil, ou se centenas de milhares de servidores ficarão em risco até que as atualizações de firmware cheguem aos datacenters.

Fontes: TianoCore EDK II Security Advisory, Linxi News, CVE Record

✓ Fontes independentes cruzadas e verificadas antes da publicação