De viktigste berørte versjonene er shim 0.9 og eldre. Disse versjonene håndterte ikke Secure Boot Advanced Targeting (SBAT) godt nok . SBAT er en mekanisme for tilbakekalling som skal gjøre det mulig å blokkere bestemte sårbare generasjoner av en bootlaster uten å tilbakekalle hele leverandørens signeringssertifikat .

Når gamle shim-versjoner ikke respekterer SBAT, kan de fortsatt starte selv etter at svakhetene er kjent og nyere, sikrere versjoner er publisert. Problemet har blitt forsterket av leverandører som har laget egne varianter av shim, men ikke oppdatert dem senere .

Positive Technologies har blant annet identifisert følgende berørte produkter :

• Spyrus WTGCreator 4.2
• Baramundi Management Suite før 2024R1
• WhiteCanyon WipeDrive 8.0.0 til 8.1.3
• Det finske eksamenssystemet Abitti 1, versjon 1.0.0
• NTC IT Rosa, versjon R9 og R10
• PC-Doctor Service Center, versjon 15 og 16

Slike verktøy kan ha lagt sine egne bootlastere på EFI System Partition – en liten systempartisjon som brukes under oppstart. Det betyr at en sårbar bootlaster kan bli liggende igjen selv om hovedoperativsystemet er oppdatert .

Slik kan angrepet gjennomføres

Dette er ikke et fjernangrep som kan utføres uten autentisering. Angriperen må først ha administratorrettigheter eller på annen måte kunne endre datamaskinens oppstartsprosess .

Deretter kan metoden minne om Bring Your Own Vulnerable Driver (BYOVD). Forskjellen er at angriperen ikke legger inn en sårbar kjernedriver, men en legitim, Microsoft-signert shim-bootlaster i oppstartskjeden.

Ved oppstart kontrollerer UEFI-fastvaren den digitale signaturen. Siden bootlasteren er signert med det betrodde sertifikatet Microsoft Corporation UEFI CA 2011, blir den godkjent og kjørt . Den utdaterte bootlasteren kan deretter brukes til å omdirigere oppstarten og laste inn en skadelig nyttelast før Windows-kjernen og sikkerhetsprogramvaren er initialisert .

Dette gir angriperen mulighet til å kjøre vilkårlig kode i den såkalte pre-OS-fasen – altså før operativsystemet er lastet inn.

Hvorfor kode før operativsystemet er så alvorlig

Angrepsformen passer inn i MITRE ATT&CK-teknikken T1542.003 – Pre-OS Boot: Bootkit . Et bootkit opererer under operativsystemlaget og kan gi en svært vanskelig oppdagbar form for utholdenhet. Slike angrep kan i enkelte tilfeller overleve en reinstallasjon av operativsystemet og omgå tradisjonell antivirusbeskyttelse .

En vellykket utnyttelse av CVE-2026-8863 kan blant annet brukes til å:

• deaktivere eller undergrave BitLocker-beskyttelse,
• injisere skadelig kode i operativsystemkjernen,
• etablere en bakdør som aktiveres ved hver oppstart.

Opprydding etter et bootkit kan være krevende. I alvorlige tilfeller kan det være nødvendig å skrive fastvaren på nytt. Rapid7 vurderte sårbarheten med en CVSS v3.1-basisscore på 7,8 og kategoriserte utnyttelse som «mindre sannsynlig», men den potensielle påvirkningen på konfidensialitet, integritet og tilgjengelighet er vurdert som høy .

En del av en lengre Secure Boot-historie

CVE-2026-8863 står ikke alene. Den minner om «BootHole»-sårbarheten i GRUB2, CVE-2020-10713, som også kunne brukes til å omgå Secure Boot og førte til omfattende oppdateringer av DBX-listen . Den har også likhetstrekk med BlackLotus, et bootkit som utnyttet en svakhet i en eldre Windows-bootlaster for å oppnå utholdenhet før operativsystemet startet .

Situasjonen blir mer komplisert av at Microsoft Corporation UEFI CA 2011 etter planen skulle utløpe 27. juni 2026. Sertifikatet har signert sårbare shim-bootlastere og en rekke andre tredjepartskomponenter. Microsoft har derfor oppfordret økosystemet til å gå over til sertifikater fra 2023, en overgang som fortsatt var under arbeid hos mange virksomheter da CVE-2026-8863 ble offentliggjort .

DBX-oppdatering er den sentrale løsningen

Dette løses ikke nødvendigvis med en vanlig Windows Update alene. Det viktigste tiltaket er en oppdatering av UEFI Forbidden Signature Database (DBX). DBX er fastvarens liste over signaturer og hashverdier som ikke lenger skal tillates under oppstart.

