BitLocker zero-day a láthatáron: mit jelent a „YellowKey” a Windows 11-felhasználóknak?

Mi történt?

2026 májusának közepén egy „Chaotic Eclipse" (más néven „Nightmare-Eclipse") álnéven publikáló, magát névtelenségbe burkoló biztonsági kutató bizonyítékkódot (proof-of-concept, PoC) tett közzé a GitHubon két, addig ismeretlen Windows-sebezhetőségről. Az egyik a YellowKey fedőnevet kapta, és a Microsoft egyik legfontosabb adatvédelmi pajzsát, a BitLocker meghajtótitkosítást támadja. A másik a GreenPlasma nevű jogosultságemelő hiba, amelyről lentebb külön is szót ejtünk.

A bejelentés azért keltett komoly visszhangot a szakmában, mert a kutató nem a szokásos, „felelős közzétételnek" nevezett úton járt — vagyis nem várta meg, amíg a Microsoft kiad egy javítást —, hanem a teljes nyilvánosság elé tárta a hibát és a működő PoC-t. A gyártónak így gyakorlatilag nem maradt ideje a háttérben javítani: a sebezhetőség a megjelenése pillanatában zero-day, azaz nulladik napi hiba lett, amelyre a megjelenésekor nem létezett hivatalos folt.

Fontos a kontextus: a Microsoft a megkeresésre azt közölte, hogy „tisztában van a feltételezett sebezhetőségekkel, és aktívan vizsgálja az állítások valódiságát és lehetséges érintettségét a platformjain és szolgáltatásain", valamint hogy „elkötelezett a bejelentett biztonsági problémák kivizsgálása és az érintett termékek frissítése mellett, hogy a lehető leghamarabb megvédje az ügyfeleket". Hivatalos javítás és CVE-azonosító a cikk írásakor azonban még nem létezik egyik hibához sem.

Mi az a BitLocker, és miért számít ez neked?

