Falha por corrigir no EDK II expõe servidores que arrancam pela rede antes do Secure Boot

Um buffer overflow que está há cerca de dezasseis anos no código de referência open-source para UEFI pode bloquear um servidor enquanto arranca a partir da rede e, no pior dos casos, executar código controlado pelo atacante antes de o Secure Boot sequer se ter inicializado. A falha tem o identificador CVE-2026-97631 e uma pontuação CVSS de 9,5. Encontra-se no EDK II, a base de código da TianoCore sobre a qual quase todos os fabricantes de firmware constroem. Existe uma correção no ramo principal de desenvolvimento do projeto, mas a 28 de outubro de 2026 nenhuma versão estável do EDK II a inclui, e a maioria dos responsáveis por servidores ainda não tem nada para instalar.

O que aconteceu

O EDK II inclui a pilha de arranque pela rede PXE, que permite a uma máquina obter a sua imagem de arranque a partir da rede em vez de um disco local. Enquanto um arranque PXE está a decorrer, o controlador aceita mensagens de erro ICMP e pequenas respostas de estado vindas da rede e copia-as para um buffer fixo de 504 bytes. As verificações de comprimento em torno dessa cópia estão erradas tanto no caminho IPv4 como no IPv6, pelo que uma única mensagem manipulada com mais de 504 bytes transborda o buffer e sobrescreve a memória adjacente com dados escolhidos pelo atacante.

O ciclo de cópia defeituoso remonta a um commit de novembro de 2010. Todas as versões do EDK II até à edk2-stable202608 inclusive, a etiqueta estável atual de agosto de 2026, o contêm. O arranque PXE vem ativado por omissão na compilação padrão do EDK II, e é por isso que tantos produtos derivados estão abrangidos: os fabricantes independentes de BIOS AMI, Insyde e Phoenix, o fork reforçado Project Mu da Microsoft e os pacotes edk2 distribuídos pelo Red Hat Enterprise Linux 8, 9 e 10, pelo SUSE e pelo Debian, usados sobretudo como firmware UEFI para máquinas virtuais.

A divulgação não correu como planeado. Estava agendada uma publicação coordenada para janeiro de 2027, mas um pull request aberto a 28 de setembro de 2026 mencionou publicamente o CVE e incluiu a correção. A TianoCore publicou então o seu aviso a 22 de outubro, com a correção já integrada no ramo principal desde 15 de outubro. A Microsoft reagiu depressa e lançou compilações do Project Mu com a correção a 26 de outubro. Do lado do hardware, a Intel afirma que não se conhece nenhum produto comercial seu sob suporte de segurança que esteja afetado e que o seu próprio código de referência não inclui a funcionalidade vulnerável, embora um fabricante de placas a possa adicionar. A Arm indica que a falha não é diretamente aplicável ao seu portefólio. AMD, AMI, Phoenix, Insyde, Microsoft e os grandes fornecedores de cloud não confirmaram publicamente o estado do seu firmware, pelo que para muitos parques de servidores a resposta honesta hoje é "desconhecido".

Porque é que importa

O perigo está no momento. O código injetado através desta falha corre dentro do firmware, antes de o Secure Boot, o measured boot e qualquer controlo do sistema operativo terem verificado o que quer que seja. O atacante não precisa de credenciais nem de acesso prévio à máquina, apenas de a conseguir alcançar na rede durante a curta janela em que ela arranca por PXE.

As consequências dividem-se em dois níveis. O simples é a negação de serviço: o arranque bloqueia e a máquina nunca chega a iniciar. Um parque que dependa do PXE para aprovisionamento ou para nós sem disco pode ser derrubado pacote a pacote. A execução de código é consideravelmente mais difícil e muito menos fiável, porque o payload tem de ser adaptado à compilação exata do firmware. O código plantado desta forma corre uma só vez e não persiste por si próprio, mas uma única execução tão cedo na cadeia de arranque chega para instalar algo que persista, ou para alcançar segredos que o processo de arranque ainda detém, como as chaves de cifra do disco libertadas pelo TPM. Num cenário de furto ou de acesso breve à rede, isso é um caminho para quebrar a cifra completa de disco num servidor ou num endpoint.

Há duas ressalvas importantes. Primeiro, não há provas de exploração real: o CVE não constava do catálogo Known Exploited Vulnerabilities da CISA na atualização de 27 de outubro e ninguém reportou tê-lo visto em uso. Segundo, não é uma porta de entrada a partir da internet. A Red Hat e a SUSE classificam o vetor de ataque como rede adjacente, e o atacante realista é alguém de dentro da organização ou alguém que já tem um ponto de apoio num segmento local e quer ir mais fundo. Ainda assim, a correção é agora pública, e qualquer pessoa capaz de ler um diff consegue perceber exatamente como o overflow é desencadeado.

Também não é a primeira vez que a pilha PXE deixa o EDK II a descoberto. O conjunto de nove falhas PixieFail, divulgado em janeiro de 2024, atingiu o mesmo componente, e as campanhas de fuzzing que se seguiram não apanharam esta.

O que fazer

• Inventarie o que arranca pela rede. Hosts de aprovisionamento bare-metal, nós de computação sem disco, thin clients e máquinas virtuais com firmware baseado em EDK II entram todos nesta categoria. Se não os consegue enumerar, não os consegue proteger.
• Desligue o PXE onde não for necessário. Vem ativado por omissão na maioria das compilações. Desativar o arranque pela rede na configuração do firmware elimina por completo a superfície de ataque nas máquinas que só arrancam a partir do disco local.
• Isole a rede de arranque. Mantenha o aprovisionamento numa VLAN dedicada, restrinja que hosts podem enviar ICMP para as máquinas em arranque e nunca faça arranque PXE através de um segmento ao qual dispositivos não confiáveis possam chegar.
• Vigie o tráfego durante o arranque. Mensagens de erro ICMP sobredimensionadas dirigidas a clientes PXE e arranques que bloqueiam sem explicação são os sinais sobre os quais alertar até o firmware ser atualizado.
• Acompanhe os seus fornecedores. Não existe uma mitigação oficial. A correção é uma alteração de código simples que não exige revogação de certificados nem de chaves, ao contrário do BootHole ou do BlackLotus, pelo que as atualizações de BIOS e UEFI dos fabricantes deverão ser mais fáceis de implementar quando surgirem. Atualize os pacotes edk2 das distribuições assim que forem publicados e dê prioridade aos hosts de virtualização onde as máquinas virtuais arrancam por PXE.

Uma falha destas só importa se um atacante conseguir realmente chegar aos seus hosts enquanto arrancam, e isso é uma questão sobre a sua rede, não sobre o firmware. Um teste de penetração interno realizado pela equipa da 4tify responde-lhe diretamente: que segmentos transportam tráfego de arranque, o que uma estação comprometida consegue ver durante uma janela de aprovisionamento e se os controlos acima se aguentam na prática.