Tällöin Secure Bootin keskeinen lupaus – luotettavan käynnistysketjun varmistaminen – ei enää pidä.

Mikä shimissä on vialla?

Shim on pieni avoimen lähdekoodin käynnistyslataaja, joka toimii UEFI-laiteohjelmiston ja esimerkiksi Linux-järjestelmien GRUB2-käynnistyslataajan välissä. Microsoft on allekirjoittanut shim-versioita, jotta Linux-jakelut ja muut kolmannen osapuolen käyttöjärjestelmät voivat toimia Secure Bootin kanssa .

Ensisijaisesti haavoittuvia ovat shim 0.9 ja sitä vanhemmat versiot. Niissä Secure Boot Advanced Targeting (SBAT) -mekanismin valvonta ja tarkistus eivät toimi asianmukaisesti .

SBAT on peruutusmekanismi, jolla voidaan estää tiettyjä haavoittuvia käynnistyslataajien sukupolvia ilman, että koko ohjelmistotoimittajan allekirjoitusvarmenne täytyy peruuttaa. Tarkistuksessa komponentti katsotaan peruutetuksi, jos se vastaa peruutusmerkintää ja sen versio on määriteltyä rajaa vanhempi .

Vanhat shim-versiot eivät kuitenkaan noudattaneet SBAT-rajoituksia. Siksi ne saattoivat pysyä käynnistyskelpoisina vielä sen jälkeen, kun niiden haavoittuvuudet oli tunnistettu ja turvallisemmat versiot julkaistu .

Toimitusketjun ongelma: allekirjoitettu ei tarkoita ajantasaista

Haavoittuvuus on ennen kaikkea toimitusketjuongelma. Useat laite- ja ohjelmistotoimittajat olivat haarauttaneet avoimen lähdekoodin shimin omiin tuotteisiinsa, mutta eivät myöhemmin päivittäneet mukana tullutta käynnistyslataajaa.

Positive Technologies listasi muun muassa seuraavat vaikutuksen alaiset tuotteet :

• Spyrus WTGCreator 4.2
• Baramundi Management Suite ennen versiota 2024R1
• WhiteCanyon WipeDrive versiot 8.0.0–8.1.3
• Suomen ylioppilastutkinnon Abitti 1 versio 1.0.0
• NTC IT Rosa versiot R9 ja R10
• PC-Doctor Service Center versiot 15 ja 16

Tällaiset työkalut voivat asentaa vanhan, Microsoftin allekirjoittaman shim-tiedoston EFI-järjestelmäosioon. Tämän vuoksi käyttöjärjestelmän päivittäminen ei välttämättä poista ongelmaa: haavoittuva käynnistyskomponentti voi jäädä levylle ja käynnistysketjuun .

Miten hyökkäys toimii?

CVE-2026-8863 ei ole etänä ilman kirjautumista hyödynnettävä haavoittuvuus. Hyökkääjällä täytyy ensin olla järjestelmänvalvojan oikeudet tai mahdollisuus muuttaa kohdelaitteen käynnistysprosessia .

Hyökkäystapa muistuttaa niin sanottua BYOVD-menetelmää (Bring Your Own Vulnerable Driver), jossa hyökkääjä tuo järjestelmään aidon mutta haavoittuvan komponentin. Tässä tapauksessa kyse ei ole käyttöjärjestelmän ytimessä toimivasta ajurista vaan haavoittuvasta käynnistyslataajasta.

Kun laite käynnistyy Secure Boot käytössä, UEFI tarkistaa shim-tiedoston allekirjoituksen. Allekirjoitus näyttää kelvolliselta, koska sen on tehnyt luotettu Microsoft Corporation UEFI CA 2011 -varmenne. UEFI suorittaa tiedoston, minkä jälkeen hyökkääjä voi ohjata käynnistystä ja ladata haitallista koodia ennen Windowsia tai tietoturvaohjelmistoja .

Tuloksena on mielivaltaisen koodin suoritus ennen käyttöjärjestelmää eli pre-OS code execution .

Miksi ennen käyttöjärjestelmää suoritettava koodi on vaarallista?

Hyökkäys liittyy MITRE ATT&CK -viitekehyksen tekniikkaan T1542.003 – Pre-OS Boot: Bootkit . Bootkit toimii käyttöjärjestelmän alapuolella ja voi tarjota huomaamattoman pysyvyyden, joka säilyy jopa käyttöjärjestelmän uudelleenasennuksen jälkeen .

Onnistunut hyödyntäminen voisi mahdollistaa esimerkiksi:

