Det underminerer Secure Boots grundidé: at computeren skal starte fra en kontrolleret og pålidelig kodebase. Samtidig viser sårbarheden, hvor vanskeligt det er at holde styr på alle de tredjepartskomponenter, som får lov til at indgå i opstartskæden.

Hvad er shim, og hvorfor er gamle versioner problemet?

Shim er et lille open source-program, der fungerer som mellemled mellem UEFI-firmwaren og en egentlig bootloader som GRUB2, der blandt andet bruges på Linux-systemer. Microsoft har tidligere signeret shim-versioner, så Linux-distributioner og andre tredjepartsoperativsystemer kunne fungere med Secure Boot .

De primært berørte versioner er shim 0.9 og ældre. De håndterer ikke mekanismen Secure Boot Advanced Targeting (SBAT) korrekt . SBAT gør det muligt at blokere bestemte, sårbare generationer af en bootloader uden at tilbagekalde hele leverandørens signeringscertifikat .

Når en gammel shim ikke håndhæver SBAT-reglerne, kan den fortsat starte, selv efter at sårbarhederne er blevet kendt, og nyere versioner er udgivet .

Leverandørernes rolle i forsyningskæden

Problemet er ikke kun selve open source-projektet. Flere hardware- og softwareleverandører har taget shim-koden, tilpasset den til egne produkter og derefter ladet de ældre versioner blive liggende i systemernes EFI System Partition – den særlige partition, hvor UEFI's startfiler ligger.

Positive Technologies har blandt andet peget på følgende berørte produkter og versioner :

• Spyrus WTGCreator version 4.2
• Baramundi Management Suite før version 2024R1
• WhiteCanyon WipeDrive version 8.0.0 til og med 8.1.3
• Finlands studentereksamenssystem Abitti 1 version 1.0.0
• NTC IT Rosa version R9 og R10
• PC-Doctor Service Center version 15 og 16

En Windows-opdatering alene fjerner derfor ikke nødvendigvis bootloaderen. Den kan blive liggende på disken, selv efter at operativsystemet er fuldt opdateret .

Sådan kan angrebet foregå

CVE-2026-8863 er ikke et fjernangreb uden login. Angriberen skal først have administratorrettigheder eller på anden måde kunne ændre computerens opstartsproces .

Teknikken minder om Bring Your Own Vulnerable Driver (BYOVD). Forskellen er, at angriberen ikke nødvendigvis indsætter en sårbar kernedriver, men i stedet placerer en legitim, men sårbar, Microsoft-signeret shim-bootloader i opstartskæden.

Ved næste opstart kontrollerer UEFI bootloaderens digitale signatur. Den ser gyldig ud, fordi den er signeret med det betroede certifikat Microsoft Corporation UEFI CA 2011, og firmwaren kører derfor bootloaderen . Den gamle shim kan derefter bruges til at omdirigere opstartsprocessen og indlæse en skadelig payload, før Windows, Linux-kernen eller sikkerhedssoftware er startet.

Resultatet er vilkårlig kodekørsel før operativsystemet, også kaldet pre-OS code execution .

Hvorfor kode før operativsystemet er så alvorligt

Angrebet passer til MITRE ATT&CK-teknikken T1542.003 – Pre-OS Boot: Bootkit . Et bootkit arbejder under operativsystemets niveau og kan give en angriber vedvarende adgang, som overlever en geninstallation af operativsystemet og kan være svær for traditionel antivirussoftware at opdage .

En vellykket udnyttelse kan blandt andet bruges til at:

• deaktivere eller omgå BitLocker,
• indsætte skadelig kode i operativsystemets kerne,
• etablere en bagdør, der aktiveres ved hver opstart.

Fordi koden kører så tidligt i opstartsforløbet, kan den påvirke de sikkerhedsmekanismer, der normalt skulle opdage eller begrænse angrebet. Oprydning efter et bootkit kan derfor være betydeligt vanskeligere end ved almindelig malware og kan kræve omfattende genoprettelse af platformens firmware og opstartsmiljø .

Rapid7 vurderer CVE-2026-8863 til 7,8 på CVSS v3.1-skalaen. Udnyttelse er klassificeret som "Less Likely", men påvirkningen af fortrolighed, integritet og tilgængelighed er vurderet som høj .

En del af et større problem med UEFI-tillid

CVE-2026-8863 står ikke alene. Den minder om BootHole-sårbarheden i GRUB2 fra 2020, CVE-2020-10713, som også kunne bruges til at omgå Secure Boot og førte til en omfattende opdatering af DBX-databasen . Den minder også om BlackLotus, et bootkit, der udnyttede en fejl i en ældre Windows-bootloader til at opnå vedvarende adgang før operativsystemet .

Situationen bliver yderligere kompliceret af, at certifikatet Microsoft Corporation UEFI CA 2011 – som har signeret de sårbare shim-bootloadere og mange andre tredjeparts-bootkomponenter – efter planen udløber den 27. juni 2026 . Microsoft har derfor arbejdet på at flytte økosystemet over på certifikater fra 2023, men overgangen er omfattende og kan stadig være i gang i mange organisationer .

