Spectre-v2-Variante BTR: JIT-Code leakt Linux-Kernelspeicher trotz Abwehr

Forscher der VU Amsterdam (VUSec) und der Scuola Superiore Sant'Anna haben am 29. September 2026 mit Branch Target Reuse (BTR) eine neue Spectre-v2-Variante öffentlich gemacht. Betroffen sind laut den Forschern alle getesteten Prozessoren von Intel, AMD und Arm. Praktisch relevant ist BTR vor allem für Linux-Systeme, auf denen fremde oder nicht vertrauenswürdige Nutzer lokal Code ausführen können: Mehrbenutzer-Server, Shared Hosting, CI-Runner und Hosts mit Containern verschiedener Kunden. Dort konnten die Forscher auf aktuellen Intel-CPUs trotz aller aktiven Spectre-Abwehrmaßnahmen beliebigen Kernelspeicher auslesen und den Hash des Root-Passworts in wenigen Minuten erbeuten.

Die gute Nachricht: Die Linux-Korrekturen (CVE-2026-64507 und CVE-2026-64508) sind seit Juli im Mainline-Kernel und bereits in die Stable-Zweige zurückportiert. Wer seine Kernel in den letzten Wochen regelmäßig aktualisiert und neu gestartet hat, ist auf Kernelseite in der Regel schon geschützt. Einzelplatzsysteme ohne fremde lokale Nutzer sind deutlich weniger exponiert. Heute sollten Admins vor allem prüfen, ob auf Mehrbenutzer- und Container-Hosts tatsächlich ein korrigierter Kernel läuft. Ein Notfall-Patch in der Nacht ist nicht nötig, ein veralteter Kernel auf einem geteilten Host gehört aber in dieses Wartungsfenster.

Was ist passiert?

Das VUSec-Team hat seine Arbeit auf der Projektseite zu BTR veröffentlicht, das zugehörige Paper ist für die ACM-Konferenz CCS 2026 angenommen. Das Embargo endete am 29. September 2026, am selben Tag berichteten BleepingComputer, SecurityWeek und Phoronix. Die Hersteller waren vorab informiert, die Offenlegung gegenüber den Linux-Entwicklern erfolgte bereits im Juli.

Der Kern des Angriffs: Moderne CPUs stellen nach selbstmodifizierendem Code zwar die architektonische Konsistenz wieder her, verwerfen aber nicht unbedingt veraltete Einträge im Sprungziel-Puffer (Branch Target Buffer) für indirekte Sprünge. JIT-Compiler geben Speicher für kompilierten Code frei und belegen dieselbe Adresse später mit neuem Code. Ein alter Vorhersageeintrag überlebt diesen Wechsel und lenkt die spekulative Ausführung an einen Versatz im neuen Code, der dort nie angesprungen werden dürfte. Die Forscher sprechen von einem spekulativen Execute-after-free.

Untersucht wurden drei JIT-Engines:

• Linux cBPF: Zwei vollständige Exploits. Die Forscher installieren zwei klassische BPF-Programme als seccomp-Filter, trainieren den Sprung mit dem ersten, entfernen es und laden das zweite in denselben Speicherbereich. Der Angriff leakt etwa 8 Byte pro Sekunde.
• Root-Passwort-Hash: In der Demo lesen die Forscher den Hash aus dem Speicher eines laufenden su-Prozesses. Laut BleepingComputer dauerte das auf Raptor Cove im Schnitt 3 und auf Lion Cove 5 Minuten.
• Constant Blinding umgangen: Auch mit aktivierter Härtung bpf_jit_harden, die standardmäßig aus ist, gelang ein Exploit über kodierte Sprungweiten.
• Firefox SpiderMonkey: Ein Proof of Concept zeigt, dass veraltete Einträge auf Intel-CPUs den Codewechsel überleben. Einen vollständigen Browser-Exploit gibt es noch nicht.
• Oracle GraalVM: Die Maskierung der Sandbox lässt sich spekulativ überspringen. In den Experimenten löschten Compiler- und Garbage-Collection-Aktivität die Einträge aber, bevor ein Angriff gelang.

Wer ist betroffen?