• BitLocker-suojauksen poistamisen käytöstä
• haitallisen koodin syöttämisen käyttöjärjestelmän ytimeen
• pysyvän takaoven asentamisen, joka aktivoituu jokaisella käynnistyskerralla

Bootkit-tartunnan täydellinen poistaminen on vaikeaa. Joissakin tapauksissa tarvitaan koko laitteen laiteohjelmiston uudelleenflashaus. Siksi haavoittuvuus on yritysten tietoturvan kannalta merkittävä, vaikka sen hyödyntäminen edellyttää paikallista pääsyä tai valmiiksi hankittuja oikeuksia.

Rapid7 arvioi haavoittuvuuden CVSS v3.1 -peruspistemääräksi 7,8 ja katsoi hyväksikäytön olevan ”Less Likely” eli epätodennäköisempi. Vaikutus luottamuksellisuuteen, eheyteen ja saatavuuteen on kuitenkin arvioitu korkeaksi .

Secure Bootin luottamusketju on ollut toistuvasti koetuksella

CVE-2026-8863 jatkaa sarjaa hyökkäyksiä, joissa kohteena on käyttöjärjestelmää edeltävä ympäristö. Vuoden 2020 BootHole-haavoittuvuus (CVE-2020-10713) koski GRUB2:ta ja johti laajaan DBX-päivitykseen . Myös BlackLotus-bootkit hyödynsi Windowsin vanhan käynnistyslataajan haavoittuvuutta saavuttaakseen pysyvyyden ennen käyttöjärjestelmän käynnistymistä .

Tilannetta mutkistaa samaan aikaan tapahtuva varmenteiden vaihtuminen. Haavoittuvia shimejä ja lukuisia muita kolmannen osapuolen käynnistyskomponentteja allekirjoittanut Microsoft Corporation UEFI CA 2011 oli asetettu vanhenemaan 27. kesäkuuta 2026 . Microsoft on ohjannut ekosysteemiä siirtymään uusiin, vuoden 2023 varmenteisiin, mutta siirtymä on monille organisaatioille monivaiheinen .

Korjaus ei ole tavallinen Windows-päivitys

CVE-2026-8863:n keskeinen torjuntatoimi on UEFI Forbidden Signature Database (DBX) -päivitys. Se lisää haavoittuvien shim-käynnistyslataajien kryptografiset tiivisteet UEFI:n peruutuslistalle. Päivityksen jälkeen laiteohjelmisto kieltäytyy suorittamasta niitä, vaikka niiden alkuperäinen allekirjoitus olisi edelleen teknisesti voimassa .

Yritysten kannattaa edetä vaiheittain:

1. Testaa DBX-päivitys ensin pilottiryhmässä. Varmista, ettei vanhojen shim-versioiden estäminen tee kriittisistä laitteista käynnistyskelvottomia .
2. Kartoita kolmannen osapuolen käynnistyslataajat. Tarkista EFI-järjestelmäosiot ja etsi esimerkiksi levyjen tyhjennys-, hallinta-, palautus- ja diagnostiikkatyökalujen asentamia komponentteja. Vertaa löydöksiä vaikutuksen alaisten tuotteiden luetteloon .
3. Tarkista Linux- ja kaksoiskäynnistyslaitteet. Vanhoja shim-paketteja käyttävät Windows–Linux-koneet voivat menettää käynnistyskykynsä DBX-eston jälkeen. Päivitä Linux-jakelut ensin tuettuihin, haavoittumattomiin shim-versioihin .
4. Pyydä toimittajilta päivitetyt versiot. Ota yhteyttä vaikutuksen alaisten tuotteiden valmistajiin ja varmista, että työkalut sisältävät Secure Bootin kanssa yhteensopivan käynnistyslataajan .
5. Varmista BitLocker-palautusavaimet. Secure Bootin muutokset voivat laukaista BitLocker-palautusnäkymän. Palautusavainten on oltava varmuuskopioituina ja tukipalvelun saatavilla ennen laajaa käyttöönottoa.
6. Käytä päivitysrenkaita. Etene IT-henkilöstöstä pilottikäyttäjiin ja vasta sen jälkeen koko organisaatioon. Seuraa jokaisessa vaiheessa käynnistyksen eheyttä ja mahdollisia palautustarpeita.

CVE-2026-8863 muistuttaa, että Secure Bootin suojaus on vain niin vahva kuin sen luottama allekirjoitettujen kolmannen osapuolen komponenttien ketju. EFI-järjestelmäosioiden jatkuva inventointi, käynnistyslataajien päivittäminen ja DBX-peruutusten hallittu käyttöönotto ovat keskeinen osa laitealustan turvallisuutta.

