[ Início ]
Vol. 2 (abr. 2026) | Pp. 430–432 | ISSN 3086-6103
CVE-2026-97631: falha de 16 anos no EDK II permite execução de código antes do Secure Boot em inicialização PXE
Nessa terça-feira o Ars Technica publicou uma matéria sobre a vulnerabilidade CVE-2026-97631 que está presente há 16 anos no EDK II, um projeto de código aberto usado por fabricantes para desenvolver firmware UEFI. A falha pode permitir a execução de código durante a inicialização pela rede, antes que o Secure Boot e outras proteções de inicialização entrem em ação. O problema afeta o código de boot PXE e recebeu pontuação 9,5 de 10 do TianoCore, projeto responsável pelo EDK II.
A falha foi descoberta por Alex Matrosov, da Anthropic, e Dan Holmes-Mitra, do Google. Sua origem está em uma alteração de código feita em novembro de 2010. A divulgação coordenada estava prevista para janeiro de 2027, mas uma proposta de alteração publicada em 28 de setembro revelou o identificador da vulnerabilidade e incluiu uma correção. O TianoCore publicou seu aviso em 22 de outubro. Até a publicação do The Hacker News (28 de outubro), não havia evidências conhecidas de exploração ativa.
Como funciona
O UEFI é o firmware executado nas etapas iniciais do funcionamento do computador, antes do carregamento do sistema operacional. No boot PXE, a máquina obtém pela rede a imagem usada para iniciar, em vez de carregá-la de um disco local.
Durante esse processo, o código PXE do EDK II recebe mensagens de erro ICMP, usadas por dispositivos de rede para comunicar problemas, e as copia para uma área fixa de memória de 504 bytes. Nas rotinas IPv4 e IPv6, porém, as verificações de tamanho estão incorretas. Assim, uma mensagem maior que o espaço reservado pode ultrapassar o limite do buffer e sobrescrever áreas próximas da memória.
Para explorar a falha, o atacante precisa enviar uma mensagem especialmente preparada enquanto a máquina está inicializando por PXE e conseguir alcançá-la pela rede. Não são necessárias senha nem acesso prévio ao equipamento. No entanto, as avaliações citadas pelo The Hacker News indicam que a falha não é diretamente acessível pela internet aberta: a exploração depende de uma posição próxima na rede e de uma janela curta durante a inicialização.
O efeito mais simples é interromper o boot, fazendo a máquina travar ou falhar ao iniciar. A execução de código é mais difícil e exige que o ataque seja adaptado à versão específica do firmware. Se obtida, ela ocorre antes das verificações do Secure Boot. Essa execução, por si só, não persiste após uma reinicialização, mas poderia ser usada para instalar outro componente que persista.
Correção e medidas para reduzir o risco
A falha afeta o EDK II até a versão estável edk2-stable202608, publicada em 21 de agosto de 2026. A correção foi incorporada a branch principal de desenvolvimento em 15 de outubro e limita a cópia das mensagens aos 504 bytes disponíveis. Em 28 de outubro, porém, ainda não havia uma versão estável do EDK II com essa correção, e o aviso do TianoCore não indicava uma versão corrigida. Mesmo depois da inclusão no código-fonte, a proteção depende de cada fabricante incorporar a mudança ao firmware e distribuir uma atualização para seus produtos.
Na data da publicação, os pacotes EDK II do Red Hat Enterprise Linux 8, 9 e 10, além de pacotes equivalentes do SUSE e do Debian, eram apontados como afetados e ainda sem correção. Isso não significa que todos os produtos dessas plataformas estejam vulneráveis: a exposição depende de o equipamento conter o código afetado e usar inicialização pela rede.
A Intel informou que não conhecia produtos comerciais sob suporte de segurança afetados e que seu código de referência não incluía a funcionalidade vulnerável, embora fabricantes de placas ou sistemas possam acrescentá-la. A Arm declarou que a falha não se aplica diretamente ao seu portfólio.
Organizações que não precisam de PXE podem desativar a inicialização pela rede para reduzir a exposição. Nos ambientes que dependem desse recurso, é importante acompanhar os avisos dos fornecedores e a distribuição de atualizações de firmware, além de observar o tráfego de rede e os registros durante o boot. As medidas devem ser avaliadas de acordo com a configuração e as necessidades operacionais de cada ambiente
Conclusão
A CVE-2026-97631 mostra como uma falha de manipulação de memória no firmware pode comprometer a inicialização antes que as proteções do sistema operacional entrem em ação. Apesar do impacto potencial elevado, a exploração depende de condições específicas: o equipamento precisa usar boot PXE, o atacante deve conseguir alcançá-lo durante essa etapa e a execução de código exige adaptação ao firmware. Até a publicação do The Hacker News, não havia evidências conhecidas de ataques em andamento. O principal desafio era a diferença entre a correção estar disponível no código-fonte e sua distribuição efetiva pelos fabricantes.
Referências
Tags: CVE-2026-97631, EDK II, Secure Boot, Vulnerabilidade.
Categorias: CVE, Falhas, Linux, Vulnerabilidade.
Apple corrige zero-day do CoreGraphics explorado em ataques direcionados contra iPhones antigos
A Apple disponibilizou correções para iPhones e iPads mais antigos afetados pela CVE-2026-86950, uma vulnerabilidade no CoreGraphics explorada em ataques…
Múltiplas vulnerabilidades Juniuper Junos OS e Junos OS Evolved
Nos últimos 7 dias (16–23 de outubro de 2026), a Juniper publicou um conjunto relevante de atualizações para Junos OS…
Alerta: Nova vulnerabilidade PHP (CVE-2026-115560)
Dois dias depois dos patches emergenciais do PHP2Shell (CVE-2026-109618 e CVE-2026-109619), o projeto PHP confirmou hoje uma terceira vulnerabilidade de…
[D]iário Threat Watch #003 – PHP2Shell
Em aproximadamente 5.712 ataques recebidos por nossos sensores entre os dias 1º e 21 de setembro, identificamos cerca de 22…
Alerta: vulnerabilidades RCE no PHP vazaram antes da correção oficial
ATUALIZAÇÃO em 21/10/2026 14:50 BRT: As atualizações já estão disponíveis. O PHP publicou as correções hoje, 21/10, um dia antes…
Alerta: Janela de risco para Suporte Remoto da BeyondTrust (CVE-2026-102764)
Nesta quinta-feira, 15 de outubro, a BeyondTrust, que, entre outros ramos, atua como provedora de suporte remoto, anunciou a vulnerabilidade…