A BitLocker a Windows beépített, teljes lemeztitkosítási megoldása, amely a Pro, Enterprise és Education kiadásokban érhető el (a modern eszközökön pedig gyakran „eszköztitkosítás" néven a Home kiadásban is aktív). A célja egyetlen mondatban összefoglalható: ha a laptopodat ellopják, elveszíted, vagy egy szerviz nem megfelelő kezekbe kerül, akkor a rajta lévő adatokat — dokumentumok, jelszóadatbázis, céges fájlok, fényképek — egy illetéktelen ne tudja kiolvasni, még akkor sem, ha kiszereli a meghajtót és egy másik gépbe köti.

A titkosítás kulcsát a legtöbb modern gépen a TPM (Trusted Platform Module) nevű biztonsági lapka őrzi. A leggyakoribb, gyári alapbeállítás az úgynevezett „TPM-only" mód: a felhasználónak nem kell semmilyen PIN-kódot vagy jelszót megadnia indításkor, a TPM automatikusan feloldja a meghajtót, ha a gép a megszokott, ép állapotában indul. Ez kényelmes — és pont ez a kényelem az, amit a YellowKey kihasznál.

A BitLockernek több „védelmi mód" (protector) is létezik: a már említett TPM-only mellett a biztonságosabb TPM + PIN, a TPM + PIN + indítókulcs (USB), valamint a tisztán jelszavas vagy USB-kulcsos megoldás. Ezen felül minden BitLocker-kötethez tartozik egy 48 számjegyű helyreállítási kulcs (recovery key), amelyet a rendszer jellemzően a Microsoft-fiókodhoz, céges környezetben pedig az Entra ID-hoz (korábbi nevén Azure AD) vagy az Active Directoryhoz ment. Érdemes most ellenőrizned, hogy ez a kulcs valóban biztonságos helyen, elérhetően megvan-e — nem azért, mert a YellowKey igényli, hanem mert bármilyen titkosítással kapcsolatos vészhelyzetben ez a végső mentőöved.

Vagyis ez a hiba nem egy elvont, kutatólaborba illő érdekesség. Pontosan azt a forgatókönyvet támadja, amiért a BitLockert egyáltalán bekapcsoljuk: a fizikailag idegen kézbe került eszköz védelmét.

A YellowKey: így csúszik ki a kulcs a rendszerből

A támadás a Windows kevéssé ismert, de kritikus összetevőjét, a Windows Recovery Environment-et (WinRE) — a helyreállítási környezetet — célozza. Ez az a minirendszer, amely akkor indul el, ha a Windows nem tud rendesen betöltődni, vagy ha szándékosan belépsz a hibaelhárító menübe.

A kutató és a hibát egymástól függetlenül megerősítő szakemberek leírása szerint a sebezhetőség a Windows egy ritkán emlegetett képességét, a tranzakciós NTFS (Transactional NTFS, TxF) mechanizmust játssza ki. A lényeg közérthetően: a támadó által előkészített állományok egy külső adathordozón (vagy a rendszerlemez EFI-partícióján) képesek manipulálni a helyreállítási környezet egyik konfigurációs fájlját egy másik meghajtón. Will Dormann, az ismert sérülékenységkutató tömör megfogalmazásában a tranzakciós NTFS-bitek „egy USB-meghajtón képesek törölni egy MÁSIK meghajtón lévő winpeshl.ini fájlt".

Miért végzetes ez? Mert ha a WinRE indulásakor a saját, megszokott vezérlőfájlja megsérül vagy eltűnik, a helyreállítási környezet a várt grafikus hibaelhárító felület helyett egy parancssorba (cmd.exe) ejti a felhasználót. A csapda lényege a következő: ekkorra a TPM a megszokott, alapértelmezett „TPM-only" konfigurációban már automatikusan feloldotta a BitLockerrel védett kötetet, hiszen a gép a saját, ismert hardverén indult. Az így kapott parancssor tehát egy már visszafejtett, nyitott lemezhez ad korlátlan olvasási és írási hozzáférést — minden jelszó, helyreállítási kulcs vagy bejelentkezés nélkül.

A biztonsági szakma ezt a típusú fenyegetést „evil maid" (gonosz szobalány) támadásnak nevezi: a klasszikus példában egy szállodai szobalány — vagy bárki, aki rövid időre egyedül marad az őrizetlenül hagyott géppel — fér hozzá az eszközhöz. A YellowKey épp ezt a forgatókönyvet teszi triviálissá ott, ahol eddig a BitLocker komoly akadályt jelentett. Ráadásul, ha a támadó egyszer parancssorhoz jut a feloldott köteten, nemcsak kiolvashatja az adatokat, hanem módosíthatja is a rendszert — például tartós hátsó kaput vagy adatlopó kódot helyezhet el, amelyet a mit sem sejtő felhasználó a következő indításnál maga aktivál. Ez a „behatolás nyoma nélküli" jelleg teszi a fizikai támadásokat különösen alattomossá.

Hangsúlyozni kell, hogy ez a cikk szándékosan nem közöl lépésről lépésre követhető receptet a támadás végrehajtásához. A működési elv ismertetése a védekezést szolgálja: ha érted, miért és hogyan bukik el a védelem, akkor azt is érted, melyik óvintézkedésnek van értelme.

Kit érint, és kit nem?

A jelenleg rendelkezésre álló információk és a független megerősítések alapján a kép a következő:

• Érintett: a Windows 11 (a beszámolók szerint a friss build-eken is működik), valamint a Windows Server 2022 és Windows Server 2025.

• Nem érintett: a beszámolók szerint a Windows 10 ebben a formában nem sebezhető — a hibás összetevő a Windows 11 helyreállítási képfájljához kötődik.

• Fizikai hozzáférés kell: ez nem egy távoli, interneten át bevethető támadás. A támadónak a kezébe kell vennie a gépet (vagy legalább egy USB-portot el kell érnie, illetve a lemezhez hozzá kell férnie). Nincs „kattints a linkre, és lefagy a BitLockered" forgatókönyv.

• A gyári alapbeállítás a legsérülékenyebb: a PIN nélküli, „TPM-only" automatikus feloldás — ez a legtöbb otthoni és sok céges gép alapértelmezett állapota.

• Az ellopott, kiszerelt meghajtó önmagában nem elég: mivel a támadás az eredeti gép TPM-jének automatikus feloldására épül, egy másik gépbe áthelyezett, kiszerelt SSD-vel a jelenlegi PoC nem működik. A reális kockázat tehát a komplett, bekapcsolható eszköz (laptop, asztali gép) idegen kézbe kerülése.

A hibát több, egymástól független, neves szakember is reprodukálta — köztük Kevin Beaumont és Will Dormann —, akik megerősítették, hogy a módszer a friss Windows 11-kiadásokon is működik. Ez fontos: nem egyetlen, nehezen ellenőrizhető állításról van szó.

A „hátsó kapu" vád — mit állít a kutató, és mit tudunk biztosan?

A bejelentés egyik legvitatottabb eleme nem maga a technikai hiba, hanem a kutató értelmezése. Chaotic Eclipse felvetette, hogy a YellowKey akár szándékosan elhelyezett hátsó kapu (backdoor) is lehet a BitLockerben. Érvelése szerint a sérülékeny komponens kizárólag a helyreállítási (WinRE) képfájlban van jelen ebben a sebezhető formában, miközben máshol — azonos elnevezés alatt — nem viselkedik így.

Itt érdemes nagyon óvatosan fogalmazni, és élesen elválasztani a tényeket a feltételezésektől:

• Tény: a hiba létezik, működik, és független szakemberek reprodukálták.

• Feltételezés: hogy ez szándékos hátsó kapu volna. Erre jelenleg nincs bizonyíték; ez a kutató interpretációja. A biztonsági szakmában jól ismert jelenség, hogy összetett, sok évtizedes kódbázisok (mint a Windows helyreállítási rétege) bőven termelnek nem szándékos, de súlyos hibákat — különösen az olyan, ritkán bolygatott területeken, mint a tranzakciós NTFS.

Felelős olvasóként tehát azt érdemes fejben tartani: a kockázat valós, a „backdoor"-narratíva viszont egyelőre bizonyítatlan vélemény. A kettőt nem szabad összemosni — a védekezés szempontjából egyébként sem számít, szándékos volt-e a hiba vagy sem; a teendők ugyanazok.

GreenPlasma: a csendes társ a háttérben

A YellowKey mellett ugyanaz a kutató közzétette a GreenPlasma nevű hibát is, amely teljesen más természetű, de szintén komoly. Ez egy jogosultságemelő (privilege escalation) sebezhetőség, amely a Windows CTFMON (Collaborative Translation Framework) komponensét érinti. Lényege, hogy egy jogosulatlan, hétköznapi felhasználó olyan memóriaobjektumokat hozhat létre a rendszer (SYSTEM) által írható könyvtárakban, amelyekkel végső soron a legmagasabb, SYSTEM szintű jogokat szerezheti meg a gépen.

A kutató itt szándékosan hiányos PoC-t tett közzé: a teljes, SYSTEM-szintű parancssort eredményező lépéseket visszatartotta. A hibát a beszámolók szerint a Windows 11 és a Windows Server 2022/2025 érinti.

Joshua Roback (Swimlane) biztonsági szakértő szerint „minden, ami SYSTEM-szintű jogosultság felé vezető utat nyit, alapos vizsgálatot érdemel; teljes kihasználás esetén egy ilyen jogosultságemelés lehetővé teheti a támadónak, hogy kikapcsolja a védelmi mechanizmusokat, manipulálja a megbízható folyamatokat és kártevőt telepítsen". A két hiba együtt különösen aggasztó: a YellowKey a titkosítást, a GreenPlasma a rendszeren belüli jogosultsági korlátokat feszegeti.

A nagyobb kép: egy kutató, aki nyilvánosan szembement a Microsofttal

A YellowKey nem előzmény nélküli. Ugyanez a kutató 2026 áprilisában már nyilvánosságra hozott három, a Microsoft Defendert érintő hibát, amelyek a BlueHammer, RedSun és UnDefend fedőneveket kapták. Közülük a BlueHammer hivatalos azonosítót is kapott (CVE-2026-33825) és a Microsoft be is foltozta; a beszámolók szerint a RedSun és az UnDefend viszont a cikk írásáig javítatlan maradt, illetve csak „csendes", hivatalos közlemény nélküli javítást kapott.

Ami ezt különösen súlyossá teszi: a Huntress biztonsági cég kutatói szerint az áprilisi Defender-hibák egy részét 2026. április 10-től kezdődően valós támadásokban is bevetették, a nyilvánosan közzétett kód felhasználásával. Ez a kontextus magyarázza a kutató radikális, „teljes közzétételi" (full disclosure) hozzáállását: a beszámolók szerint elégedetlen volt azzal, ahogyan a Microsoft a korábbi bejelentéseit kezelte, ezért döntött a nyilvánosság mellett — vállalva annak vitatott következményeit is.

Érdemes hozzátenni: a BitLocker megkerülése önmagában nem új jelenség. Korábban már dokumentáltak hasonló célú támadásokat — például a rendszerbetöltő visszafejlesztésére épülő, külön azonosítót kapott (CVE-2025-48804) módszert is. A YellowKey azonban abban különbözik, hogy friss, javítatlan, és működő PoC-vel együtt, a nyilvánosság előtt jelent meg.

A Microsoft válasza és a júniusi Patch Tuesday

A Microsoft hivatalos álláspontja egyelőre visszafogott: vizsgálja az állításokat, és — saját megfogalmazása szerint — „támogatja a koordinált sérülékenység-közzétételt, amely széles körben elfogadott iparági gyakorlat". Ez burkolt kritika a kutató választott útjával szemben, ugyanakkor a cég nem cáfolta a hibák létezését.

A piaci pletykák szerint a kutató a 2026. júniusi Patch Tuesday (a Microsoft havi, minden hónap második keddjén esedékes javítócsomagja) kapcsán „nagy meglepetést" ígért — ami arra utalhat, hogy további részletek vagy újabb hibák kerülhetnek nyilvánosságra. Reálisan tehát az a forgatókönyv valószínű, hogy a hivatalos javítás legkorábban a júniusi (vagy egy soron kívüli, „out-of-band") csomagban érkezik. Addig a felhasználói és szervezeti óvintézkedéseken múlik a védelem.