Tällöin Secure Bootin keskeinen lupaus – luotettavan käynnistysketjun varmistaminen – ei enää pidä.

Mikä shimissä on vialla?

Shim on pieni avoimen lähdekoodin käynnistyslataaja, joka toimii UEFI-laiteohjelmiston ja esimerkiksi Linux-järjestelmien GRUB2-käynnistyslataajan välissä. Microsoft on allekirjoittanut shim-versioita, jotta Linux-jakelut ja muut kolmannen osapuolen käyttöjärjestelmät voivat toimia Secure Bootin kanssa .

Ensisijaisesti haavoittuvia ovat shim 0.9 ja sitä vanhemmat versiot. Niissä Secure Boot Advanced Targeting (SBAT) -mekanismin valvonta ja tarkistus eivät toimi asianmukaisesti .

SBAT on peruutusmekanismi, jolla voidaan estää tiettyjä haavoittuvia käynnistyslataajien sukupolvia ilman, että koko ohjelmistotoimittajan allekirjoitusvarmenne täytyy peruuttaa. Tarkistuksessa komponentti katsotaan peruutetuksi, jos se vastaa peruutusmerkintää ja sen versio on määriteltyä rajaa vanhempi .

Vanhat shim-versiot eivät kuitenkaan noudattaneet SBAT-rajoituksia. Siksi ne saattoivat pysyä käynnistyskelpoisina vielä sen jälkeen, kun niiden haavoittuvuudet oli tunnistettu ja turvallisemmat versiot julkaistu .

Toimitusketjun ongelma: allekirjoitettu ei tarkoita ajantasaista

Haavoittuvuus on ennen kaikkea toimitusketjuongelma. Useat laite- ja ohjelmistotoimittajat olivat haarauttaneet avoimen lähdekoodin shimin omiin tuotteisiinsa, mutta eivät myöhemmin päivittäneet mukana tullutta käynnistyslataajaa.

Positive Technologies listasi muun muassa seuraavat vaikutuksen alaiset tuotteet :

• Spyrus WTGCreator 4.2
• Baramundi Management Suite ennen versiota 2024R1
• WhiteCanyon WipeDrive versiot 8.0.0–8.1.3
• Suomen ylioppilastutkinnon Abitti 1 versio 1.0.0
• NTC IT Rosa versiot R9 ja R10
• PC-Doctor Service Center versiot 15 ja 16

Tällaiset työkalut voivat asentaa vanhan, Microsoftin allekirjoittaman shim-tiedoston EFI-järjestelmäosioon. Tämän vuoksi käyttöjärjestelmän päivittäminen ei välttämättä poista ongelmaa: haavoittuva käynnistyskomponentti voi jäädä levylle ja käynnistysketjuun .

Miten hyökkäys toimii?

CVE-2026-8863 ei ole etänä ilman kirjautumista hyödynnettävä haavoittuvuus. Hyökkääjällä täytyy ensin olla järjestelmänvalvojan oikeudet tai mahdollisuus muuttaa kohdelaitteen käynnistysprosessia .

Hyökkäystapa muistuttaa niin sanottua BYOVD-menetelmää (Bring Your Own Vulnerable Driver), jossa hyökkääjä tuo järjestelmään aidon mutta haavoittuvan komponentin. Tässä tapauksessa kyse ei ole käyttöjärjestelmän ytimessä toimivasta ajurista vaan haavoittuvasta käynnistyslataajasta.

Kun laite käynnistyy Secure Boot käytössä, UEFI tarkistaa shim-tiedoston allekirjoituksen. Allekirjoitus näyttää kelvolliselta, koska sen on tehnyt luotettu Microsoft Corporation UEFI CA 2011 -varmenne. UEFI suorittaa tiedoston, minkä jälkeen hyökkääjä voi ohjata käynnistystä ja ladata haitallista koodia ennen Windowsia tai tietoturvaohjelmistoja .

Tuloksena on mielivaltaisen koodin suoritus ennen käyttöjärjestelmää eli pre-OS code execution .

Miksi ennen käyttöjärjestelmää suoritettava koodi on vaarallista?

Hyökkäys liittyy MITRE ATT&CK -viitekehyksen tekniikkaan T1542.003 – Pre-OS Boot: Bootkit . Bootkit toimii käyttöjärjestelmän alapuolella ja voi tarjota huomaamattoman pysyvyyden, joka säilyy jopa käyttöjärjestelmän uudelleenasennuksen jälkeen .

Onnistunut hyödyntäminen voisi mahdollistaa esimerkiksi:

