En gammal komponent som fortfarande är betrodd

shim är en liten UEFI-startladdare med öppen källkod. Den fungerar som en brygga mellan datorns UEFI-firmware och en fullständig bootloader, exempelvis GRUB2 på Linux-system. Microsoft har signerat shim-versioner för att Linuxdistributioner och andra tredjepartssystem ska kunna fungera med Secure Boot .

De främst berörda versionerna är shim 0.9 och äldre. De saknar tillräcklig kontroll av Secure Boot Advanced Targeting (SBAT), en mekanism som kan spärra specifika generationer av sårbara bootloaders utan att hela leverantörens certifikat behöver återkallas .

När äldre shim-versioner inte respekterar SBAT kan de fortsätta att starta även efter att sårbarheter har upptäckts och säkrare versioner har släppts .

Positive Technologies pekade ut flera produkter som innehåller berörda komponenter, bland annat:

• Spyrus WTGCreator 4.2
• Baramundi Management Suite före 2024R1
• WhiteCanyon WipeDrive 8.0.0–8.1.3
• det finländska systemet för studentexamen, Abitti 1 version 1.0.0
• NTC IT Rosa R9 och R10
• PC-Doctor Service Center version 15 och 16

Bakgrunden är ett typiskt leveranskedjeproblem: leverantörer har förgrenat den öppna shim-koden för egna produkter, men inte alltid uppdaterat bootloadern när nya säkerhetsproblem blivit kända. Resultatet kan bli att en gammal, Microsoftsignerad fil ligger kvar i EFI System Partition även om själva operativsystemet är fullt uppdaterat .

Så kan attacken gå till

CVE-2026-8863 är inte en fjärrattack som kan genomföras utan föregående åtkomst. Angriparen behöver administratörsbehörighet eller möjlighet att ändra datorns startprocess .

Därefter kan angriparen använda en legitim men sårbar shim-bootloader – en metod som liknar Bring Your Own Vulnerable Driver (BYOVD). Skillnaden är att angreppet här riktas mot en bootloader i stället för en drivrutin i operativsystemets kärna.

Vid uppstart kontrollerar UEFI bootloaderns digitala signatur. Eftersom filen är signerad med det betrodda certifikatet Microsoft Corporation UEFI CA 2011 godkänns den av Secure Boot . Den sårbara bootloadern kan sedan styra om startförloppet och ladda en skadlig nyttolast innan Windows, Linux-kärnan eller säkerhetsprogrammen har hunnit starta .

Det innebär godtycklig kodkörning före operativsystemet, eller pre-OS-exekvering – ett läge där Secure Boot inte längre ger det skydd som funktionen är avsedd att ge.

Därför är kod före operativsystemet så allvarlig

Angreppssättet motsvarar MITRE ATT&CK-tekniken T1542.003 – Pre-OS Boot: Bootkit . Ett bootkit arbetar under operativsystemets nivå och kan ge en angripare uthållighet som överlever en ominstallation av Windows eller Linux och undgår många traditionella antiviruskontroller .

Ett lyckat angrepp kan bland annat användas för att:

• stänga av eller kringgå BitLocker,
• injicera kod i operativsystemets kärna,
• skapa en bakdörr som körs vid varje uppstart.

Att sanera ett bootkit kan vara svårt. I allvarliga fall kan en fullständig ominitiering av systemets firmware krävas. Det gör sårbarheten relevant för företagsmiljöer även om den kräver lokal åtkomst.

Rapid7 anger ett CVSS v3.1-värde på 7,8 och bedömer exploatering som ”mindre sannolik”. Den tekniska påverkan på konfidentialitet, integritet och tillgänglighet är däremot hög .

Senaste exemplet i en längre Secure Boot-historik

CVE-2026-8863 är en del av en längre serie angrepp mot UEFI:s startmiljö. Den påminner bland annat om BootHole i GRUB2, CVE-2020-10713, där en sårbarhet kunde användas för att kringgå Secure Boot och som krävde omfattande DBX-uppdateringar . Även bootkitet BlackLotus utnyttjade en sårbar Windows-bootloader för att skapa uthållighet före operativsystemets start .

Situationen sammanfaller dessutom med övergången från äldre Secure Boot-certifikat. Certifikatet Microsoft Corporation UEFI CA 2011, som bland annat används för Linux-shim och andra tredjepartskomponenter, skulle löpa ut den 27 juni 2026 . Microsoft har därför drivit på en migrering till certifikat från 2023, en förändring som kan vara tekniskt krävande i miljöer med äldre hårdvara, Linuxinstallationer och specialiserade startverktyg .

Åtgärden: uppdatera DBX – inte bara Windows