Fontos hűvös fejjel értékelni a kockázatot. Ross Filipek, a Corsica Technologies biztonsági vezetője szerint „a nyilvános zero-day-közzétételek mindig megváltoztatják a kockázati egyenletet, mert lerövidítik a felfedezés és a tényleges kihasználás közötti időablakot". A YellowKey kapcsán a cikk írásakor nincs megerősített, valós (in-the-wild) támadásról szóló jelentés — szemben az áprilisi Defender-hibákkal —, de a nyilvános PoC megléte miatt a kockázat objektíve nőtt.

Mit tegyél most? — gyakorlati védekezési útmutató

A jó hír: mivel a támadáshoz fizikai hozzáférés kell, néhány célzott lépéssel jelentősen csökkentheted a kitettséget már a hivatalos javítás előtt is. Íme a teendők, fontossági sorrendben.

1. Kapcsolj be indítás előtti hitelesítést (BitLocker PIN)

A legfontosabb lépés: állíts be indítás előtti PIN-kódot (TPM + PIN). Ezzel a TPM nem oldja fel automatikusan a meghajtót pusztán a megszokott hardver láttán — kell hozzá egy, csak általad ismert kód. Megjegyzés: a kutató állítása szerint létezik a YellowKey egy PIN-t is megkerülő változata, ezt azonban nem hozta nyilvánosságra, és független megerősítése sincs. A PIN tehát nem garantált abszolút védelem, de jelentősen megemeli a lécet, és minden más fizikai-hozzáférésű támadás ellen is véd. Beállítása csoportházirendből (Group Policy) vagy a manage-bde eszközzel lehetséges.

