themalwareguardian/cve-2026-25250Análise e exploit para CVE-2026-25250, uma bypass do Secure Boot no Horizon DataSys Reboot Restore, onde o shdloader.efi carrega o Shield.efi sem verificação.
Um bootloader de terceiros assinado pela Microsoft que carrega um binário EFI secundário sem verificação de assinatura ou integridade, colapsando a cadeia de confiança do Secure Boot a partir de dentro.
Este repositório documenta a pesquisa sobre CVE-2026-25250, uma vulnerabilidade de bypass do Secure Boot divulgada à Microsoft e à qual foi atribuído um CVE em abril de 2026. Rapidamente se destacou como um dos problemas de segurança de firmware mais significativos do ano, precisamente porque o componente vulnerável é assinado pela Microsoft e, portanto, incondicionalmente confiável na grande maioria dos sistemas Windows habilitados para UEFI.
A vulnerabilidade foi descoberta por Mickey Shkatov e Stanislav Lyakhov na Eclypsium, uma das principais equipes de pesquisa de segurança de firmware e cadeia de suprimentos da indústria. Mickey Shkatov é uma figura de longa data na pesquisa ofensiva de UEFI, autor do BootHole (CVE-2020-10713, um bypass crítico do Secure Boot do GRUB2 que afetou praticamente todas as distribuições Linux e configurações de dual-boot com Windows), e apresentador de "One Bootloader to Load Them All" na DEF CON 30 ao lado de Jesse Michael, uma palestra que catalogou sistematicamente como bootloaders de terceiros assinados pela Microsoft representam uma fraqueza de classe no ecossistema do Secure Boot.
O CVE-2026-25250 se enquadra exatamente nessa classe.
O que o torna particularmente instrutivo é a sua simplicidade: sem corrupção de memória, sem falha criptográfica no próprio firmware, apenas um binário confiável tomando uma decisão insegura sobre o que carrega em seguida. Um único elo fraco é suficiente para colapsar todo o modelo do Secure Boot para um sistema alvo.
O CVE-2026-25250 foi descoberto durante a análise de componentes de boot UEFI de terceiros implantados em ambientes empresariais de recuperação. O produto afetado é a solução Reboot Restore da Horizon DataSys.
A vulnerabilidade foi atribuída pela MITRE em vez da Microsoft, porque a falha reside em firmware de terceiros (shdloader.efi), não no Windows ou em qualquer código de autoria da Microsoft.
Referências oficiais:
Centro de Resposta de Segurança da Microsoft - Patch Tuesday de abril de 2026
Boletim mensal de atualizações de segurança.
Entrada oficial do CVE. CVSS 6.0 - AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N. CWE-325: Etapa Criptográfica Obrigatória Ausente.
Divulgação Técnica da Eclypsium
Divulgação original da pesquisa pela equipe descobridora, incluindo a publicação no LinkedIn que primeiro trouxe esta vulnerabilidade à atenção pública.
A divulgação da Eclypsium, publicada no LinkedIn pela equipe descobridora, fornece contexto suficiente para identificar o software afetado e baixá-lo diretamente do site do fornecedor.
O instalador do Horizon DataSys Reboot Restore está disponível publicamente, e instalá-lo em um sistema de teste coloca tanto o shdloader.efi quanto o Shield.efi na Partição do Sistema EFI, onde podem ser examinados estaticamente ou observados em tempo de execução.
Configuração de laboratório recomendada:
VM Windows 10/11 (QEMU ou VMware)
├── Secure Boot: Ativado
├── Horizon DataSys Reboot Restore: Instalado
├── ESP acessível via: mountvol X: /S
└── Alvos:
HorizonDataSys
X:\EFI\shdloader.efi ← assinado, confiável, carrega o próximo estágio
X:\EFI\Shield.efi ← carregado sem qualquer verificação
Uma vez instalado, o shdloader.efi pode ser confirmado como assinado pela Microsoft CA 2011 via sigcheck.exe (Sysinternals) ou pesign. A ausência de qualquer chamada LoadImage / StartImage no caminho de carregamento do Shield.efi é visível imediatamente na análise estática.
Esta vulnerabilidade afeta uma cadeia de boot em múltiplos estágios, não um único binário.
A vulnerabilidade não reside no firmware. Ela reside na lógica de um bootloader confiável, um binário que o firmware já aprovou, que escolhe carregar um binário secundário através de um caminho de código que ignora todas as verificações de segurança.
Firmware
└── verifica shdloader.efi ✅ Microsoft CA 2011, confiável
└── ManualPEParse(Shield.efi) ❌ sem LoadImage, sem verificação de assinatura
└── EntryPoint() 💥 código controlado pelo atacante, pré-OS
O perímetro do Secure Boot é tão forte quanto o binário menos cuidadoso que ele confia.
O CVE-2026-25250 é um bypass do Secure Boot causado pela validação incorreta de um binário EFI secundário carregado durante o processo de boot. O bootloader afetado (shdloader.efi) é assinado e confiável pelo Secure Boot, mas carrega o Shield.efi através de uma rotina manual de parsing de PE sem qualquer verificação criptográfica de nenhum tipo.
É uma falha de design e de modelo de confiança, um componente confiável tomando uma decisão insegura que anula todas as proteções a jusante.
O Secure Boot impõe uma cadeia de confiança na qual cada componente executado durante a sequência de boot deve ser verificado antes que o controle seja transferido. O modelo só se mantém se cada binário confiável na cadeia honrar esse contrato:
Firmware → verifica bootloader → bootloader executa apenas código verificado
O CVE-2026-25250 quebra o segundo elo:
Firmware → verifica shdloader.efi (✅ confiável)
↓
shdloader.efi → carrega Shield.efi (❌ não verificado)
↓
Código arbitrário não assinado executa pré-boot
A aplicação do Secure Boot no nível do firmware torna-se irrelevante uma vez que um binário confiável introduz um caminho de execução não verificado.
Classificado como:
Uma operação sensível à segurança é executada sem uma etapa obrigatória de verificação criptográfica, permitindo que um atacante ignore a proteção que essa etapa teria aplicado.
| Etapa | Executada | Observações |
|---|
| Localizar Shield.efi na ESP | ✅ | Acesso padrão ao sistema de arquivos |
| Ler arquivo na memória | ✅ | - |
| Analisar cabeçalhos PE manualmente | ✅ | Implementação personalizada |
| Verificar assinatura | ❌ | Não executada |
| Verificar contra db / dbx | ❌ | Não executada |
| Chamar LoadImage / StartImage | ❌ | Ignorado completamente |
| Transferir execução para o entry point | ✅ | Chamada direta |
A ausência de LoadImage / StartImage é a causa raiz. Esses Boot Services UEFI são o ponto de integração para a aplicação da política do Secure Boot; ignorá-los significa ignorar tudo.
A exploração requer acesso de Administrador local e uma única reinicialização.
Na próxima inicialização, o shdloader.efi é executado (confiável pelo firmware), carrega o binário controlado pelo atacante e transfere a execução, pré-OS, pré-EDR, antes que qualquer política de boot medida seja aplicada, sem qualquer objeção do Secure Boot.
Permite:
Eclypsium - Divulgação do CVE-2026-25250
Pesquisa original por Mickey Shkatov e Stanislav Lyakhov. A publicação no LinkedIn da Eclypsium anunciando a descoberta fornece links para o software Horizon DataSys, permitindo análise independente.
Microsoft MSRC - Patch Tuesday de abril de 2026
Boletim de segurança da Microsoft.
Entrada oficial do CVE. Atribuído pela MITRE porque a vulnerabilidade reside em firmware de terceiros, não em código da Microsoft.
Eclypsium - BootHole (CVE-2020-10713)
Mickey Shkatov e Jesse Michael - bypass crítico do Secure Boot do GRUB2 que afeta praticamente todas as distribuições Linux e sistemas com dual-boot Windows.
DEF CON 30 - "One Bootloader to Load Them All"
Mickey Shkatov e Jesse Michael - análise sistemática de bootloaders de terceiros assinados pela Microsoft como uma superfície de ataque de classe do Secure Boot. O CVE-2026-25250 é uma instância direta desse modelo de ameaça.
CWE-325: Etapa Criptográfica Obrigatória Ausente
Classificação da causa raiz para a verificação ausente no caminho de carregamento do
shdloader.efi.
Especificação UEFI - Boot Services: LoadImage / StartImage
Os Boot Services UEFI que aplicam a política do Secure Boot - completamente ignorados pelo carregador PE manual do
shdloader.efi.
Trabalhando em algo semelhante? Pesquisando segurança de UEFI, kernel, exploração ou outro tópico interessante de segurança? Se você precisar de ajuda para desenvolver um exploit, explorar uma técnica ou apenas quiser trocar ideias, não hesite em entrar em contato. Estou sempre aberto a discutir pesquisas, ajudar onde puder e colaborar em projetos interessantes. Sinta-se à vontade para me contatar no LinkedIn.