Eine neue Variante von Spectre V2 kann veraltete Sprungvorhersagen in Just-in-Time-Engines wiederverwenden und darüber sensible Daten auslesen. Forscher der Vrije Universiteit Amsterdam und der Scuola Superiore Sant’Anna nennen den Angriff Branch Target Reuse, kurz BTR. Untersucht wurden unter anderem der cBPF-JIT des Linux-Kernels, Oracle GraalVM und Mozillas JavaScript-Engine SpiderMonkey. Der Schwachstellenkomplex wird unter CVE-2026-64507 und CVE-2026-64508 geführt.
Die konkrete Tragweite ist enger als die Bezeichnung „Spectre ist zurück“ vermuten lässt. Nachgewiesen wurden Forschungsangriffe und zwei End-to-End-Proofs-of-Concept gegen den Linux-cBPF-JIT auf Intel-Systemen. Hinweise auf beobachtete oder aktiv ausgenutzte Angriffe liegen nicht vor. Linux und Oracle haben bereits Gegenmaßnahmen umgesetzt; Mozilla priorisiert Site Isolation, statt BTR unmittelbar mit einer IBPB-basierten Abwehr zu adressieren.
Entscheidend ist dabei nicht nur, ob ein Prozessor spekulativ arbeitet. BTR benötigt eine JIT-Umgebung, in der erzeugter Maschinencode verschwindet und der zugehörige Code-Cache später neu belegt wird. Genau an dieser Wiederverwendung hängt der Angriff.
Alte Sprungziele überleben neuen Maschinencode
JIT-Engines übersetzen Code erst während der Ausführung in Maschinencode. Das kommt in Browsern und Laufzeitumgebungen vor, aber auch in Kernel-Komponenten wie cBPF. Speicherbereiche des Code-Caches werden dabei angelegt, freigegeben und später erneut verwendet.
Wie Branch Target Reuse alte JIT-Sprungziele nutzt
Die Grafik zeigt die fünf Schritte vom erzeugten JIT-Code über einen veralteten Eintrag der Sprungvorhersage bis zum Datenleck über einen Seitenkanal.
Moderne Prozessoren stellen nach einer solchen Codeänderung zwar die architektonische Kohärenz wieder her: Regulär ausgeführter Code sieht den aktuellen Inhalt des Speichers. Nach Erkenntnissen der Forscher werden jedoch nicht zwingend alle alten Einträge der indirekten Sprungvorhersage entfernt. Ein zuvor gelerntes Sprungziel kann deshalb länger existieren als der Code, auf den es ursprünglich verwies.
Wird derselbe Bereich später erneut mit JIT-Code belegt, kann die CPU während der spekulativen Ausführung vorübergehend einem veralteten Ziel folgen. Die Forscher sprechen von einer spekulativen Execute-after-Free-Primitive. Die irrtümlich ausgeführten Operationen werden zwar verworfen, können aber Spuren im mikroarchitektonischen Zustand hinterlassen. Diese lassen sich über einen Seitenkanal auswerten.
BTR ist nach Darstellung der Autoren der erste praktische „in-place“-Spectre-V2-Angriff auf JIT-Compiler. Die Manipulation bleibt am Sprung des Opfers, statt die Spekulation zu einem Ziel auf einem anderen Branch umzulenken. Dadurch kann der Angriff auch softwarebasierte Kontrollflussmechanismen wie FineIBT umgehen.
Die Linux-Demonstration braucht lokalen Zugriff
Die Forscher entwickelten zwei vollständige Exploits gegen den cBPF-JIT eines Intel-basierten Linux-Kernels. Ein unprivilegierter lokaler Benutzer konnte damit den Root-Passworthash auslesen, obwohl cBPF eine Constant-Binding-Abwehr verwendete. Die Demonstration setzt somit lokalen Codezugriff und den angegriffenen JIT-Pfad voraus; sie belegt keinen beliebigen Fernangriff auf jedes System mit einer betroffenen CPU.
Auch der ausgelesene Passworthash ist nicht mit dem Root-Passwort im Klartext gleichzusetzen. Er bleibt dennoch hochsensibles Authentifizierungsmaterial. Gerade dieser Versuch zeigt, warum eine geringe Übertragungsrate bei Seitenkanälen nicht automatisch ein geringes Risiko bedeutet: Für Schlüssel, Hashes und andere kurze Geheimnisse reichen vergleichsweise wenige Bytes.
Für Intel Raptor Cove errechneten die Forscher eine mögliche Kanalleistung von 5,7 KB pro Sekunde, für Lion Cove 5,4 KB pro Sekunde. Der vollständige cBPF-Exploit erreichte dagegen nur etwa acht Byte pro Sekunde. Die höheren Werte beschreiben damit nicht den Durchsatz der gesamten Linux-Angriffskette. Trotzdem ließ sich der Root-Hash nach Angaben der Forscher innerhalb weniger Minuten gewinnen.
Die zugrunde liegende BTR-Problematik betrifft den Forschungsergebnissen zufolge CPUs von Intel, AMD und Arm. Praktisch demonstriert wurden die beschriebenen Linux-Exploits jedoch auf Intel-Systemen. Für AMD- und Arm-Plattformen sowie für SpiderMonkey wurde in den vorliegenden Angaben kein vergleichbarer End-to-End-Exploit mit derselben Wirkung dokumentiert.
Linux, Oracle und Mozilla wählen verschiedene Wege
Linux begegnet BTR auf x86-Systemen mit einer gezielten Maßnahme: Wenn ein cBPF-Programm Speicherbereiche wiederverwendet, wird auf allen CPU-Kernen ein IBPB-Flush ausgelöst. Die Indirect Branch Predictor Barrier soll die problematischen Vorhersageeinträge entfernen, bevor sie mit neuem JIT-Code kombiniert werden können.
Oracle verfolgt bei GraalVM einen anderen Ansatz. Das Unternehmen verhindert die vorhersehbare Wiederverwendung betroffener Regionen, indem es die Speicherorte des JIT-Code-Caches randomisiert. Mozilla hat sich nach Angaben der Forscher gegen eine direkte IBPB-basierte BTR-Mitigation entschieden und konzentriert seine Arbeiten stattdessen auf Site Isolation.
Die Unterschiede sind operativ relevant. IBPB gilt als starke Abwehr, erzeugt aber zusätzliche Komplexität und kann Leistung kosten. Andere Ansätze versuchen, die für BTR notwendige Wiederverwendung zu erschweren oder die Auswirkungen zwischen getrennten Sicherheitsbereichen zu begrenzen. Es gibt deshalb keinen einzelnen Patch, der unabhängig von JIT-Engine, Betriebssystem und Laufzeitumgebung überall identisch eingesetzt werden kann.
Was Betreiber jetzt prüfen sollten
Administratoren sollten zunächst Kernel-, Distributions- und Oracle-Sicherheitsupdates einspielen und die Hinweise zu CVE-2026-64507 und CVE-2026-64508 verfolgen. Für Browser und eingebettete JavaScript-Laufzeiten bleiben reguläre Herstellerupdates entscheidend. Pauschale Änderungen an CPU-Einstellungen oder das Abschalten sämtlicher JIT-Funktionen lassen sich aus den veröffentlichten Ergebnissen nicht als allgemeine Sofortmaßnahme ableiten.
Wichtig ist außerdem eine Bestandsaufnahme der tatsächlich eingesetzten JIT-Komponenten. Besonders relevant sind Umgebungen, in denen nicht vertrauenswürdige oder gering privilegierte Benutzer Code ausführen können und JIT-Code-Caches wiederverwendet werden. Die Linux-Demonstration betrifft genau diese Kombination. Ein Prozessor aus einer betroffenen Familie allein beweist dagegen noch nicht, dass der gezeigte Angriff unter einer konkreten Konfiguration funktioniert.
Konkrete betroffene und gepatchte Versionsnummern sowie eine einheitliche CVSS-Bewertung gehen aus den bislang vorliegenden Angaben nicht hervor. Betreiber sollten deshalb nicht nach einer vermeintlich universellen Mindestversion suchen, sondern die Advisories ihres Kernels, ihrer Distribution und der eingesetzten Runtime heranziehen.
Das BTR-Paper wurde für die ACM Conference on Computer and Communications Security 2026 angenommen, die vom 15. bis 19. November in Den Haag stattfindet. Der praktisch wichtige Befund steht bereits fest: Bei dynamisch erzeugtem Code endet die Lebensdauer eines Programms nicht zwingend gleichzeitig mit der Lebensdauer der CPU-Vorhersage, die es hinterlassen hat. Wer JIT-Speicher wiederverwendet, muss daher nicht nur den sichtbaren Codezustand bereinigen, sondern auch schwerer greifbare Zustände im Prozessor berücksichtigen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