Rettelsen: Opdater UEFI's DBX-database

CVE-2026-8863 løses ikke nødvendigvis med en almindelig Windows Update. Den centrale afhjælpning er en opdatering af UEFI's Forbidden Signature Database (DBX). Opdateringen tilføjer kryptografiske hashværdier for de sårbare shim-bootloadere til firmwarets liste over tilbagekaldte komponenter .

Når opdateringen er installeret, vil UEFI afvise bootloaderne, selv om deres digitale signaturer stadig er gyldige .

Vigtige forholdsregler for virksomheder

1. Start med en pilotgruppe. Test DBX-opdateringen på ikke-kritiske systemer, før den rulles bredt ud. Kontrollér især, at ingen nødvendige værktøjer stadig er afhængige af en berørt bootloader .

2. Kortlæg tredjeparts-bootloadere. Scan EFI System Partitioner for de berørte filer, og sammenhold resultaterne med produktlisten fra Positive Technologies. Vær særlig opmærksom på værktøjer til disk­sletning, systemadministration, gendannelse og hardwarediagnostik .

3. Kontrollér Linux- og dual-boot-maskiner. Computere med både Windows og Linux kan miste muligheden for at starte Linux, hvis distributionen stadig bruger en gammel shim. Opdatér alle distributioner til en understøttet, ikke-sårbar bootloader, før tilbagekaldelsen håndhæves .

4. Kontakt leverandørerne. Bed leverandører som WhiteCanyon og Baramundi om opdaterede, Secure Boot-kompatible versioner, før de gamle bootloadere blokeres .

5. Sørg for adgang til BitLocker-genoprettelsesnøgler. Ændringer i Secure Boot-konfigurationen kan udløse en BitLocker-genoprettelsesprompt. Kontrollér derfor på forhånd, at nøglerne er sikkerhedskopieret og tilgængelige for helpdesken.

6. Brug en trinvis udrulning. Start med it-afdelingen, fortsæt med en pilotgruppe, og udvid derefter til resten af organisationen. Overvåg hvert trin for problemer med opstart og platformens integritet.

CVE-2026-8863 er en påmindelse om, at Secure Boot kun er så stærk som den kode, den vælger at stole på. For virksomheder betyder det, at kontrol af opstartsmiljøet, leverandørernes komponenter og DBX-tilbagekaldelser skal være en løbende del af sikkerhedsarbejdet – ikke en engangsopgave.

Det underminerer Secure Boots grundidé: at computeren skal starte fra en kontrolleret og pålidelig kodebase. Samtidig viser sårbarheden, hvor vanskeligt det er at holde styr på alle de tredjepartskomponenter, som får lov til at indgå i opstartskæden.

Hvad er shim, og hvorfor er gamle versioner problemet?

Shim er et lille open source-program, der fungerer som mellemled mellem UEFI-firmwaren og en egentlig bootloader som GRUB2, der blandt andet bruges på Linux-systemer. Microsoft har tidligere signeret shim-versioner, så Linux-distributioner og andre tredjepartsoperativsystemer kunne fungere med Secure Boot .

De primært berørte versioner er shim 0.9 og ældre. De håndterer ikke mekanismen Secure Boot Advanced Targeting (SBAT) korrekt . SBAT gør det muligt at blokere bestemte, sårbare generationer af en bootloader uden at tilbagekalde hele leverandørens signeringscertifikat .

Når en gammel shim ikke håndhæver SBAT-reglerne, kan den fortsat starte, selv efter at sårbarhederne er blevet kendt, og nyere versioner er udgivet .

Leverandørernes rolle i forsyningskæden

Problemet er ikke kun selve open source-projektet. Flere hardware- og softwareleverandører har taget shim-koden, tilpasset den til egne produkter og derefter ladet de ældre versioner blive liggende i systemernes EFI System Partition – den særlige partition, hvor UEFI's startfiler ligger.

Positive Technologies har blandt andet peget på følgende berørte produkter og versioner :

• Spyrus WTGCreator version 4.2
• Baramundi Management Suite før version 2024R1
• WhiteCanyon WipeDrive version 8.0.0 til og med 8.1.3
• Finlands studentereksamenssystem Abitti 1 version 1.0.0
• NTC IT Rosa version R9 og R10
• PC-Doctor Service Center version 15 og 16

En Windows-opdatering alene fjerner derfor ikke nødvendigvis bootloaderen. Den kan blive liggende på disken, selv efter at operativsystemet er fuldt opdateret .

Sådan kan angrebet foregå

CVE-2026-8863 er ikke et fjernangreb uden login. Angriberen skal først have administratorrettigheder eller på anden måde kunne ændre computerens opstartsproces .

Teknikken minder om Bring Your Own Vulnerable Driver (BYOVD). Forskellen er, at angriberen ikke nødvendigvis indsætter en sårbar kernedriver, men i stedet placerer en legitim, men sårbar, Microsoft-signeret shim-bootloader i opstartskæden.

