themalwareguardian/cve-2026-25250Analyse und Exploit für CVE-2026-25250, eine Secure-Boot-Umgehung in Horizon DataSys Reboot Restore, bei der shdloader.efi Shield.efi ohne Verifizierung lädt.
Ein von Microsoft signierter Drittanbieter-Bootloader, der eine sekundäre EFI-Binärdatei ohne Signatur- oder Integritätsprüfung lädt und damit die Secure-Boot-Vertrauenskette von innen heraus zum Einsturz bringt.
Dieses Repository dokumentiert Forschung zu CVE-2026-25250, einer Secure-Boot-Bypass-Schwachstelle, die Microsoft gemeldet und im April 2026 eine CVE-Nummer erhalten hat. Sie stach schnell als eines der bedeutendsten Firmware-Sicherheitsprobleme des Jahres hervor, gerade weil die verwundbare Komponente von Microsoft signiert und daher auf der überwältigenden Mehrheit der UEFI-fähigen Windows-Systeme bedingungslos vertraut wird.
Die Schwachstelle wurde von Mickey Shkatov und Stanislav Lyakhov bei Eclypsium entdeckt, einem der führenden Forschungsteams für Firmware- und Lieferketten-Sicherheit der Branche. Mickey Shkatov ist eine langjährige Größe in der offensiven UEFI-Forschung, Autor von BootHole (CVE-2020-10713, ein kritischer GRUB2-Secure-Boot-Bypass, der praktisch jede Linux-Distribution und Windows-Dual-Boot-Konfiguration betraf), und Präsentator von "One Bootloader to Load Them All" auf der DEF CON 30 zusammen mit Jesse Michael, einem Vortrag, der systematisch katalogisierte, wie von Microsoft signierte Drittanbieter-Bootloader eine Schwachstelle auf Klassenebene im Secure-Boot-Ökosystem darstellen.
CVE-2026-25250 fällt genau in diese Klasse.
Was sie besonders lehrreich macht, ist ihre Einfachheit: keine Speicherkorruption, kein kryptografischer Fehler in der Firmware selbst, sondern nur eine vertrauenswürdige Binärdatei, die eine unsichere Entscheidung darüber trifft, was sie als Nächstes lädt. Ein einziges schwaches Glied genügt, um das gesamte Secure-Boot-Modell für ein Zielsystem zum Einsturz zu bringen.
CVE-2026-25250 wurde während der Analyse von UEFI-Boot-Komponenten von Drittanbietern entdeckt, die in Enterprise-Wiederherstellungsumgebungen eingesetzt werden. Das betroffene Produkt ist die Reboot-Restore-Lösung von Horizon DataSys.
Die Schwachstelle wurde von MITRE und nicht von Microsoft zugewiesen, da der Fehler in Drittanbieter-Firmware (shdloader.efi) liegt, nicht in Windows oder in von Microsoft verfasstem Code.
Offizielle Referenzen:
Microsoft Security Response Center - April 2026 Patch Tuesday
Monatliches Sicherheitsupdate-Bulletin.
Offizieller CVE-Eintrag. CVSS 6.0 - AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N. CWE-325: Fehlender erforderlicher kryptografischer Schritt.
Eclypsium Technische Offenlegung
Ursprüngliche Forschungs-Offenlegung des Entdeckungsteams, einschließlich des LinkedIn-Beitrags, der diese Schwachstelle erstmals der Öffentlichkeit zugänglich machte.
Die Offenlegung von Eclypsium, die vom Entdeckungsteam auf LinkedIn veröffentlicht wurde, liefert genügend Kontext, um die betroffene Software zu identifizieren und direkt von der Website des Anbieters herunterzuladen.
Das Horizon DataSys Reboot Restore-Installationsprogramm ist öffentlich verfügbar, und die Installation auf einem Testsystem platziert sowohl shdloader.efi als auch Shield.efi in der EFI-Systempartition, wo sie statisch untersucht oder zur Laufzeit beobachtet werden können.
Empfohlenes Labor-Setup:
Windows 10/11 VM (QEMU oder VMware)
├── Secure Boot: Aktiviert
├── Horizon DataSys Reboot Restore: Installiert
├── ESP zugänglich über: mountvol X: /S
└── Ziele:
HorizonDataSys
X:\EFI\shdloader.efi ← signiert, vertrauenswürdig, lädt nächste Stufe
X:\EFI\Shield.efi ← ohne jegliche Überprüfung geladen
Nach der Installation kann shdloader.efi über sigcheck.exe (Sysinternals) oder pesign als mit Microsoft CA 2011 signiert bestätigt werden. Das Fehlen jeglicher LoadImage-/StartImage-Aufrufe im Shield.efi-Ladepfad ist in der statischen Analyse sofort sichtbar.
Diese Schwachstelle betrifft eine mehrstufige Boot-Kette, nicht eine einzelne Binärdatei.
Die Schwachstelle liegt nicht in der Firmware. Sie liegt in der Logik eines vertrauenswürdigen Bootloaders, einer Binärdatei, die die Firmware bereits genehmigt hat, die sich dafür entscheidet, eine sekundäre Binärdatei über einen Codepfad zu laden, der jede Sicherheitsprüfung umgeht.
Firmware
└── verifiziert shdloader.efi ✅ Microsoft CA 2011, vertrauenswürdig
└── ManualPEParse(Shield.efi) ❌ kein LoadImage, keine Signaturprüfung
└── EntryPoint() 💥 Angreifer-kontrollierter Code, vor dem OS
Die Secure-Boot-Perimeter ist nur so stark wie die am wenigsten sorgfältige Binärdatei, der sie vertraut.
CVE-2026-25250 ist ein Secure-Boot-Bypass, der durch eine fehlerhafte Validierung einer sekundären EFI-Binärdatei verursacht wird, die während des Boot-Prozesses geladen wird. Der betroffene Bootloader (shdloader.efi) ist signiert und wird von Secure Boot vertraut, lädt jedoch Shield.efi über eine manuelle PE-Parsing-Routine ohne jegliche kryptografische Überprüfung.
Es handelt sich um ein Versagen des Designs und des Vertrauensmodells: Eine vertrauenswürdige Komponente trifft eine unsichere Entscheidung, die alle nachgelagerten Schutzmechanismen zunichtemacht.
Secure Boot erzwingt eine Vertrauenskette, in der jede während der Boot-Sequenz ausgeführte Komponente verifiziert werden muss, bevor die Kontrolle übergeben wird. Das Modell hält nur, wenn jede vertrauenswürdige Binärdatei in der Kette diesen Vertrag einhält:
Firmware → verifiziert Bootloader → Bootloader führt nur verifizierten Code aus
CVE-2026-25250 bricht das zweite Glied:
Firmware → verifiziert shdloader.efi (✅ vertrauenswürdig)
↓
shdloader.efi → lädt Shield.efi (❌ nicht verifiziert)
↓
Beliebiger unsignierter Code wird vor dem Boot ausgeführt
Die Durchsetzung von Secure Boot auf Firmware-Ebene wird irrelevant, sobald eine vertrauenswürdige Binärdatei einen unverifizierten Ausführungspfad einführt.
Klassifiziert als:
Eine sicherheitsrelevante Operation wird ohne einen erforderlichen kryptografischen Verifizierungsschritt durchgeführt, wodurch ein Angreifer den Schutz umgehen kann, den dieser Schritt durchgesetzt hätte.
| Schritt | Durchgeführt | Anmerkungen |
|---|
| Shield.efi auf ESP lokalisieren | ✅ | Standard-Dateisystemzugriff |
| Datei in den Speicher lesen | ✅ | - |
| PE-Header manuell parsen | ✅ | Benutzerdefinierte Implementierung |
| Signatur verifizieren | ❌ | Nicht durchgeführt |
| Gegen db / dbx prüfen | ❌ | Nicht durchgeführt |
| LoadImage / StartImage aufrufen | ❌ | Vollständig umgangen |
| Ausführung an Einstiegspunkt übergeben | ✅ | Direkter Aufruf |
Das Fehlen von LoadImage / StartImage ist die Root Cause. Diese UEFI-Boot-Services sind der Integrationspunkt für die Durchsetzung der Secure-Boot-Richtlinie; sie zu umgehen bedeutet, alles zu umgehen.
Die Ausnutzung erfordert lokalen Administratorzugriff und einen einzigen Neustart.
Beim nächsten Boot führt shdloader.efi aus (von der Firmware vertraut), lädt die vom Angreifer kontrollierte Binärdatei und übergibt die Ausführung vor dem OS, vor EDR, bevor eine gemessene Boot-Richtlinie durchgesetzt wird, ohne Einwand von Secure Boot.
Ermöglicht:
Eclypsium - CVE-2026-25250 Offenlegung
Ursprüngliche Forschung von Mickey Shkatov und Stanislav Lyakhov. Der Eclypsium-LinkedIn-Beitrag, der die Entdeckung ankündigt, verlinkt auf die Horizon DataSys-Software und ermöglicht so eine unabhängige Analyse.
Microsoft MSRC - April 2026 Patch Tuesday
Microsoft-Sicherheitsbulletin.
Offizieller CVE-Eintrag. Von MITRE zugewiesen, da die Schwachstelle in Drittanbieter-Firmware liegt, nicht in Microsoft-Code.
Eclypsium - BootHole (CVE-2020-10713)
Mickey Shkatov & Jesse Michael - kritischer GRUB2-Secure-Boot-Bypass, der praktisch alle Linux-Distributionen und Windows-Dual-Boot-Systeme betrifft.
DEF CON 30 - "One Bootloader to Load Them All"
Mickey Shkatov & Jesse Michael - systematische Analyse von Microsoft-signierten Drittanbieter-Bootloadern als Secure-Boot-Angriffsfläche auf Klassenebene. CVE-2026-25250 ist ein direktes Beispiel dieses Bedrohungsmodells.
CWE-325: Missing Required Cryptographic Step
Root-Cause-Klassifizierung für die fehlende Verifizierung im
shdloader.efi-Ladepfad.
UEFI-Spezifikation - Boot Services: LoadImage / StartImage
Die UEFI-Boot-Services, die die Secure-Boot-Richtlinie durchsetzen - vollständig umgangen durch den manuellen PE-Loader von
shdloader.efi.
Arbeitest du an etwas Ähnlichem? Recherchierst du zu UEFI, Kernel-Sicherheit, Exploitation oder einem anderen interessanten Sicherheitsthema? Wenn du Hilfe bei der Entwicklung eines Exploits, der Erforschung einer Technik benötigst oder einfach nur Ideen austauschen möchtest, zögere nicht, dich zu melden. Ich bin immer offen für die Diskussion von Forschung, helfe wo ich kann und kollaboriere gerne an interessanten Projekten. Kontaktiere mich gerne auf LinkedIn.