CVE-2026-8863 löses inte enbart med en vanlig Windows Update. Den centrala åtgärden är en uppdatering av UEFI Forbidden Signature Database, förkortad DBX. Databasen innehåller spärrade signaturer och hashvärden. När de sårbara shim-bootloaders läggs till där ska UEFI vägra köra dem, trots att deras digitala signaturer fortfarande är giltiga .

Företag bör behandla utrullningen som en förändring av startinfrastrukturen, inte som en rutinuppdatering.

Checklista för företagsmiljöer

1. Börja med en pilot. Testa DBX-uppdateringen på en avgränsad grupp datorer utan produktionskritiska beroenden. Kontrollera särskilt att inget system fortfarande behöver en berörd tredjeparts-bootloader .

2. Inventera EFI System Partition. Leta efter bootloaders som installerats av verktyg för exempelvis disk‑wiping, återställning, systemadministration och hårdvarudiagnostik. Jämför resultaten med den berörda produktlistan .

3. Kontrollera Linux och dual boot. Datorer med äldre Linuxdistributioner kan förlora möjligheten att starta efter att äldre shim-versioner spärrats. Säkerställ därför att installerade distributioner använder en aktuell, icke-sårbar shim innan DBX-reglerna tillämpas brett .

4. Kontakta leverantörerna. Be leverantörer som WhiteCanyon och Baramundi om uppdaterade, Secure Boot-kompatibla versioner innan de äldre bootloaders blockeras .

5. Säkerställ BitLocker-nycklar. Ändringar i Secure Boot-konfigurationen kan utlösa återställningsläge för BitLocker. Kontrollera att återställningsnycklarna är säkerhetskopierade och åtkomliga för servicedesk och supportpersonal.

6. Rulla ut stegvis. Använd företagets vanliga uppdateringsringar: först IT-avdelningen, därefter en pilotgrupp och slutligen resten av organisationen. Följ upp startfel, BitLocker-frågor och problem med alternativa operativsystem i varje fas.

CVE-2026-8863 visar varför Secure Boot inte enbart handlar om att kontrollera om en fil är signerad. Skyddet beror också på att hela ekosystemet av betrodda tredjepartskomponenter hålls uppdaterat och att gamla, sårbara versioner faktiskt spärras. För organisationer är inventering av pre-OS-miljön och kontrollerad DBX-utrullning därför centrala delar av det löpande säkerhetsarbetet.

En gammal komponent som fortfarande är betrodd

shim är en liten UEFI-startladdare med öppen källkod. Den fungerar som en brygga mellan datorns UEFI-firmware och en fullständig bootloader, exempelvis GRUB2 på Linux-system. Microsoft har signerat shim-versioner för att Linuxdistributioner och andra tredjepartssystem ska kunna fungera med Secure Boot .

De främst berörda versionerna är shim 0.9 och äldre. De saknar tillräcklig kontroll av Secure Boot Advanced Targeting (SBAT), en mekanism som kan spärra specifika generationer av sårbara bootloaders utan att hela leverantörens certifikat behöver återkallas .

När äldre shim-versioner inte respekterar SBAT kan de fortsätta att starta även efter att sårbarheter har upptäckts och säkrare versioner har släppts .

Positive Technologies pekade ut flera produkter som innehåller berörda komponenter, bland annat:

• Spyrus WTGCreator 4.2
• Baramundi Management Suite före 2024R1
• WhiteCanyon WipeDrive 8.0.0–8.1.3
• det finländska systemet för studentexamen, Abitti 1 version 1.0.0
• NTC IT Rosa R9 och R10
• PC-Doctor Service Center version 15 och 16

Bakgrunden är ett typiskt leveranskedjeproblem: leverantörer har förgrenat den öppna shim-koden för egna produkter, men inte alltid uppdaterat bootloadern när nya säkerhetsproblem blivit kända. Resultatet kan bli att en gammal, Microsoftsignerad fil ligger kvar i EFI System Partition även om själva operativsystemet är fullt uppdaterat .

Så kan attacken gå till

CVE-2026-8863 är inte en fjärrattack som kan genomföras utan föregående åtkomst. Angriparen behöver administratörsbehörighet eller möjlighet att ändra datorns startprocess .

Därefter kan angriparen använda en legitim men sårbar shim-bootloader – en metod som liknar Bring Your Own Vulnerable Driver (BYOVD). Skillnaden är att angreppet här riktas mot en bootloader i stället för en drivrutin i operativsystemets kärna.

Vid uppstart kontrollerar UEFI bootloaderns digitala signatur. Eftersom filen är signerad med det betrodda certifikatet Microsoft Corporation UEFI CA 2011 godkänns den av Secure Boot . Den sårbara bootloadern kan sedan styra om startförloppet och ladda en skadlig nyttolast innan Windows, Linux-kärnan eller säkerhetsprogrammen har hunnit starta .

