LONDON (IT BOLTWISE) – Microsoft warnt vor CVE-2026-45585 („YellowKey“): Ein Angreifer mit physischem Zugriff kann in der Windows Recovery Environment WinRE vertrauenswürdige Abläufe missbrauchen, um auf BitLocker-verschlüsselte Daten zuzugreifen. Die Schwachstelle liegt nicht in der Laufwerksverschlüsselung selbst, sondern im Recovery-Kontext, der beim Booten automatisch mitläuft. Für Unternehmen wird damit vor allem das Zusammenspiel aus Recovery-Images, USB/EFI-Zugriff und BitLocker-Trust-Setups zum kritischen Härtungsthema.
BitLocker gilt in vielen Rechenzentren und Endgeräteflotten als letzte Verteidigungslinie gegen Offline-Zugriffe: Das Laufwerk bleibt auch dann geschützt, wenn ein Gerät gestohlen, ausgeschaltet oder später an fremder Hardware betrieben wird. Genau deshalb sorgt CVE-2026-45585 („YellowKey“) für Aufmerksamkeit. Microsoft beschreibt eine Umgehung von BitLocker über die Windows Recovery Environment (WinRE), bei der ein Angreifer mit physischem Zugriff vertrauenswürdige Vorab-Boot-Schritte so ausnutzen kann, dass er während der Recovery-Phase auf die geschützte Partition zugreift. Entscheidend: Der Angriff zielt nicht auf die Kryptografie des Datenträgers, sondern auf die Umgebung, die BitLocker im Wiederherstellungsmodus „ermöglicht“.
Technisch betrachtet entsteht das Risiko aus der Rolle des Recovery-Kontexts rund um BitLocker. In den öffentlich diskutierten Analysen wird betont, dass die Schwachstelle nicht in der Verschlüsselungsfunktion selbst liegt, sondern in der Art, wie Windows den Wiederherstellungsablauf vorbereitet und bestimmte Tools automatisiert startet. Damit wird ein typisches Vertrauensmodell angreifbar: Systeme gehen davon aus, dass WinRE-Logik nur im legitimen Wartungsfall greift. Wenn ein Angreifer jedoch über präparierte Recovery-Ressourcen (etwa spezielle FsTx-Dateien auf Wechselmedien oder EFI-Pfaden) in diese Abläufe hineingerät, kann daraus ein missbräuchlicher Pfad entstehen, der die Kontrolle über den Boot-Flow verschiebt und schließlich unautorisierte Shell-Zugriffe ermöglicht.
Aus Sicht der Ausnutzung ist CVE-2026-45585 vor allem lokal und vor-boot-basiert. Der öffentlich beschriebene Weg geht über das Platzieren manipulierter FsTx-Dateien auf einem USB-Stick oder in einer EFI-Struktur, das anschließende Verbinden dieser Medien mit einem betroffenen System und das Booten in WinRE. Während des Recovery-Starts kann ein Angreifer dann über Tastaturinteraktionen (im Bericht wird das Halten einer CTRL-Taste hervorgehoben) einen eingeschränkten Schutz in einen unbeschränkten Shell-Kontext verwandeln. Das ist weniger ein klassisches „Remote Exploit“-Szenario, sondern eher ein physisches Angriffsmodell: Wer das Gerät kontrolliert und einen Reboot auslösen kann, erhält Zeitfenster, in denen die normalerweise geschützten Datenpfade erreichbar werden.
Für die Verteidigung verschiebt sich damit der Schwerpunkt: Detektion und Risikoanalyse sind komplexer, weil kein „normaler“ Netzwerk-IOC-Stream (Indikatoren wie IPs, Domains oder typische Payload-Signaturen) erwartet wird. In den vorliegenden Berichten werden zudem keine klaren, vendorseitigen CVE-2026-45585-IOCs genannt. Realistisch ist deshalb ein asset-getriebener Ansatz: betroffene Windows-11-Builds (inklusive 24H2, 25H2 sowie 26H1 auf x64) und Windows Server 2025, einschließlich Server Core, müssen identifiziert werden. Danach folgt die technische Prüfung, ob BitLocker-Trust im WinRE-Kontext über Microsofts temporäre Maßnahme aktualisiert wurde. Da viele Organisationen BitLocker-Images, Recovery-WIMs oder Labor-/Imaging-Prozesse zentral verwalten, ist diese Prüfung häufig schneller erreichbar als eine rein beobachtungsbasierte Erkennung.
Auch die Unternehmenswirkung lässt sich gut historisch einordnen: Seit Jahren existieren in der Praxis Diskussionen darüber, wie stark „at rest“-Schutz ist, wenn Recovery-Mechanismen, Pre-Boot-Umgebungen oder Schlüsselbereitstellung selbst als Angriffsfläche dienen. Frühe Angriffe konzentrierten sich oft auf schwache Passphrase- oder Key-Handling-Prozesse; mit der Verbreitung von TPM-gestützter Absicherung und standardisierten Recovery-Flows verlagert sich die Aufmerksamkeit auf die Komponenten „davor und drumherum“. In diesem Sinn ist CVE-2026-45585 ein klassisches Beispiel dafür, dass Verschlüsselung nur so robust ist wie das gesamte Ökosystem aus Boot-Chain, Authentifizierung und Recovery-Logik. Sicherheitsexperten betonen sinngemäß: „Wenn der Recovery-Zugang bequem und automatisiert ist, muss genau dieses Komfortniveau als potenzielle Angriffsfläche behandelt werden.“
Microsoft bietet zwei Hauptlinien zur Härtung an, die beide auf das Vertrauen in WinRE bzw. auf die Startup-Authentifizierung abzielen. Der erste Weg ist eine Anpassung des gemounteten WinRE-Images: Dabei soll autofstx.exe aus dem Session-Manager-„BootExecute“-Setting entfernt werden, was die automatische Startlogik im Recovery-Kontext unterbindet. Operativ erfordert das ein sicheres Mounten des WinRE-Images, das Ändern der Offline-Registry (insbesondere im SYSTEM-Hive), das Unmounting sowie das erneute „Resealing“ des BitLocker-Trusts, damit WinRE wieder korrekt eingebunden ist. Laut den veröffentlichten Hinweisen ergänzt Microsoft die Advisory später um einen Skript-Workflow, der genau diese Schritte kontrolliert automatisiert und damit das Risiko von Fehlkonfigurationen im Imaging-Prozess reduziert.
Der zweite Mitigationspfad verschiebt das Sicherheitsniveau hin zu stärkerer Startup-Authentifizierung: TPM-only wird durch TPM plus PIN ersetzt. Microsoft empfiehlt dafür PowerShell, die Command Line oder den Control Panel-Umweg für bereits verschlüsselte Systeme; bei neuen oder noch nicht verschlüsselten Geräten sollen Administratoren „Require additional authentication at startup“ über Group Policy oder Intune aktivieren und einen Startup-PIN konfigurieren. In den Analystenberichten wird außerdem diskutiert, dass Forschende den ersten WinRE-basierten Fix als wirksam einstufen, während für den TPM+PIN-Umweg ein separater Bypass vorübergehend nicht im Detail offen gelegt sei. Für Unternehmen bedeutet das: Wo physischer Zugriff nicht strikt verhindert werden kann, ist TPM+PIN oft langfristig die konservativere Strategie, selbst wenn sie für Nutzer und Prozesse zusätzliche Hürden mitbringt.
Markt- und Wettbewerbsbetrachtung hilft, die Dringlichkeit realistisch zu skalieren. Disk-Verschlüsselung ist branchenweit ein Standardbaustein, doch die Angriffsflächen unterscheiden sich. Während Microsoft-Umgebungen stark über BitLocker und die UEFI/WinRE-Kette charakterisiert sind, setzen andere Plattformen wie Apple mit FileVault oder bestimmte Linux-Setups auf abweichende Recovery- und Boot-Mechaniken. In der Praxis heißt das: CVE-2026-45585 ist für heterogene Landschaften keine „nur Windows“-Thematik im Sinne von „nicht relevant“. Vielmehr sollten Security-Teams ihre Recovery- und Pre-Boot-Härtungspraktiken generell überprüfen, etwa indem sie nachvollziehbar machen, welche Images, Tools und Autostarts im Wiederherstellungsfall tatsächlich laufen.
Für die zukünftige Roadmap ergibt sich daraus ein klarer Handlungsimpuls: Unternehmen sollten Recovery-Images als Teil der Security Supply Chain betrachten, inklusive Versionierung, Signierung/Integrität und kontrollierter Bereitstellung in Imaging- und Patch-Prozessen. Ein weiterer Punkt ist der Abgleich zwischen physischer Bedrohung und technischen Schutzmaßnahmen: Wenn ein Angreifer nur kurz Zugang zum Gerät bekommt, entscheidet oft das Zeitfenster zwischen Reboot und Recovery-Initialisierung. In der Praxis lassen sich diese Risiken reduzieren, indem Gerätezugang stärker gerahmt wird (z. B. durch organisatorische Controls), und indem technische Härtungen wie WinRE-Anpassungen oder TPM+PIN systematisch gerollt werden. Gleichzeitig sollten Teams erwarten, dass weitere Varianten oder neue Recovery-Pfade nachgezogen werden, sobald Angreifer lernen, welche Teile des Boot-Trust-Containers am flexibelsten sind.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "CVE-2026-45585 YellowKey: BitLocker-Bypass über WinRE entschärfen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "CVE-2026-45585 YellowKey: BitLocker-Bypass über WinRE entschärfen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »CVE-2026-45585 YellowKey: BitLocker-Bypass über WinRE entschärfen« bei Google Deutschland suchen, bei Bing oder Google News!