Ved næste opstart kontrollerer UEFI bootloaderens digitale signatur. Den ser gyldig ud, fordi den er signeret med det betroede certifikat Microsoft Corporation UEFI CA 2011, og firmwaren kører derfor bootloaderen . Den gamle shim kan derefter bruges til at omdirigere opstartsprocessen og indlæse en skadelig payload, før Windows, Linux-kernen eller sikkerhedssoftware er startet.

Resultatet er vilkårlig kodekørsel før operativsystemet, også kaldet pre-OS code execution .

Hvorfor kode før operativsystemet er så alvorligt

Angrebet passer til MITRE ATT&CK-teknikken T1542.003 – Pre-OS Boot: Bootkit . Et bootkit arbejder under operativsystemets niveau og kan give en angriber vedvarende adgang, som overlever en geninstallation af operativsystemet og kan være svær for traditionel antivirussoftware at opdage .

En vellykket udnyttelse kan blandt andet bruges til at:

• deaktivere eller omgå BitLocker,
• indsætte skadelig kode i operativsystemets kerne,
• etablere en bagdør, der aktiveres ved hver opstart.

Fordi koden kører så tidligt i opstartsforløbet, kan den påvirke de sikkerhedsmekanismer, der normalt skulle opdage eller begrænse angrebet. Oprydning efter et bootkit kan derfor være betydeligt vanskeligere end ved almindelig malware og kan kræve omfattende genoprettelse af platformens firmware og opstartsmiljø .

Rapid7 vurderer CVE-2026-8863 til 7,8 på CVSS v3.1-skalaen. Udnyttelse er klassificeret som "Less Likely", men påvirkningen af fortrolighed, integritet og tilgængelighed er vurderet som høj .

En del af et større problem med UEFI-tillid

CVE-2026-8863 står ikke alene. Den minder om BootHole-sårbarheden i GRUB2 fra 2020, CVE-2020-10713, som også kunne bruges til at omgå Secure Boot og førte til en omfattende opdatering af DBX-databasen . Den minder også om BlackLotus, et bootkit, der udnyttede en fejl i en ældre Windows-bootloader til at opnå vedvarende adgang før operativsystemet .

Situationen bliver yderligere kompliceret af, at certifikatet Microsoft Corporation UEFI CA 2011 – som har signeret de sårbare shim-bootloadere og mange andre tredjeparts-bootkomponenter – efter planen udløber den 27. juni 2026 . Microsoft har derfor arbejdet på at flytte økosystemet over på certifikater fra 2023, men overgangen er omfattende og kan stadig være i gang i mange organisationer .

Rettelsen: Opdater UEFI's DBX-database

CVE-2026-8863 løses ikke nødvendigvis med en almindelig Windows Update. Den centrale afhjælpning er en opdatering af UEFI's Forbidden Signature Database (DBX). Opdateringen tilføjer kryptografiske hashværdier for de sårbare shim-bootloadere til firmwarets liste over tilbagekaldte komponenter .

Når opdateringen er installeret, vil UEFI afvise bootloaderne, selv om deres digitale signaturer stadig er gyldige .

Vigtige forholdsregler for virksomheder

1. Start med en pilotgruppe. Test DBX-opdateringen på ikke-kritiske systemer, før den rulles bredt ud. Kontrollér især, at ingen nødvendige værktøjer stadig er afhængige af en berørt bootloader .

2. Kortlæg tredjeparts-bootloadere. Scan EFI System Partitioner for de berørte filer, og sammenhold resultaterne med produktlisten fra Positive Technologies. Vær særlig opmærksom på værktøjer til disk­sletning, systemadministration, gendannelse og hardwarediagnostik .

3. Kontrollér Linux- og dual-boot-maskiner. Computere med både Windows og Linux kan miste muligheden for at starte Linux, hvis distributionen stadig bruger en gammel shim. Opdatér alle distributioner til en understøttet, ikke-sårbar bootloader, før tilbagekaldelsen håndhæves .

4. Kontakt leverandørerne. Bed leverandører som WhiteCanyon og Baramundi om opdaterede, Secure Boot-kompatible versioner, før de gamle bootloadere blokeres .

5. Sørg for adgang til BitLocker-genoprettelsesnøgler. Ændringer i Secure Boot-konfigurationen kan udløse en BitLocker-genoprettelsesprompt. Kontrollér derfor på forhånd, at nøglerne er sikkerhedskopieret og tilgængelige for helpdesken.

6. Brug en trinvis udrulning. Start med it-afdelingen, fortsæt med en pilotgruppe, og udvid derefter til resten af organisationen. Overvåg hvert trin for problemer med opstart og platformens integritet.

CVE-2026-8863 er en påmindelse om, at Secure Boot kun er så stærk som den kode, den vælger at stole på. For virksomheder betyder det, at kontrol af opstartsmiljøet, leverandørernes komponenter og DBX-tilbagekaldelser skal være en løbende del af sikkerhedsarbejdet – ikke en engangsopgave.