Die Forscher haben das Verhalten auf jeder getesteten CPU von Intel, AMD und Arm bestätigt und schreiben, dass derzeit keine CPU einen Mechanismus besitzt, um Sprungvorhersage und tatsächlichen Code synchron zu halten. Die vollständigen Exploits laufen allerdings nur auf modernen Intel-CPUs. Für AMD und Arm ist das Verhalten nachgewiesen, ein fertiger Angriff aber nicht veröffentlicht. AMD erklärte gegenüber SecurityWeek, das Paper zeige keine neue Schwachstelle in AMD-Produkten, die Technik sei durch bestehende Spectre-v2-Empfehlungen abgedeckt. Intel und Arm hatten sich dort bis zur Veröffentlichung nicht geäußert.

Auf Linux-Seite ist entscheidend, dass klassisches BPF (cBPF) weiterhin für unprivilegierte Prozesse erreichbar ist, etwa über seccomp-Filter und Socket-Filter. Das deutlich mächtigere eBPF ist dagegen privilegierten Nutzern vorbehalten. Relevant sind damit vor allem:

• Linux-Server mit Shell-Zugängen für mehrere Nutzer, etwa Hosting, Hochschul- oder Entwicklungsserver.
• Container-Hosts und CI-Runner, die Workloads aus unterschiedlichen Quellen ausführen.
• Virtualisierte Umgebungen, in denen Kunden eigene Prozesse im selben Kernel betreiben. Ob BTR über VM-Grenzen hinweg funktioniert, belegen die Quellen nicht.
• Systeme mit Firefox, sobald ein Browser-Exploit nachgereicht werden sollte. Heute ist das ein theoretisches Risiko.
• Anwendungen, die GraalVM-Sandboxes für fremden Code wie Plugins oder Nutzerskripte verwenden.

Laut den CVE-Einträgen betroffen sind Linux-Kernel ab Version 5.18. Korrigiert sind 6.1.183, 6.6.145, 6.12.97, 6.18.39 und 7.1.4 in den jeweiligen Stable-Zweigen sowie Linux 7.2. Debian führt die Korrektur in Trixie ab 6.12.100-1 (DSA-6405-1) und in Bookworm ab 6.1.187-1 (DLA-4777-1). Kernel älter als 5.18 werden in den CVE-Einträgen als nicht betroffen geführt.

Wie kritisch ist das?

BTR ist kein Fernangriff. Ein Angreifer muss bereits Code auf dem Zielsystem ausführen können. Der Schaden ist dann aber erheblich: Er kann Kernelspeicher lesen und damit Geheimnisse anderer Prozesse und Nutzer abgreifen, auch wenn alle bisherigen Spectre-Abwehrmaßnahmen aktiv sind. Ein Passwort-Hash ist zwar nicht das Klartextpasswort, lässt sich aber offline angreifen. Wie schnell das gelingt, hängt vom Hash-Verfahren und der Passwortstärke ab.

Einen CVSS-Wert oder Berichte über Angriffe in freier Wildbahn nennen die ausgewerteten Quellen nicht. Die Hardware-Hersteller sehen die Abwehr in der Software. Die Linux-Entwickler haben dafür unter x86 eine IBPB-Barriere (Indirect Branch Predictor Barrier) eingeführt, die auf allen Kernen ausgelöst wird, wenn ein cBPF-Programm einen zuvor ausgeführten BPF-Speicherbereich wiederverwendet. Oracle randomisiert in GraalVM die Lage des JIT-Code-Caches. Mozilla priorisiert laut VUSec die vollständige Site Isolation in Firefox statt einer IBPB-Lösung.

Hardware-Schutz wie Intel IBT und Arm BTI erschwert den Angriff, beseitigt ihn laut den Forschern aber nicht. Auf älteren Intel-CPUs werden vor der Prüfung noch Befehle spekulativ ausgeführt. Lion Cove ist die erste Intel-Generation, bei der die Forscher dieses Zeitfenster nicht fanden. Die stärkste Kombination ist nach ihrer Einschätzung ein solches IBT zusammen mit Constant Blinding. Für geteilte Linux-Hosts mit veraltetem Kernel ist BTR damit zeitnah zu behandeln, für Einzelplatzsysteme ohne fremde lokale Nutzer ist das Risiko gering.

Was sollten Admins jetzt tun?

