Uma falha crítica de 16 anos no EDK II, código de código aberto usado pela maioria dos fabricantes de hardware para criar firmware UEFI, pode permitir que um invasor execute código em uma máquina antes de o sistema operacional carregar. O risco, porém, existe apenas durante a inicialização pela rede.
O firmware UEFI é o primeiro software executado quando um computador é ligado, antes do sistema operacional. Um invasor que consiga enviar uma mensagem de rede especialmente preparada à máquina durante esse tipo de inicialização pode travar o processo ou, com um exploit adaptado à versão exata do firmware, executar comandos antes que o Secure Boot e outras defesas entrem em ação.
O invasor não precisa de senha nem de acesso prévio à máquina, mas precisa alcançá-la pela rede durante o curto período em que ela está sendo inicializada dessa forma.
A Red Hat e a SUSE, que distribuem o código afetado, classificaram a falha como explorável por um invasor em uma posição adjacente na rede, e não por alguém em qualquer ponto da internet.
A TianoCore, mantenedora do projeto EDK II, publicou um alerta em 22/10 e atribuiu à falha, identificada como
CVE-2026-97631
, nota 9,5 de 10. Já existe uma correção no código, mas nenhuma versão estável do EDK II a inclui. O alerta ainda não indica uma versão corrigida, portanto a maioria dos usuários não tem nada para instalar no momento.
O que a falha permite fazer
A falha é um estouro de buffer no código de inicialização de rede do EDK II, conhecido como PXE. Durante uma inicialização PXE, a máquina carrega a imagem de inicialização pela rede, em vez de buscá-la em um disco local.
Nesse processo, o controlador PXE recebe mensagens de erro ICMP e pequenas mensagens de status enviadas por dispositivos de rede. Em seguida, copia cada mensagem para uma área de memória fixa, com capacidade para 504 bytes.
As verificações de tamanho dessa cópia estão incorretas nas versões do código para IPv4 e IPv6. Assim, uma mensagem com mais de 504 bytes ultrapassa o limite da área e sobrescreve regiões próximas da memória com dados escolhidos pelo invasor.
Para acionar a falha, basta enviar uma mensagem de erro preparada ao endereço da máquina enquanto ela está sendo inicializada pela rede. Não é necessário ter senha ou acesso prévio ao equipamento.
O resultado mais simples é uma falha no processo: a inicialização trava e a máquina não consegue iniciar. Fazer o código ser executado é muito mais difícil e menos confiável. Segundo o alerta, um invasor que conheça a versão exata do firmware pode criar um “evento falsificado” que leva o firmware a executar código próprio. Por isso, o exploit precisa ser desenvolvido para uma versão específica.
Quando o código é executado, ele roda dentro do firmware, antes que o Secure Boot e outras verificações de inicialização tenham validado qualquer componente. É esse momento que torna a falha grave.
O código inserido dessa forma é executado uma única vez e não permanece após a reinicialização. Ainda assim, essa execução pode bastar para instalar outro código que passe a ser iniciado sempre que a máquina for ligada.
Quem é afetado
A falha está presente no EDK II até a versão edk2-stable202608, a mais recente versão estável, lançada em 21/08. O EDK II é o código de referência usado por quase todos os fabricantes de firmware UEFI, incluindo os fabricantes independentes de BIOS AMI, Insyde e Phoenix, além do Project Mu, uma variante reforçada da Microsoft.
Segundo o The Hacker News, o trecho de código responsável pela cópia defeituosa está no projeto desde uma alteração adicionada em novembro de 2010.
A inicialização de rede PXE vem ativada por padrão na compilação padrão do EDK II. A falha não afeta usuários domésticos ou de escritório que iniciam seus computadores apenas por um disco local. Ela diz respeito a organizações cujas máquinas são inicializadas pela rede, principalmente servidores e equipamentos de centros de dados.
Não se sabe quantos produtos comercializados incluem o código vulnerável. Segundo o Ars Technica, a Intel afirmou que não tem conhecimento de que algum de seus “produtos comerciais que ainda recebem suporte de segurança” seja afetado. A empresa também afirmou que “não inclui a funcionalidade afetada do EDK2 em seu código de referência”, embora um fabricante de placas OEM ou de sistemas possa adicioná-la.
Segundo o Ars Technica, a Arm afirmou que a falha “não se aplica diretamente ao portfólio de produtos da empresa”. O firmware das duas companhias utiliza código do EDK II.
Distribuições Linux também incluem o código. A Red Hat classifica o pacote edk2 do Red Hat Enterprise Linux 8, 9 e 10 como afetado e ainda sem correção. SUSE e Debian indicam a mesma situação para os pacotes equivalentes.
Segundo o The Hacker News, AMD, Phoenix Technologies, AMI, Microsoft e Amazon não responderam às perguntas enviadas antes da publicação. A TianoCore também não se manifestou, e a situação de seus produtos continua incerta.
Existe uma correção?
Uma correção já foi incorporada ao código-fonte do EDK II. Ela reformula a cópia defeituosa para que mensagens maiores sejam limitadas a 504 bytes, em vez de ultrapassarem o espaço reservado. A alteração chegou ao principal ramo de desenvolvimento em 15/10.
Nenhuma versão estável do EDK II inclui a correção até o momento. O The Hacker News verificou os marcadores de versão do projeto em 28/10 e constatou que a mais recente, edk2-stable202608, é anterior à alteração. O alerta ainda indica que a versão corrigida está “atualmente indisponível”. O Project Mu, da Microsoft, já incorporou a correção em seus ramos de lançamento e publicou versões identificadas com tags em 26/10.
Mesmo com a correção disponível publicamente no código-fonte, operadores de servidores não têm o que instalar até que o fabricante do firmware distribua uma atualização de BIOS ou UEFI baseada nela. Segundo o Ars Technica, Jesse Michael, pesquisador principal da empresa de segurança de firmware Eclypsium, afirmou que essa etapa deve ser relativamente simples. Diferentemente de formas de contornar o Secure Boot, como BootHole e BlackLotus, a falha “pode ser corrigida com uma alteração básica no código” e não exige a revogação de certificados ou chaves.
Até que a atualização seja distribuída, o alerta não recomenda nenhuma medida alternativa. Como a falha só pode ser explorada durante uma inicialização pela rede, operadores que não precisam de PXE podem desativá-lo para reduzir a exposição. O Ars Technica também recomendou monitorar o tráfego de rede durante a inicialização e os registros em busca de sinais de tentativa de exploração.
Como a falha veio a público
A falha foi encontrada por Alex Matrosov, da Anthropic, e Dan Holmes-Mitra, do Google, segundo o alerta. A divulgação coordenada estava prevista para janeiro de 2027.
O plano mudou em 28/09, quando um pedido de integração 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 seu alerta em 22/10, semanas antes da data planejada.
Com a correção pública, o Ars Technica observou que invasores experientes podem estudá-la para descobrir como acionar a falha e desenvolver exploits funcionais.
Não há indícios de que a falha tenha sido usada em um ataque. Ela não constava no catálogo de Vulnerabilidades Conhecidamente Exploradas da CISA na atualização de 27/10, e nenhum pesquisador relatou ter observado sua exploração.
Segundo o Ars Technica, vários pesquisadores de firmware afirmaram que a falha, por si só, também não permite entrar em uma rede. O cenário mais provável envolve alguém de dentro da organização ou um invasor que já tenha obtido um ponto de apoio de baixo nível na rede local e queira avançar.
Segundo o Ars Technica, HD Moore, criador do Metasploit e diretor de pesquisa da empresa de segurança Dragos, afirmou: “Um invasor interessado em comprometer um endpoint ou servidor próximo poderia usar esse bug para assumir o controle do fluxo de execução em um momento no qual o processo de inicialização ainda tem acesso a componentes sensíveis, como o TPM do endpoint. Isso poderia ser usado para quebrar a criptografia de disco em situações nas quais o invasor tem acesso temporário à rede. Em um caso de roubo, seria ainda mais fácil.”
Esta não é a primeira falha grave no código de inicialização de 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 exploráveis durante a inicialização PXE. O Ars Technica informou que projetos de testes automatizados iniciados após o PixieFail para encontrar outras falhas no código não detectaram esta vulnerabilidade.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...