Uma investigação da ESET revelou que 11 bootloaders UEFI “shim”, todos assinados digitalmente pela própria Microsoft, permitiram contornar a proteção Secure Boot durante mais de dez anos sem que ninguém detetasse o problema. A falha afeta computadores com Windows e com Linux, e foi corrigida através da atualização de segurança de junho de 2026, com reforço adicional em julho.
O que a ESET descobriu
O investigador Martin Smolár, da ESET, identificou 11 aplicações UEFI antigas — na sua maioria versões 0.9 ou anteriores do projeto open-source “shim”, com datas de assinatura entre 2013 e 2025 — que continuavam a ser confiadas por qualquer sistema que aceite o certificado “Microsoft Corporation UEFI CA 2011”. O shim é um pequeno bootloader inicial que serve de ponte entre o firmware UEFI e o sistema operativo, permitindo sobretudo a distribuições Linux arrancar com o Secure Boot ativo sem que cada distribuição precise de ter a sua própria chave gravada na motherboard.
A ESET comunicou o problema ao CERT/CC a 16 de fevereiro de 2026, através de um processo de divulgação responsável. O caso ficou registado como VU#616257, com dois identificadores CVE atribuídos: CVE-2026-8863 e CVE-2026-10797.
Um ataque sem exploit novo
O que torna este caso particularmente preocupante, segundo a própria ESET, não é a descoberta de uma vulnerabilidade inédita, mas sim o facto de não ser necessário nenhum exploit sofisticado para a explorar. Um atacante só precisa de uma cópia de um dos shims antigos — que pode transportar num pen USB ou colocar diretamente na partição EFI de um computador-alvo — e de conhecimentos básicos sobre o funcionamento do UEFI. Como o Secure Boot valida a assinatura do shim e não a origem do equipamento, a vítima nem sequer precisa de ter esse software instalado à partida: o atacante “traz o seu próprio” bootloader vulnerável, numa técnica próxima do conhecido “bring your own vulnerable driver” (BYOVD).
Um dos dois CVE atribuídos, o CVE-2026-10797, decorre de uma inconsistência técnica: os shims afetados verificam o tamanho de um certificado num local do ficheiro, mas validam a assinatura noutro — uma discrepância que permite adulterar a estrutura do certificado e fazer passar um binário malicioso pela verificação.
Que sistemas estão em risco
Qualquer máquina com UEFI que confie no certificado de terceiros da Microsoft está potencialmente exposta, independentemente de correr Windows ou Linux — o mecanismo de arranque é o mesmo. A ESET alerta que a exploração bem-sucedida pode permitir a instalação de bootkits UEFI maliciosos, como o Bootkitty, o HybridPetya ou o já conhecido BlackLotus, capazes de sobreviver a reinstalações do sistema operativo e, nalguns casos, à própria substituição do disco. Como o código malicioso corre antes do sistema operativo e do software de segurança arrancarem, este tipo de ataque tende a passar despercebido às soluções antivírus convencionais.
Segundo a ESET, os PC com Windows 11 Secured-core não deverão estar vulneráveis por definição, uma vez que este tipo de equipamento desativa, por defeito, a confiança no certificado UEFI de terceiros da Microsoft.
O que já foi corrigido
A Microsoft optou por revogar os 11 binários vulneráveis pelo respetivo valor de hash, adicionando-os à base de dados de assinaturas proibidas do UEFI (DBX) — a única forma eficaz de bloquear especificamente estes ficheiros, já que a mera expiração do certificado que os assinou, ocorrida também em junho de 2026, não impede a sua utilização. A revogação, inicialmente prevista para 19 de maio, acabou por ser adiada para 9 de junho, para dar tempo aos fabricantes afetados de disponibilizarem versões substitutas dos shims.
A lista de revogação atualizada foi distribuída através da atualização cumulativa de junho (KB5094126) e voltou a ser incluída na atualização de julho (KB5101650), pelo que a generalidade dos utilizadores fica protegida ao instalar a atualização mais recente do Windows.
Recomendações práticas
Para cidadãos e profissionais, a recomendação é simples: manter o Windows atualizado através do Windows Update, já que as atualizações cumulativas mais recentes já incluem a lista DBX corrigida. Para administradores de sistemas Linux ou de parques informáticos mistos, o CERT/CC recomenda uma ordem específica de atuação — atualizar primeiro os componentes de arranque e certificados confiáveis (base de dados DB) antes de aplicar a lista de revogação (DBX), para evitar que sistemas legítimos deixem de arrancar. Utilizadores de distribuições Linux podem ainda consultar o Linux Vendor Firmware Service ou o respetivo fornecedor para confirmar o estado de atualização, e verificar o estado de revogação através do script “uefi-dbx-audit”.
Porque é que isto importa
O caso ilustra uma fragilidade estrutural do modelo de confiança do Secure Boot: um mecanismo pensado para impedir a execução de código não autorizado durante o arranque do sistema pode ser contornado através de componentes que, apesar de antigos e publicamente conhecidos como vulneráveis, nunca chegaram a ser explicitamente bloqueados. Para as organizações portuguesas — sobretudo as abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2) — o episódio reforça a importância de manter processos de gestão de vulnerabilidades que cubram também a camada de firmware e arranque, normalmente esquecida face ao foco habitual em sistemas operativos e aplicações. Manter os equipamentos atualizados continua a ser, também neste caso, a medida de proteção mais eficaz e acessível.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela ESET (WeLiveSecurity), pelo CERT/CC e por publicações especializadas em cibersegurança.