Nach Angaben von ESET wurden die betroffenen Anwendungen erst am Patch Tuesday im Juni 2026 von Microsoft widerrufen. Für die Funde wurden die Kennungen CVE-2026-8863 und CVE-2026-10797 vergeben. Die alten Shims stammten aus verschiedenen Werkzeugen und Paketen und vergrößerten die Angriffsfläche über die jeweils vertrauenswürdigen Bootloader der zweiten Stufe.

ESET zufolge lassen sich die anfälligen Shims dazu ausnutzen, „UEFI Secure Boot auf jedem UEFI-basierten Rechner zu umgehen, der dem Microsoft-Drittanbieterzertifikat ‚Microsoft Corporation UEFI CA 2011‘ vertraut, unabhängig vom installierten Betriebssystem“. Angreifer könnten dabei nicht nur bereits vorhandene anfällige Shims missbrauchen, sondern auch eigene verwundbare Shims auf Systeme bringen, auf denen dieses Microsoft-Zertifikat eingetragen ist.

Besonders kritisch ist nach Einschätzung von ESET, dass die von den Shims als vertrauenswürdig akzeptierten Anwendungen teils sehr alt sind. „Die Signatur- und Kompilierungszeitstempel der Anwendungen, denen die von uns gemeldeten Shims vertrauen, reichen von 2013 bis 2025 – genug, um zu bestätigen, dass ein erheblicher Teil dieser Binärdateien alt war und wahrscheinlich von zahlreichen öffentlich bekannten Schwachstellen betroffen ist, etwa BootHole im Fall von GRUB2“, erklärt das Unternehmen.

Weil diese alten und anfälligen Shims weiterhin Vertrauen innerhalb der Secure-Boot-Kette genossen, konnten Angreifer laut ESET während des Startvorgangs nicht vertrauenswürdigen Code ausführen und Bootkits einschleusen, obwohl Secure Boot aktiviert war.

ESET meldete die Ergebnisse im Februar 2026 an CERT/CC. Im Juni widerrief Microsoft sämtliche anfälligen Anwendungen und nahm sie in die UEFI-DBX auf, also in die Datenbank verbotener Signaturen. CERT/CC weist jedoch darauf hin, dass Administratoren zunächst die Signaturdatenbank aktualisieren sollten, bevor sie die DBX-Widerrufe einspielen.

CERT/CC formuliert die empfohlene Reihenfolge so: Zuerst sollten vertrauenswürdige Boot-Anwendungen und Zertifikate aktualisiert werden, anschließend die Sperrliste ausgerollt werden. Andernfalls könnten Systeme neu aktualisierte Boot-Komponenten zurückweisen. Besonders Unternehmen, Virtualisierungsanbieter und Cloud-Betreiber mit großen Umgebungen sollten Validierung und Verteilung dieser Aktualisierungen priorisieren, damit beim Start physischer oder virtueller Maschinen keine anfälligen oder unsignierten Binärdateien ausgeführt werden.

Seit 2017 werden Shims nach einem Prüfverfahren signiert und dokumentiert. Für vor diesem Zeitpunkt freigegebene Exemplare gibt es laut dem Bericht jedoch keine Dokumentation. Deshalb könnten noch weitere alte, weiterhin vertrauenswürdige Shims existieren, die Systeme angreifbar machen.