Oppdateringen legger hashverdiene til de sårbare shim-bootlasterne i tilbakekallingslisten. Når den er installert, skal UEFI-fastvaren nekte å kjøre bootlasterne selv om de fortsatt har en gyldig Microsoft-signatur .

Dette bør virksomheter gjøre før utrulling

En DBX-oppdatering må planlegges nøye. For aggressiv utrulling kan i verste fall gjøre systemer som fortsatt er avhengige av en gammel bootlaster, ustartbare.

1. Start med en pilot. Test oppdateringen på en ikke-produksjonsgruppe før den distribueres bredt. Kontroller særlig maskiner som kan være avhengige av tredjeparts bootlastere .

2. Kartlegg EFI System Partition. Bruk inventar- og sikkerhetsverktøy til å lete etter de berørte bootlasterne. Sammenlign funnene med produktlisten fra Positive Technologies, inkludert verktøy for disk-sletting, systemadministrasjon og maskinvarediagnostikk .

3. Kontroller Linux- og dual-boot-maskiner. Datamaskiner med både Windows og Linux, særlig eldre Linux-installasjoner, kan få problemer dersom de bruker en gammel shim. Sørg for at distribusjonene er oppdatert til en ikke-sårbar bootlaster før tilbakekallingen håndheves .

4. Ta kontakt med leverandørene. Be leverandører som WhiteCanyon og Baramundi om oppdaterte, Secure Boot-kompatible versjoner før de gamle bootlasterne blokkeres .

5. Forbered BitLocker-gjenoppretting. Endringer i Secure Boot-konfigurasjonen kan utløse spørsmål etter BitLocker-gjenopprettingsnøkkelen. Kontroller at nøklene er sikkerhetskopiert og tilgjengelige for brukerstøtten.

6. Bruk trinnvis utrulling. Rull først ut til IT-avdelingen, deretter til en pilotgruppe og til slutt til resten av organisasjonen. Overvåk oppstartsfeil og endringer i systemenes oppstartsstatus mellom hvert trinn.

CVE-2026-8863 illustrerer et grunnleggende problem med Secure Boot: Beskyttelsen avhenger ikke bare av Microsofts egne komponenter, men også av alle tredjepartskomponentene som får plass i tillitskjeden. Derfor bør kontroll av pre-OS-miljøet, leverandørenes bootlastere og DBX-tilstanden være en løpende del av virksomhetens sikkerhetsarbeid.

De viktigste berørte versjonene er shim 0.9 og eldre. Disse versjonene håndterte ikke Secure Boot Advanced Targeting (SBAT) godt nok . SBAT er en mekanisme for tilbakekalling som skal gjøre det mulig å blokkere bestemte sårbare generasjoner av en bootlaster uten å tilbakekalle hele leverandørens signeringssertifikat .

Når gamle shim-versjoner ikke respekterer SBAT, kan de fortsatt starte selv etter at svakhetene er kjent og nyere, sikrere versjoner er publisert. Problemet har blitt forsterket av leverandører som har laget egne varianter av shim, men ikke oppdatert dem senere .

Positive Technologies har blant annet identifisert følgende berørte produkter :

• Spyrus WTGCreator 4.2
• Baramundi Management Suite før 2024R1
• WhiteCanyon WipeDrive 8.0.0 til 8.1.3
• Det finske eksamenssystemet Abitti 1, versjon 1.0.0
• NTC IT Rosa, versjon R9 og R10
• PC-Doctor Service Center, versjon 15 og 16

Slike verktøy kan ha lagt sine egne bootlastere på EFI System Partition – en liten systempartisjon som brukes under oppstart. Det betyr at en sårbar bootlaster kan bli liggende igjen selv om hovedoperativsystemet er oppdatert .

Slik kan angrepet gjennomføres

Dette er ikke et fjernangrep som kan utføres uten autentisering. Angriperen må først ha administratorrettigheter eller på annen måte kunne endre datamaskinens oppstartsprosess .

Deretter kan metoden minne om Bring Your Own Vulnerable Driver (BYOVD). Forskjellen er at angriperen ikke legger inn en sårbar kjernedriver, men en legitim, Microsoft-signert shim-bootlaster i oppstartskjeden.

Ved oppstart kontrollerer UEFI-fastvaren den digitale signaturen. Siden bootlasteren er signert med det betrodde sertifikatet Microsoft Corporation UEFI CA 2011, blir den godkjent og kjørt . Den utdaterte bootlasteren kan deretter brukes til å omdirigere oppstarten og laste inn en skadelig nyttelast før Windows-kjernen og sikkerhetsprogramvaren er initialisert .

Dette gir angriperen mulighet til å kjøre vilkårlig kode i den såkalte pre-OS-fasen – altså før operativsystemet er lastet inn.