2. Zárd le a BIOS/UEFI-t és a külső bootolást

• Állíts be UEFI/BIOS rendszergazdai jelszót.

• Tiltsd le a külső adathordozóról (USB, hálózat) történő indítást, vagy állítsd a belső lemezt kizárólagos, első helyre a bootsorrendben.

• Győződj meg róla, hogy a Secure Boot engedélyezve van.

3. Erősítsd a fizikai biztonságot

Mivel a támadás belépési pontja a fizikai hozzáférés, a klasszikus higiénia most kiemelten számít: ne hagyd a laptopot felügyelet nélkül nyilvános helyen, használj kábelzárat, zárd el az eszközöket, és ne hagyd a gépet alvó/bekapcsolt, felügyelet nélküli állapotban idegen környezetben. A nagyobb kockázatú eszközök: a sokat utazó munkatársak laptopjai, a recepción/közös térben álló gépek, a kioszkok és a céges eszközflották.

4. Szervezeteknek: csökkentsd a támadási felületet

• Vezesd be a TPM + PIN módot házirenddel, az egész flottára, ne csak ad hoc módon.

• Mérlegeld a WinRE szerepének felülvizsgálatát a felügyelt végpontokon (pl. központi helyreállítási folyamat mellett a helyi WinRE korlátozása) — ezt körültekintően, a helyreállítási képességek mérlegelésével tedd, mert a WinRE letiltása nehezítheti a legitim hibaelhárítást.

• Tartsd naprakészen az eszköznyilvántartást és a lopás-/elvesztés-bejelentési folyamatot; egy gyorsan jelentett eszközvesztésnél a fiókok és kulcsok rotálása kulcsfontosságú.

• Ahol indokolt, fontold meg a különösen érzékeny adatok fájlszintű, külön kulcsú titkosítását a teljeslemez-titkosítás mellett, hogy egyetlen megkerülés ne tegyen mindent olvashatóvá.

