Uma falha crítica de 16 anos no EDK II (kit de desenvolvimento de firmware EFI, de código aberto), que a maioria dos fabricantes de hardware usa para construir firmware UEFI (Interface Extensível Unificada de Firmware), pode permitir que um atacante execute código em uma máquina antes de o sistema operacional ser carregado, mas somente enquanto a máquina estiver inicializando pela rede.
O firmware UEFI é o software que roda primeiro quando o computador é ligado, antes do sistema operacional. Um atacante que consiga alcançar a máquina com uma mensagem de rede elaborada durante essa inicialização pela rede pode travar o processo de boot ou, com um trabalho direcionado à build exata do firmware, executar o próprio código antes que o Secure Boot e outras defesas de inicialização sejam carregados.
O atacante não precisa de senha nem de acesso prévio à máquina, mas precisa alcançá-la pela rede durante a janela curta em que ela está inicializando dessa forma.
A Red Hat e a SUSE, que distribuem o código afetado, classificaram a falha como uma que um atacante explora a partir de uma posição de rede adjacente, e não pela internet aberta.
A TianoCore, projeto por trás do EDK II, publicou um comunicado em 22 de outubro e avaliou a falha, registrada como CVE-2026-97631 (Common Vulnerabilities and Exposures, sistema de identificação de vulnerabilidades), com nota 9,5 em 10. Existe uma correção de código, mas nenhuma versão estável do EDK II a contém ainda, e o comunicado continua sem listar uma versão corrigida. Por isso, a maioria dos usuários não tem nada para instalar hoje.
O que a falha permite ao atacante
A falha é um estouro de buffer (buffer overflow) no código de inicialização pela rede do EDK II, conhecido como PXE (Preboot Execution Environment, ambiente de pré-inicialização via rede). Durante uma inicialização PXE, a máquina carrega sua imagem de inicialização pela rede, em vez de a partir de um disco local.
Nesse processo, o driver PXE escuta mensagens de erro ICMP (Internet Control Message Protocol, protocolo de mensagens de controle da internet) e as pequenas mensagens de status que dispositivos de rede enviam de volta, e copia cada uma delas para uma área de memória fixa de 504 bytes.
As verificações de tamanho dessa cópia estão incorretas tanto na versão IPv4 quanto na IPv6 do código (protocolos de internet versões 4 e 6). Assim, uma mensagem maior que 504 bytes transborda essa área e sobrescreve a memória vizinha com dados escolhidos pelo atacante.
Para disparar a falha, o atacante só precisa enviar uma única mensagem de erro elaborada ao endereço da máquina enquanto ela está no meio de uma inicialização pela rede. Não é necessária senha nem acesso prévio à máquina.
O resultado mais simples é um travamento: a inicialização para e a máquina não consegue iniciar. Fazer código ser executado é bem mais difícil e muito menos confiável. O comunicado diz que um atacante que conheça a build exata do firmware pode plantar um “evento falsificado” que leva o firmware a executar o código do atacante. Por isso, um exploit precisa ser construído para uma build específica.
Quando o código é executado, ele roda dentro do firmware, antes de o Secure Boot e outras verificações de inicialização terem validado qualquer coisa. Esse momento é o que torna a falha grave.
O código plantado dessa forma roda apenas uma vez e não sobrevive sozinho a uma reinicialização. Ainda assim, essa execução única basta para instalar outro código que passa a rodar em toda inicialização.
Quem é afetado
A falha está presente no EDK II até a versão estável edk2-stable202608 inclusive, a mais recente, datada de 21 de agosto. O EDK II é o código de referência sobre o qual quase todos os fornecedores de firmware UEFI constroem, incluindo os fabricantes independentes de BIOS (Sistema Básico de Entrada e Saída) AMI, Insyde e Phoenix, além da versão reforçada da Microsoft, o Project Mu.
O trecho de código com o laço de cópia vulnerável existe desde um commit adicionado em novembro de 2010, segundo o The Hacker News, que descobriu isso ao rastrear o histórico do projeto.
A inicialização PXE vem ativada por padrão na build padrão do EDK II. A falha não afeta usuários domésticos ou de escritório que inicializam apenas a partir de disco local. Ela se aplica a organizações cujas máquinas inicializam pela rede, principalmente servidores e equipamentos de data center.
Não se sabe quantos produtos em circulação carregam o código vulnerável. A Intel disse à Ars Technica que nenhum de seus “produtos comerciais atualmente sob suporte de segurança” é conhecido por ser afetado, e que a empresa “não inclui a funcionalidade afetada do EDK2 em seu código de referência”. Ainda assim, um fornecedor de placas OEM (fabricante original do equipamento) ou um fabricante de sistemas pode incluí-la.
A Arm afirmou que a falha “não é diretamente aplicável ao portfólio de produtos da Arm”. As duas empresas têm firmware próprio que se apoia no EDK II.
Distribuições Linux também incluem o código. A Red Hat lista seu pacote edk2 nas versões Red Hat Enterprise Linux 8, 9 e 10 como afetado e ainda sem correção, e a SUSE e a Debian marcam seus pacotes equivalentes da mesma forma.
AMD, Phoenix Technologies, AMI, Microsoft e Amazon não responderam às perguntas do site de notícias de tecnologia antes da publicação, e a TianoCore também não se manifestou. Por isso, a situação de seus produtos permanece incerta.
Há uma correção?
Uma correção foi incorporada ao código-fonte do EDK II. Ela reescreve a cópia defeituosa para que uma mensagem excessivamente grande seja cortada em 504 bytes, em vez de transbordar. A mudança chegou ao ramo principal de desenvolvimento em 15 de outubro.
Nenhuma versão estável do EDK II inclui essa correção ainda. O The Hacker News verificou as tags de versão do projeto em 28 de outubro e constatou que a mais recente, edk2-stable202608, é anterior à correção. Além disso, o comunicado continua indicando a versão corrigida como “não corrigida no momento”. O Project Mu, da Microsoft, já incorporou a correção em seus ramos de lançamento e gerou builds com tags em 26 de outubro.
Mesmo com a correção pública no código-fonte, um operador de servidor não tem o que instalar até que o fabricante do firmware lance uma atualização de BIOS ou UEFI construída a partir dela. Essa etapa é, pelo menos, simples, disse Jesse Michael, pesquisador principal da empresa de segurança de firmware Eclypsium, à Ars Technica. Diferentemente de contornos do Secure Boot, como BootHole e BlackLotus, a falha “pode ser corrigida com uma correção básica de código” e não exige revogação de certificados ou chaves.
Até que essa atualização chegue, o comunicado não lista nenhuma solução alternativa. Como a falha só pode ser alcançada durante uma inicialização pela rede, operadores que não precisam de PXE podem desativá-lo para reduzir a exposição. A Ars também recomendou monitorar o tráfego de rede durante a inicialização e os registros em busca de sinais de tentativas de ataque.
Como a falha se tornou pública
A falha foi encontrada por Alex Matrosov, da Anthropic, e Dan Holmes-Mitra, do Google, segundo o comunicado. Uma divulgação coordenada estava planejada para janeiro de 2027.
Esse plano foi antecipado em 28 de setembro, quando um pull request enviado ao EDK II, aprovado por um engenheiro da AMI, descreveu publicamente a falha pelo número CVE e incluiu a correção. Depois que os pesquisadores que a encontraram viram a publicação, a TianoCore divulgou o comunicado em 22 de outubro, semanas antes da data planejada.
Com a correção pública, a Ars observou que atacantes qualificados podem estudá-la para descobrir como a falha é acionada e desenvolver exploits funcionais.
Não há indícios de que a falha tenha sido usada em algum ataque. Ela não constava no catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) na atualização de 27 de outubro, e nenhum pesquisador relatou tê-la visto sendo explorada.
A falha também não é, por si só, uma porta de entrada para uma rede, segundo a Ars Technica, que ouviu vários pesquisadores de firmware. O atacante realista é alguém de dentro da organização ou alguém que já obteve uma posição inicial de baixo nível na rede local e quer se aprofundar.
“Um atacante que queira comprometer um dispositivo final (endpoint) ou um servidor próximo poderia usar esse bug para sequestrar o fluxo do programa em um ponto em que o processo de inicialização ainda tem acesso a componentes sensíveis, como o TPM (Trusted Platform Module, Módulo de Plataforma Confiável) do dispositivo”, disse HD Moore, criador do Metasploit e diretor de pesquisa da empresa de segurança Dragos, em declarações à Ars Technica.
“Isso pode ser usado para quebrar a criptografia de disco em casos em que o atacante tem acesso à rede por curto prazo (e seria ainda mais fácil em um cenário de roubo).”
Não é a primeira falha grave no código de inicialização pela rede do EDK II. Em janeiro de 2024, pesquisadores divulgaram o PixieFail, um conjunto de nove falhas na mesma parte do EDK II, também alcançáveis durante a inicialização PXE. A Ars informou que projetos de fuzzing (teste automatizado com entradas aleatórias) iniciados após o PixieFail para encontrar mais bugs no código não detectaram esta falha.
