Investigadores da ESET revelaram que uma das defesas mais elementares do arranque dos computadores modernos — o UEFI Secure Boot — pôde ser contornada durante mais de uma década por causa de bootloaders antigos assinados pela Microsoft e nunca revogados. A equipa identificou 11 shims na versão 0.9 ou anterior, alguns com origem em 2013, que continuavam a ser aceites por praticamente qualquer máquina que confie no certificado “Microsoft Corporation UEFI CA 2011”. O caso foi documentado em fevereiro de 2026, coordenado pelo CERT/CC e corrigido no Patch Tuesday de junho de 2026 da Microsoft.
Resposta rápida: A ESET encontrou 11 shims UEFI assinados pela Microsoft que permitiam contornar o Secure Boot sem qualquer exploit novo — bastava copiar um binário antigo ainda de confiança. A Microsoft revogou-os na atualização de 9 de junho de 2026, adicionando as suas assinaturas à base de dados dbx. A ação recomendada é simples: aplicar as atualizações cumulativas de junho/julho de 2026 no Windows e, em Linux, atualizar via LVFS.
O que são shims e porque é que isto importa
O Secure Boot é uma norma que garante que apenas software de confiança corre durante o arranque, antes do sistema operativo assumir o controlo. Para permitir que o Linux e diversas ferramentas arranquem sob Secure Boot, a Microsoft assina um pequeno carregador de primeira fase chamado shim. A vasta maioria dos computadores UEFI transporta um certificado da Microsoft que confia num pequeno carregador de primeira fase chamado shim, um programa que a Microsoft assina para que o Linux e diversas ferramentas de arranque possam correr com o Secure Boot ativado.
O problema não está na criptografia. A ESET identificou 11 shim bootloaders UEFI antigos e esquecidos, nas versões 0.9 e anteriores, que podem ser usados para contornar o UEFI Secure Boot em qualquer máquina baseada em UEFI que confie no certificado “Microsoft Corporation UEFI CA 2011”, independentemente do sistema operativo instalado. Por outras palavras, qualquer computador que confie no certificado de terceiros da Microsoft aceitava estes carregadores, mesmo que estivessem cheios de falhas conhecidas.
A gravidade reside na simplicidade. Segundo a ESET, o que torna estes shims antigos perigosos não é uma vulnerabilidade nova — é que não é necessária qualquer vulnerabilidade nova para contornar o UEFI Secure Boot. Um atacante não precisa de primitivas de exploração complicadas, apenas de uma cópia de um shim antigo, ainda de confiança mas não revogado, e de uma compreensão básica de como funcionam os shims UEFI. Na prática, um atacante copia um destes shims antigos para uma máquina-alvo com um carregador de segunda fase correspondente, e a cadeia de arranque aceita-o.
Onde estavam as falhas
Os binários afetados provinham de produtos conhecidos. Estão afetados 11 binários na versão 0.9 ou anterior, e podem ser explorados em qualquer máquina que confie no certificado de 2011, independentemente do sistema operativo instalado. Os produtos afetados incluem Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2 e distribuições ROSA Linux, além de binários OpenSUSE.
As fraquezas eram de três tipos. Em primeiro lugar, os shims mais antigos confiavam em versões vulneráveis do GRUB 2. Em segundo, antecediam mecanismos modernos de revogação: a lista de negação da Machine Owner Key chegou com o shim versão 0.9, e as versões mais antigas podem não processar corretamente os metadados SBAT modernos ou fazer cumprir as revogações baseadas em MOK. Em terceiro, uma das duas vulnerabilidades atribuídas explora um erro no cabeçalho de assinatura: os shims afetados leem o tamanho da assinatura em dois locais diferentes do binário PE, permitindo que as verificações de revogação sejam aplicadas a dados falsos.
O caso ficou associado a dois identificadores. Os problemas são rastreados sob os identificadores CVE-2026-8863 e CVE-2026-10797, sendo este último relativo a um problema há muito corrigido no shim que permitia contornar o mecanismo de revogação baseado em certificados modificando o cabeçalho de assinatura do carregador de segunda fase. O caso é rastreado como VU#616257, cobrindo os CVE-2026-8863 e CVE-2026-10797.
Um ponto contraintuitivo: a expiração do certificado não resolve nada. A ESET alertou que a expiração do certificado “Microsoft Corporation UEFI CA 2011” não tem qualquer influência no processo de verificação do Secure Boot enquanto os bootloaders assinados com o certificado expirado não forem explicitamente revogados por hash. O certificado expirou em 27 de junho de 2026, mas essa data não tem impacto na verificação: enquanto o certificado permanecer em db sem ser revogado em dbx, os binários que assinou continuam de confiança.
Cronologia da divulgação e da correção
| Data | Evento |
|---|---|
| 16 fev. 2026 | ESET (Martin Smolár) reporta ao CERT/CC |
| 19 mai. 2026 | Data de revogação inicialmente prevista |
| 9 jun. 2026 | Patch Tuesday: Microsoft revoga os 11 shims via dbx (KB5094126) |
| 27 jun. 2026 | Expiração do certificado Microsoft Corporation UEFI CA 2011 |
| Jul. 2026 | Revogações incluídas na atualização cumulativa (KB5101650); divulgação técnica completa |
A ESET reportou as descobertas ao CERT/CC em 16 de fevereiro de 2026. A Microsoft definiu inicialmente uma data de revogação de 19 de maio, mas adiou-a para 9 de junho, dando aos fornecedores afetados tempo para distribuírem shims de substituição antes de os antigos serem totalmente bloqueados. A Microsoft distribuiu primeiro as revogações através da atualização de junho de 2026 KB5094126 e incluiu-as também na atualização cumulativa de julho, a KB5101650.
A parte inquietante: quantos shims esquecidos faltam?
A revogação destes 11 binários não fecha necessariamente o capítulo. A ESET avisa que podem existir mais shims assinados e esquecidos ainda por descobrir. A base de dados de revogação é apenas tão boa quanto a auditoria que a sustenta. A própria ESET nota que este ecossistema de assinatura de terceiros ainda tem margem para transparência, apontando outros carregadores UEFI não-shim como fonte recorrente de bypasses ao longo dos anos.
Como verificar e mitigar
A boa notícia é que a mitigação é acessível e, na maioria dos casos, automática:
- Windows: as máquinas Windows recebem a atualização dbx automaticamente, e a ESET publicou comandos PowerShell, a executar com permissões elevadas, que verificam se os onze hashes revogados estão presentes. Aplique as atualizações cumulativas de junho ou julho de 2026.
- Linux: os sistemas Linux podem obter a atualização através do Linux Vendor Firmware Service e confirmar o resultado com o script
uefi-dbx-audit. - PCs Secured-core: os PCs Windows 11 Secured-core deverão ter a assinatura de terceiros desativada por predefinição.
- Ordem das operações: segundo o CERT/CC, os administradores devem atualizar a base de dados de assinaturas (db) antes de aplicar as revogações dbx — ou seja, atualizar aplicações de arranque e certificados de confiança primeiro, seguidos da lista de revogação; caso contrário, os sistemas podem rejeitar componentes de arranque recém-atualizados.
Convém ainda dar atenção especial às máquinas fora do ciclo normal de manutenção — servidores antigos, endpoints industriais de longa duração, imagens de instalação obsoletas e dispositivos de dual-boot — porque são exatamente estas as mais suscetíveis de ficar por atualizar.
Porque é que isto importa em Portugal
Ameaças ao nível do arranque são particularmente perigosas porque vivem abaixo do sistema operativo: soluções de EDR não as veem, reinstalar o Windows não as remove e os shims comprometidos podem servir de trampolim para bootkits UEFI como o BlackLotus. Para PME e organizações portuguesas, isto reforça a mensagem de que a gestão de vulnerabilidades tem de incluir a cadeia de arranque e o firmware, não apenas o software aplicacional.
No plano regulatório, o novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2) impõe às entidades abrangidas obrigações de gestão de risco e de aplicação atempada de correções — algo que abrange também a integridade do arranque. O CNCS e o CERT.PT recomendam de forma consistente a aplicação célere de atualizações de segurança. E quando um comprometimento ao nível do firmware puser em risco dados pessoais, aplicam-se as obrigações do RGPD, incluindo a eventual notificação à CNPD e aos titulares afetados.
Perguntas frequentes
O meu computador está em risco?
Qualquer máquina UEFI que confie no certificado “Microsoft Corporation UEFI CA 2011” e que não tenha aplicado a atualização de revogação de junho ou julho de 2026 pode aceitar os shims vulneráveis. A exploração exige, contudo, acesso local ao dispositivo. Aplicar as atualizações cumulativas mais recentes resolve a exposição na maioria dos casos.
A expiração do certificado em junho de 2026 não me protege?
Não. A ESET foi clara: enquanto o certificado permanecer na base de dados de confiança (db) sem que os hashes dos binários vulneráveis sejam revogados na dbx, esses binários continuam a ser aceites no arranque. A única mitigação efetiva é a revogação por hash através da atualização dbx.
Como verifico se a minha máquina já está protegida?
Em Windows, a atualização dbx chega automaticamente pelo Windows Update, e a ESET disponibilizou comandos PowerShell (executados com permissões elevadas) para confirmar se os onze hashes revogados estão presentes. Em Linux, pode obter a atualização via Linux Vendor Firmware Service e validar com o script uefi-dbx-audit.
Podem existir mais shims vulneráveis por revogar?
Sim. A ESET alertou que podem existir outros shims antigos e esquecidos ainda por descobrir, porque o repositório de revisão de shims só regista submissões a partir de 2017. A eficácia da base de dados de revogação depende da qualidade da auditoria que a suporta.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela ESET (WeLiveSecurity), pelo CERT Coordination Center e pela Microsoft.