5. Figyeld a hivatalos javítást

Kövesd a Microsoft biztonsági közleményeit, és azonnal telepítsd a júniusi Patch Tuesday (vagy egy esetleges soron kívüli) csomagot, amint elérhető. Tartsd bekapcsolva az automatikus frissítést. Ha megjelenik egy hivatalos CVE-azonosító és javítás, ez a cikk frissül.

Gyakran ismételt kérdések

Elég, ha egyszerűen kikapcsolom a BitLockert?

Nem — sőt, ez a lehető legrosszabb lépés. A BitLocker kikapcsolásával a teljes lemezed titkosítatlanná válik, és onnantól bármilyen ellopott vagy elveszített eszköz adatait triviálisan ki lehet olvasni, semmilyen trükk nélkül. A YellowKey egy szűk, fizikai hozzáférést igénylő rést nyit; a titkosítás kikapcsolása viszont szélesre tárja a kaput. A helyes irány a titkosítás megerősítése (TPM + PIN), nem a kikapcsolása.

Veszélyben van a Microsoft-fiókomban tárolt helyreállítási kulcs?

A YellowKey nem a felhőben tárolt helyreállítási kulcs kiszivárogtatásáról szól, hanem arról, hogy a támadó a kulcs ismerete nélkül, a TPM automatikus feloldását kihasználva jut hozzá az adatokhoz az eredeti gépen. A helyreállítási kulcs biztonságos tárolása ettől függetlenül mindig fontos — ne oszd meg, és ne tárold magán a gépen.

Érint ez engem, ha Linuxot vagy macOS-t használok?

A YellowKey kifejezetten a Windows BitLocker/WinRE rétegét célozza, így a Linux (LUKS) és a macOS (FileVault) ebben a formában nem érintett. Ha azonban kettős rendszerindítású (dual-boot) géped van BitLockerrel titkosított Windows-partícióval, arra a Windows-oldali óvintézkedések vonatkoznak.

Honnan tudom, milyen módban fut a BitLockerem?

Rendszergazdai parancssorból a manage-bde -status paranccsal megnézheted a kötetek állapotát, a védelmi módot pedig a manage-bde -protectors -get C: listázza. Ha csak „TPM" szerepel PIN nélkül, akkor a leginkább érintett, alapértelmezett konfigurációban vagy — érdemes PIN-t hozzáadni.

Mikor lesz hivatalos javítás?

A cikk írásakor nincs dátum. A legvalószínűbb a 2026. júniusi Patch Tuesday vagy egy soron kívüli (out-of-band) frissítés. Tartsd bekapcsolva az automatikus frissítést, és figyeld a Microsoft biztonsági közleményeit.

Kell pánikolni? — reális kockázatértékelés

Röviden: aggódni nem, de cselekedni érdemes. A YellowKey nem az a fajta hiba, amely egy weboldal megnyitásával vagy egy e-mail-melléklettel távolról ledönti a védelmedet — ehhez valakinek a kezébe kell vennie a gépedet. Az átlagos otthoni felhasználó számára, aki a laptopját nem hagyja idegenek között, a közvetlen kockázat mérsékelt.

Ahol viszont a kockázat valós és jelentős: a lopás, elvesztés, hatósági lefoglalás vagy „gonosz szobalány" (evil maid) típusú helyzetek — vagyis pontosan azok a forgatókönyvek, amelyek miatt a BitLockert egyáltalán használjuk. Újságírók, ügyvédek, vezetők, sokat utazó szakemberek és a céges IT-üzemeltetés számára ez nem elméleti probléma. Számukra a TPM + PIN és a BIOS-szintű megerősítés most nem opció, hanem ajánlott azonnali teendő.

A tanulság túlmutat ezen az egy hibán: a teljeslemez-titkosítás egy védelmi réteg, nem mindenható pajzs. A rétegzett védelem — erős fizikai biztonság, indítás előtti hitelesítés, naprakész rendszer és átgondolt szervezeti folyamatok — az, ami egy ilyen zero-day megjelenésekor is talpon tart. Amint a Microsoft kiadja a hivatalos javítást és a CVE-azonosítót, visszatérünk a témára a konkrét frissítési teendőkkel.

Ez a cikk a 2026. május közepén nyilvánosan elérhető, több független forrás (BleepingComputer, The Hacker News, SecurityWeek, SecurityAffairs) által közölt információk alapján készült. A helyzet aktívan fejlődik; a technikai részletek a hivatalos Microsoft-közlemény megjelenésével pontosodhatnak.