Shim ist ein leichtgewichtiger, quelloffener UEFI-Bootloader, der zwischen der Firmware des Mainboards und Linux vermittelt. Er soll Linux-Distributionen den Start bei aktiviertem Secure Boot ermöglichen. Der Ablauf: Die UEFI-Firmware lädt zunächst Shim und prüft dessen Signatur gegen die in der Firmware hinterlegte Microsoft-Zertifizierungsstelle. Danach verifiziert Shim den Bootloader der zweiten Stufe, meist GRUB 2, anhand eines eingebetteten Herstellerzertifikats. GRUB 2 prüft schließlich den Kernel mit demselben Zertifikat.

Laut ESET lassen sich vor allem Bootloader des offenen Shim-Projekts bis einschließlich Version 0.9 missbrauchen. Die veralteten, aber weiterhin als vertrauenswürdig behandelten Komponenten erlauben es, beim Start beliebigen Code auszuführen. Damit könnten Angreifer UEFI-Bootkits wie Bootkitty, HybridPetya oder BlackLotus einschleusen, obwohl Secure Boot aktiv ist.

Der Angriff nutzt keine neue Lücke in Secure Boot selbst aus, sondern die Tatsache, dass alte, signierte Shim-Binaries noch akzeptiert werden. Nach Einschätzung von ESET kann ein Angreifer einen aktuellen Shim durch einen älteren, von Microsoft signierten Shim ersetzen. So lässt sich die Durchsetzung der MOK-Sperrliste umgehen, obwohl in Shim 0.9 eine MOK-Denylist eingeführt wurde, um alte Signaturzertifikate verwundbarer UEFI-Binaries zu widerrufen und gepatchte Versionen neu zu signieren. Wenn die Allowlist das alte Zertifikat weiterhin akzeptiert, kann ein manipuliertes Shim anfällige Binärdateien ohne Einschränkung laden und so beliebigen Code ausführen.

Darüber hinaus hebelt die Methode auch Secure Boot Advanced Targeting, kurz SBAT, aus. Dieser Mechanismus soll verwundbare Boot-Komponenten gezielt sperren, ohne eine riesige Blockliste einzelner Dateihashes pflegen zu müssen. Er setzt dafür eine Mindestgeneration pro Komponente fest. Wird eine ältere, verwundbare Version gestartet, blockiert das System den Bootvorgang und meldet einen Fehler. Laut dem Bericht lässt sich auch dieser Schutz unterlaufen.

CERT/CC hatte bereits im vergangenen Monat darauf hingewiesen, dass herstellerspezifische Bootloader nach der öffentlichen Bekanntmachung und Behebung der Schwachstellen im Ursprungsprojekt nicht aktualisiert wurden. Dadurch blieben verwundbare Bootloader weiter signiert und für Secure-Boot-Systeme vertrauenswürdig, weil sie nicht über die von Microsoft signierte DBX-Widerrufsliste gesperrt worden waren. Nach Einschätzung von CERT/CC entstand so eine langfristige Exponierung der Lieferkette, bei der veraltete und anfällige Boot-Komponenten selbst auf vollständig gepatchten Systemen noch ausgeführt werden konnten.

Voraussetzung für den Missbrauch ist laut ESET, dass ein Angreifer Administratorrechte besitzt oder den Bootprozess verändern kann. Dann kann er einen der verwundbaren Shim-Bootloader nutzen, um Secure Boot zu umgehen und noch vor dem Laden des Betriebssystems beliebigen Code auszuführen. Weil dies vor der Initialisierung von Betriebssystem und Schutzsoftware geschieht, kann der Code auch integrierte Sicherheitskontrollen sowie EDR-Lösungen umgehen.

Die Probleme werden unter CVE-2026-8863 und CVE-2026-10797 geführt. Letztere Kennung bezeichnet eine seit Langem gepatchte Schwachstelle in Shim, bei der sich der zertifikatbasierte Widerrufsmechanismus durch Änderungen am Signatur-Header des Bootloaders der zweiten Stufe umgehen ließ. ESET betont, das Gefährliche an den alten Shims sei nicht eine neue Schwachstelle, sondern dass zur Umgehung von UEFI Secure Boot gar keine neue Schwachstelle nötig sei: Eine Kopie eines alten, weiter vertrauten und nicht widerrufenen Shim-Binaries sowie Grundwissen über die Funktionsweise von UEFI-Shims genügten dafür.