• Kernelversionen inventarisieren: Auf allen Linux-Hosts mit uname -r den laufenden Kernel erfassen und mit den korrigierten Versionen der Distribution abgleichen. Unter Debian liefert apt changelog linux-image-$(uname -r) oder der Security Tracker den Stand. Wichtig ist der laufende, nicht der installierte Kernel.
• Kernel-Updates einspielen und neu starten, zuerst auf Mehrbenutzer-Servern, Container-Hosts und CI-Runnern. Wer Livepatching nutzt, sollte beim Anbieter prüfen, ob beide CVEs abgedeckt sind.
• Den allgemeinen Spectre-v2-Schutz kontrollieren: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 zeigt, ob IBPB und weitere Maßnahmen aktiv sind. Einen eigenen Eintrag für BTR nennen die Quellen nicht, maßgeblich bleibt die Kernelversion.
• Prüfen, ob Spectre-Mitigations per Bootparameter abgeschaltet wurden, etwa mit mitigations=off oder nospectre_v2 in /proc/cmdline. Die Kernel-Korrektur greift laut CVE-Text nur bei aktiven Spectre-v2-Mitigations.
• Auf Hosts mit fremden Nutzern sysctl net.core.bpf_jit_harden abfragen und den Wert 2 erwägen. Die Einstellung kostet Leistung und schützt allein nicht vollständig, erschwert aber JIT-Spraying.
• Microcode- und Firmware-Updates der Hersteller wie gewohnt einspielen. Eine eigene BTR-Korrektur per Microcode kündigen die Quellen nicht an, bestehende Barrieren wie IBPB setzen aber aktuellen Microcode voraus.
• Firefox aktuell halten und die weitere Entwicklung bei Mozilla beobachten. Anwendungen mit GraalVM-Sandbox auf die aktuelle Version bringen.
• Lokale Zugänge auf geteilten Servern überprüfen: nicht mehr benötigte Shell-Konten entfernen und fremden Code nur in klar getrennten Umgebungen ausführen.

Einordnung für Unternehmen

Für die meisten kleinen und mittleren Unternehmen ist BTR kein Anlass zur Panik. Der Angriff setzt lokale Codeausführung voraus, und die Kernel-Korrektur ist über die normalen Distributionsupdates längst verfügbar. Wer Linux-Server per automatischer Sicherheitsupdates pflegt und Neustarts nicht monatelang aufschiebt, dürfte bereits geschützt sein. Genau hier liegt aber die typische Lücke: Der neue Kernel ist installiert, der Server läuft noch mit dem alten.

Mehr Aufmerksamkeit verdienen Umgebungen, in denen Code aus unterschiedlichen Vertrauensbereichen auf demselben Kernel läuft. Dazu zählen selbst betriebene CI-Runner für externe Beiträge, Container-Plattformen für mehrere Kunden und Entwicklungsserver mit vielen Konten. Langfristig zeigt BTR, dass Spectre ein Dauerthema bleibt: Solange CPUs Vorhersage und Code nicht selbst synchron halten, müssen Betriebssysteme und Laufzeitumgebungen nachbessern. Aktuelle Kernel, aktive Mitigations und eine saubere Trennung von Mandanten bleiben die wirksamsten Maßnahmen.

Passende Anleitungen auf S-EDV

• Unattended Upgrades: automatische Sicherheitsupdates unter Debian und Ubuntu: damit Kernel-Korrekturen zeitnah auf dem Server landen.
• Linux-Server nach CIS-Benchmark härten: Grundhärtung für Mehrbenutzer- und Container-Hosts.
• Linux-Kernel CVE-2026-68480: Safe-RET-Umgehung auf AMD Zen: eine weitere aktuelle Lücke rund um spekulative Ausführung.

Quellen

• VUSec: Branch Target Reuse, Projektseite mit technischen Details und FAQ (29.09.2026)
• CVE-2026-64507: x86/bugs, IBPB-Flush bei BPF-JIT-Allokation
• CVE-2026-64508: bpf, Härtung gegen JIT-Spraying
• Debian Security Tracker zu CVE-2026-64507
• BleepingComputer: neue Spectre-v2-Variante leakt Root-Passwort-Hash (29.09.2026)
• SecurityWeek: Spectre-v2-Variante betrifft Intel, AMD und Arm, mit Stellungnahme von AMD (29.09.2026)
• Phoronix: BTR und die Kernel-Korrekturen seit Juli (29.09.2026)
• Kernel-Dokumentation zu bpf_jit_harden