Hvorfor kode før operativsystemet er så alvorlig

Angrepsformen passer inn i MITRE ATT&CK-teknikken T1542.003 – Pre-OS Boot: Bootkit . Et bootkit opererer under operativsystemlaget og kan gi en svært vanskelig oppdagbar form for utholdenhet. Slike angrep kan i enkelte tilfeller overleve en reinstallasjon av operativsystemet og omgå tradisjonell antivirusbeskyttelse .

En vellykket utnyttelse av CVE-2026-8863 kan blant annet brukes til å:

• deaktivere eller undergrave BitLocker-beskyttelse,
• injisere skadelig kode i operativsystemkjernen,
• etablere en bakdør som aktiveres ved hver oppstart.

Opprydding etter et bootkit kan være krevende. I alvorlige tilfeller kan det være nødvendig å skrive fastvaren på nytt. Rapid7 vurderte sårbarheten med en CVSS v3.1-basisscore på 7,8 og kategoriserte utnyttelse som «mindre sannsynlig», men den potensielle påvirkningen på konfidensialitet, integritet og tilgjengelighet er vurdert som høy .

En del av en lengre Secure Boot-historie

CVE-2026-8863 står ikke alene. Den minner om «BootHole»-sårbarheten i GRUB2, CVE-2020-10713, som også kunne brukes til å omgå Secure Boot og førte til omfattende oppdateringer av DBX-listen . Den har også likhetstrekk med BlackLotus, et bootkit som utnyttet en svakhet i en eldre Windows-bootlaster for å oppnå utholdenhet før operativsystemet startet .

Situasjonen blir mer komplisert av at Microsoft Corporation UEFI CA 2011 etter planen skulle utløpe 27. juni 2026. Sertifikatet har signert sårbare shim-bootlastere og en rekke andre tredjepartskomponenter. Microsoft har derfor oppfordret økosystemet til å gå over til sertifikater fra 2023, en overgang som fortsatt var under arbeid hos mange virksomheter da CVE-2026-8863 ble offentliggjort .

DBX-oppdatering er den sentrale løsningen

Dette løses ikke nødvendigvis med en vanlig Windows Update alene. Det viktigste tiltaket er en oppdatering av UEFI Forbidden Signature Database (DBX). DBX er fastvarens liste over signaturer og hashverdier som ikke lenger skal tillates under oppstart.

Oppdateringen legger hashverdiene til de sårbare shim-bootlasterne i tilbakekallingslisten. Når den er installert, skal UEFI-fastvaren nekte å kjøre bootlasterne selv om de fortsatt har en gyldig Microsoft-signatur .

Dette bør virksomheter gjøre før utrulling

En DBX-oppdatering må planlegges nøye. For aggressiv utrulling kan i verste fall gjøre systemer som fortsatt er avhengige av en gammel bootlaster, ustartbare.

1. Start med en pilot. Test oppdateringen på en ikke-produksjonsgruppe før den distribueres bredt. Kontroller særlig maskiner som kan være avhengige av tredjeparts bootlastere .

2. Kartlegg EFI System Partition. Bruk inventar- og sikkerhetsverktøy til å lete etter de berørte bootlasterne. Sammenlign funnene med produktlisten fra Positive Technologies, inkludert verktøy for disk-sletting, systemadministrasjon og maskinvarediagnostikk .

3. Kontroller Linux- og dual-boot-maskiner. Datamaskiner med både Windows og Linux, særlig eldre Linux-installasjoner, kan få problemer dersom de bruker en gammel shim. Sørg for at distribusjonene er oppdatert til en ikke-sårbar bootlaster før tilbakekallingen håndheves .

4. Ta kontakt med leverandørene. Be leverandører som WhiteCanyon og Baramundi om oppdaterte, Secure Boot-kompatible versjoner før de gamle bootlasterne blokkeres .

5. Forbered BitLocker-gjenoppretting. Endringer i Secure Boot-konfigurasjonen kan utløse spørsmål etter BitLocker-gjenopprettingsnøkkelen. Kontroller at nøklene er sikkerhetskopiert og tilgjengelige for brukerstøtten.

6. Bruk trinnvis utrulling. Rull først ut til IT-avdelingen, deretter til en pilotgruppe og til slutt til resten av organisasjonen. Overvåk oppstartsfeil og endringer i systemenes oppstartsstatus mellom hvert trinn.

CVE-2026-8863 illustrerer et grunnleggende problem med Secure Boot: Beskyttelsen avhenger ikke bare av Microsofts egne komponenter, men også av alle tredjepartskomponentene som får plass i tillitskjeden. Derfor bør kontroll av pre-OS-miljøet, leverandørenes bootlastere og DBX-tilstanden være en løpende del av virksomhetens sikkerhetsarbeid.