Det innebär godtycklig kodkörning före operativsystemet, eller pre-OS-exekvering – ett läge där Secure Boot inte längre ger det skydd som funktionen är avsedd att ge.

Därför är kod före operativsystemet så allvarlig

Angreppssättet motsvarar MITRE ATT&CK-tekniken T1542.003 – Pre-OS Boot: Bootkit . Ett bootkit arbetar under operativsystemets nivå och kan ge en angripare uthållighet som överlever en ominstallation av Windows eller Linux och undgår många traditionella antiviruskontroller .

Ett lyckat angrepp kan bland annat användas för att:

• stänga av eller kringgå BitLocker,
• injicera kod i operativsystemets kärna,
• skapa en bakdörr som körs vid varje uppstart.

Att sanera ett bootkit kan vara svårt. I allvarliga fall kan en fullständig ominitiering av systemets firmware krävas. Det gör sårbarheten relevant för företagsmiljöer även om den kräver lokal åtkomst.

Rapid7 anger ett CVSS v3.1-värde på 7,8 och bedömer exploatering som ”mindre sannolik”. Den tekniska påverkan på konfidentialitet, integritet och tillgänglighet är däremot hög .

Senaste exemplet i en längre Secure Boot-historik

CVE-2026-8863 är en del av en längre serie angrepp mot UEFI:s startmiljö. Den påminner bland annat om BootHole i GRUB2, CVE-2020-10713, där en sårbarhet kunde användas för att kringgå Secure Boot och som krävde omfattande DBX-uppdateringar . Även bootkitet BlackLotus utnyttjade en sårbar Windows-bootloader för att skapa uthållighet före operativsystemets start .

Situationen sammanfaller dessutom med övergången från äldre Secure Boot-certifikat. Certifikatet Microsoft Corporation UEFI CA 2011, som bland annat används för Linux-shim och andra tredjepartskomponenter, skulle löpa ut den 27 juni 2026 . Microsoft har därför drivit på en migrering till certifikat från 2023, en förändring som kan vara tekniskt krävande i miljöer med äldre hårdvara, Linuxinstallationer och specialiserade startverktyg .

Åtgärden: uppdatera DBX – inte bara Windows

CVE-2026-8863 löses inte enbart med en vanlig Windows Update. Den centrala åtgärden är en uppdatering av UEFI Forbidden Signature Database, förkortad DBX. Databasen innehåller spärrade signaturer och hashvärden. När de sårbara shim-bootloaders läggs till där ska UEFI vägra köra dem, trots att deras digitala signaturer fortfarande är giltiga .

Företag bör behandla utrullningen som en förändring av startinfrastrukturen, inte som en rutinuppdatering.

Checklista för företagsmiljöer

1. Börja med en pilot. Testa DBX-uppdateringen på en avgränsad grupp datorer utan produktionskritiska beroenden. Kontrollera särskilt att inget system fortfarande behöver en berörd tredjeparts-bootloader .

2. Inventera EFI System Partition. Leta efter bootloaders som installerats av verktyg för exempelvis disk‑wiping, återställning, systemadministration och hårdvarudiagnostik. Jämför resultaten med den berörda produktlistan .

3. Kontrollera Linux och dual boot. Datorer med äldre Linuxdistributioner kan förlora möjligheten att starta efter att äldre shim-versioner spärrats. Säkerställ därför att installerade distributioner använder en aktuell, icke-sårbar shim innan DBX-reglerna tillämpas brett .

4. Kontakta leverantörerna. Be leverantörer som WhiteCanyon och Baramundi om uppdaterade, Secure Boot-kompatibla versioner innan de äldre bootloaders blockeras .

5. Säkerställ BitLocker-nycklar. Ändringar i Secure Boot-konfigurationen kan utlösa återställningsläge för BitLocker. Kontrollera att återställningsnycklarna är säkerhetskopierade och åtkomliga för servicedesk och supportpersonal.

6. Rulla ut stegvis. Använd företagets vanliga uppdateringsringar: först IT-avdelningen, därefter en pilotgrupp och slutligen resten av organisationen. Följ upp startfel, BitLocker-frågor och problem med alternativa operativsystem i varje fas.

CVE-2026-8863 visar varför Secure Boot inte enbart handlar om att kontrollera om en fil är signerad. Skyddet beror också på att hela ekosystemet av betrodda tredjepartskomponenter hålls uppdaterat och att gamla, sårbara versioner faktiskt spärras. För organisationer är inventering av pre-OS-miljön och kontrollerad DBX-utrullning därför centrala delar av det löpande säkerhetsarbetet.