Firmware é a brecha de patches que ninguém assume, e a nova falha de UEFI prova isso

Seu EDR é excelente, seu hipervisor está atualizado, suas imagens de contêiner foram reconstruídas ontem à noite. Então, quem aplica patch no código que roda antes de tudo isso existir?

Essa é a pergunta incômoda por trás da CVE-2026-97631, uma falha crítica no TianoCore EDK II, a base de código de referência de código aberto usada pela maioria dos fabricantes de firmware UEFI. Segundo os resumos da apuração do Ars Technica, ela está num componente ICMP, no caminho de boot pela rede, e recebeu nota 9,5 de 10. Permite que um invasor execute código durante o boot, antes que proteções como Secure Boot e o TPM consigam estabelecer uma cadeia de confiança.

Alguns detalhes importam. Os payloads, segundo relatos, não persistem sozinhos, mas podem instalar outro código que roda em todo boot seguinte. A falha também veio a público antes de uma divulgação planejada para janeiro, de acordo com um resumo da FourWeekMBA sobre a Ars. E Jesse Michael, da Eclypsium, disse à Ars que a correção exige instalar uma atualização de BIOS/UEFI.

“A maioria dos servidores do planeta” é manchete, não medição

Primeiro, um pouco de cautela. A manchete diz que a falha ameaça a maioria dos servidores do planeta. Como o Tech Insider observa, a cobertura diz que o código de referência é usado pela maioria dos fabricantes de servidores do mundo, mas não informa quantas máquinas são afetadas nem qual a porcentagem. Código compartilhado não é o mesmo que exposição compartilhada. As versões e configurações de cada fabricante provavelmente diferem, e se uma determinada máquina é alcançável por esse caminho de boot pela rede provavelmente depende da configuração.

Achamos que essa nuance vale para os dois lados. Significa que você não deve reiniciar toda a frota em pânico esta noite. Significa também que não dá para saber sua exposição por uma manchete, e suspeitamos que muitas organizações também não conseguem responder com os próprios registros. Essa é a verdadeira história.

O bug é novo; o pipeline quebrado é antigo

Veja como uma correção de firmware viaja. Na cobertura da Ars em 2024 sobre uma onda anterior de bugs de UEFI, a cadeia foi descrita com clareza: os fabricantes de firmware enviam atualizações a seus clientes, e esses clientes disponibilizam os patches aos seus próprios clientes, geralmente os usuários finais. Cada etapa é uma empresa diferente e, na nossa visão, ninguém é dono do caminho inteiro.

Compare com um bug em biblioteca. Quando uma falha no Brotli surgiu recentemente, Google e Node.js lançaram correções em 21 de outubro e a Microsoft veio em seguida com uma atualização de emergência do.NET no fim de semana, segundo o TechRadar. Até isso foi bagunçado: cópias embutidas fazem com que atualizar apenas a biblioteca do Google não proteja todos os aplicativos. Mas a correção ao menos passa por canais que a maioria das equipes já sabe operar, como atualizações de pacotes e novos deploys. O firmware não tem rotina assim. É preciso descobrir qual imagem de qual fornecedor você usa, esperar o OEM reempacotá-la, agendar uma janela de manutenção e gravar o firmware em máquinas que ninguém quer reiniciar.

Há ainda a camada em que os defensores normalmente pegariam um problema. O código de pré-boot roda abaixo do sistema operacional, então as ferramentas em que a maioria das equipes confia podem ter pouca visibilidade sobre ele. O firmware também teve alguns meses ruins. Em setembro, o Cybernews relatou um bypass do Secure Boot via UEFI Shell, reconhecido por AMI, Gigabyte, Insyde e Cisco, com provavelmente muitos outros fabricantes afetados. Dois incidentes em dois meses não fazem uma tendência por si sós, mas apontam para um ponto fraco.

Trate o firmware como um produto com dono

Nosso veredito é simples: se o firmware não tem dono na sua equipe, você já decidiu aplicar o patch tarde. A solução é mais de processo do que de ferramenta.

• Faça o inventário. Saiba qual versão de firmware e qual build de qual fornecedor há em cada servidor. Sem isso, responder “estamos afetados?” leva dias em vez de minutos.
• Nomeie um responsável. Alguém deveria acompanhar os avisos dos fornecedores e ter autoridade para agendar janelas de manutenção, como uma equipe cuida da cadência de patches do sistema operacional.
• Reduza a superfície alcançável. Se você não precisa de boot pela rede numa máquina, desativá-lo pode ser uma mitigação barata. Não podemos prometer que cubra todas as configurações, então confira o que diz seu fornecedor.
• Ensaie a gravação. Uma atualização de BIOS que nunca foi praticada no seu hardware é uma aposta na hora em que importa.

Os fornecedores também têm lição de casa. Uma base de código de referência compartilhada por todo o setor deveria vir com uma forma compartilhada e previsível de levar as correções aos clientes. Até que isso exista, o peso cai sobre os administradores, o que não é justo, mas é a realidade.

A lição desta CVE não será lembrada pela nota. A pergunta a fazer é quanto tempo sua organização levaria para saber quais máquinas estão expostas. Se a resposta honesta for “teríamos que descobrir”, o firmware é a sua brecha de patches, e ninguém mais vai fechá-la.