• BitLocker-suojauksen poistamisen käytöstä
• haitallisen koodin syöttämisen käyttöjärjestelmän ytimeen
• pysyvän takaoven asentamisen, joka aktivoituu jokaisella käynnistyskerralla

Bootkit-tartunnan täydellinen poistaminen on vaikeaa. Joissakin tapauksissa tarvitaan koko laitteen laiteohjelmiston uudelleenflashaus. Siksi haavoittuvuus on yritysten tietoturvan kannalta merkittävä, vaikka sen hyödyntäminen edellyttää paikallista pääsyä tai valmiiksi hankittuja oikeuksia.

Rapid7 arvioi haavoittuvuuden CVSS v3.1 -peruspistemääräksi 7,8 ja katsoi hyväksikäytön olevan ”Less Likely” eli epätodennäköisempi. Vaikutus luottamuksellisuuteen, eheyteen ja saatavuuteen on kuitenkin arvioitu korkeaksi .

Secure Bootin luottamusketju on ollut toistuvasti koetuksella

CVE-2026-8863 jatkaa sarjaa hyökkäyksiä, joissa kohteena on käyttöjärjestelmää edeltävä ympäristö. Vuoden 2020 BootHole-haavoittuvuus (CVE-2020-10713) koski GRUB2:ta ja johti laajaan DBX-päivitykseen . Myös BlackLotus-bootkit hyödynsi Windowsin vanhan käynnistyslataajan haavoittuvuutta saavuttaakseen pysyvyyden ennen käyttöjärjestelmän käynnistymistä .

Tilannetta mutkistaa samaan aikaan tapahtuva varmenteiden vaihtuminen. Haavoittuvia shimejä ja lukuisia muita kolmannen osapuolen käynnistyskomponentteja allekirjoittanut Microsoft Corporation UEFI CA 2011 oli asetettu vanhenemaan 27. kesäkuuta 2026 . Microsoft on ohjannut ekosysteemiä siirtymään uusiin, vuoden 2023 varmenteisiin, mutta siirtymä on monille organisaatioille monivaiheinen .

Korjaus ei ole tavallinen Windows-päivitys

CVE-2026-8863:n keskeinen torjuntatoimi on UEFI Forbidden Signature Database (DBX) -päivitys. Se lisää haavoittuvien shim-käynnistyslataajien kryptografiset tiivisteet UEFI:n peruutuslistalle. Päivityksen jälkeen laiteohjelmisto kieltäytyy suorittamasta niitä, vaikka niiden alkuperäinen allekirjoitus olisi edelleen teknisesti voimassa .

Yritysten kannattaa edetä vaiheittain:

1. Testaa DBX-päivitys ensin pilottiryhmässä. Varmista, ettei vanhojen shim-versioiden estäminen tee kriittisistä laitteista käynnistyskelvottomia .
2. Kartoita kolmannen osapuolen käynnistyslataajat. Tarkista EFI-järjestelmäosiot ja etsi esimerkiksi levyjen tyhjennys-, hallinta-, palautus- ja diagnostiikkatyökalujen asentamia komponentteja. Vertaa löydöksiä vaikutuksen alaisten tuotteiden luetteloon .
3. Tarkista Linux- ja kaksoiskäynnistyslaitteet. Vanhoja shim-paketteja käyttävät Windows–Linux-koneet voivat menettää käynnistyskykynsä DBX-eston jälkeen. Päivitä Linux-jakelut ensin tuettuihin, haavoittumattomiin shim-versioihin .
4. Pyydä toimittajilta päivitetyt versiot. Ota yhteyttä vaikutuksen alaisten tuotteiden valmistajiin ja varmista, että työkalut sisältävät Secure Bootin kanssa yhteensopivan käynnistyslataajan .
5. Varmista BitLocker-palautusavaimet. Secure Bootin muutokset voivat laukaista BitLocker-palautusnäkymän. Palautusavainten on oltava varmuuskopioituina ja tukipalvelun saatavilla ennen laajaa käyttöönottoa.
6. Käytä päivitysrenkaita. Etene IT-henkilöstöstä pilottikäyttäjiin ja vasta sen jälkeen koko organisaatioon. Seuraa jokaisessa vaiheessa käynnistyksen eheyttä ja mahdollisia palautustarpeita.

CVE-2026-8863 muistuttaa, että Secure Bootin suojaus on vain niin vahva kuin sen luottama allekirjoitettujen kolmannen osapuolen komponenttien ketju. EFI-järjestelmäosioiden jatkuva inventointi, käynnistyslataajien päivittäminen ja DBX-peruutusten hallittu käyttöönotto ovat keskeinen osa laitealustan turvallisuutta.