Codeausführung durch Webseitenbesuch : Firefox-JIT-Lücke öffnete den Weg vom Browser bis zum Android-Kernel

Eine präparierte Webseite genügte einer neueren Analyse zufolge, um unter Android Schadcode im Firefox– und Tor-Browser-Prozess auszuführen. Eine inzwischen geschlossene Schwachstelle im Just-in-Time-Compiler ermöglichte zunächst beliebige Speicherzugriffe. Mit einer zweiten Kernel-Lücke ließ sich der Angriff bis zu Root-Rechten ausweiten.

Die Anfang Juni als CVE-2026-10702 erfasste Schwachstelle steckte im Just-in-Time-Compiler (JIT) von Firefox. Mozilla bewertete sie mit „high“ und beseitigte sie mit Version 151.0.3. Nach Angaben von Nebula Security waren auch Ausgaben des Tor-Browsers betroffen, die auf einer verwundbaren Firefox-Version basierten (siehe Erläuterungen am Ende dieses Beitrags); welche Tor-Versionen dies im Einzelnen waren, ist bislang nicht abschließend dokumentiert. „Es sind weder besondere Einstellungen noch zusätzliche Aktionen des Nutzers erforderlich“, so Nebula Geschäftsführer Eten Zou. Der Besuch einer manipulierten Webseite habe genügt, um den Angriff zu starten.

Codeausführung zunächst innerhalb der Sandbox

CVE-2026-10702 ermöglicht beliebige Codeausführung im Renderer beziehungsweise im isolierten Content-Prozess des Browsers. Dieser Prozess ist durch eine Sandbox vom restlichen Betriebssystem getrennt. Ein erfolgreicher Angriff bedeutet daher nicht automatisch, dass ein Angreifer sofort vollständige Kontrolle über das Gerät erhält. Nebula nutzte die Schwachstelle jedoch als erste Stufe der jetzt veröffentlichten Exploit-Kette IonStack – sie wurde speziell für ein unterstütztes ARM64-Gerät mit Android 17 entwickelt und kombiniert den Browserfehler mit einer zweiten Schwachstelle im Linux-Kernel. Der veröffentlichte Beispielcode enthält konkrete Speicheradressen und Offsets für Firefox 151.0 auf einer bestimmten ARM64-Version von Android 17; die zugrunde liegende Browserlücke ist laut Zou jedoch nicht auf ARM64 beschränkt. Die einzelnen Angriffsschritte seien grundsätzlich architekturunabhängig; der x86-Pfad gelte sogar als stabiler. Eine vollständige öffentlich dokumentierte Exploit-Kette für x86 liegt bislang allerdings nicht vor.

Fehlerhafte Annahme im JIT-Compiler

Die Ursache liegt laut Nebula-Analyse in der Compileroperation MObjectToIterator. Sie wird unter bestimmten Bedingungen mit der Option skipRegistration ausgeführt. Der JIT-Compiler übersetzt häufig verwendeten JavaScript-Code während der Laufzeit in nativen Maschinencode. Um diesen Code sicher optimieren zu können, muss der Compiler genau wissen, welche Operationen Speicher lediglich lesen und welche ihn verändern. Bei CVE-2026-10702 behandelte Firefox eine Operation fälschlicherweise als reinen Lesezugriff. Tatsächlich konnte das Auflösen einer verzögert erzeugten Objekteigenschaft einen neuen Speicherbereich für sogenannte “Dynamic Slots” anlegen und den bisherigen Speicherbereich freigeben. Diese Dynamic Slots enthalten zusätzliche Eigenschaften eines JavaScript-Objekts, die nicht direkt im festen Objektbereich gespeichert werden. Wird dieser Puffer ersetzt, verliert ein zuvor gespeicherter Zeiger auf den alten Bereich seine Gültigkeit.

Optimierung verwendet freigegebenen Zeiger erneut

Anschließend griff die Compileroptimierung “Global Value Numbering” (GVN) ein: GVN sucht nach mehrfach ausgeführten Berechnungen mit identischem Ergebnis. Erkennt der Compiler einen vermeintlich redundanten Ladevorgang, verwendet er einen bereits ermittelten Wert erneut, statt nochmals auf den Speicher zuzugreifen. Da die vorherige Operation fälschlicherweise nur als lesend gekennzeichnet war, nahm der Compiler an, der Zeiger auf den Slots-Puffer sei weiterhin gültig. Tatsächlich war der Puffer inzwischen ersetzt und der alte Speicher freigegeben worden. Der optimierte Code arbeitete deshalb mit einem veralteten Zeiger weiter. Es entstand ein “Use-after-free”-ähnlicher Zustand innerhalb des generierten Maschinencodes.

Der Compiler stufte einen Vorgang fälschlicherweise als reinen Lesezugriff ein, obwohl er den Speicher des Objekts verändern konnte. Deshalb ging die anschließende Optimierung davon aus, dass ein bereits geladener Speicherzeiger weiterhin gültig war. Tatsächlich zeigte er jedoch auf einen inzwischen freigegebenen Speicherbereich.

Vom Speicherfehler zur Schreibkontrolle

Der Exploit sorgt zunächst dafür, dass der zuvor freigegebene Speicherbereich mit kontrollierten Daten neu belegt wird. So kann er interne Informationen über den Aufbau eines JavaScript-Objekts auslesen und anschließend ein gefälschtes Objekt erzeugen. Danach manipuliert er ein Uint8Array, das JavaScript normalerweise für die Verarbeitung binärer Daten nutzt. Verändert der Angreifer dessen Angaben zur Speicheradresse und Größe, kann er auf beliebige Bereiche im Speicher des Browserprozesses zugreifen und dort Daten lesen oder überschreiben.

Im Android-17-Beispiel nutzt der Exploit diese Kontrolle, um Speicherbereiche ausführbar zu machen. Anschließend lenkt er eine WebAssembly-Funktion (Wasm) auf eingeschleusten ARM64-Schadcode um. Das ist möglich, weil der Wasm-Code in direkt ausführbaren Maschinencode übersetzt und im Arbeitsspeicher verwaltet.

Zweite Lücke führt zu Root-Rechten

Die zweite Stufe von IonStack nutzt CVE-2026-43499, eine separate Schwachstelle im Futex-Mechanismus des Linux-Kernels. Nebula bezeichnet diese Lücke als GhostLock. Futexe dienen der schnellen Synchronisierung von Threads zwischen Benutzer- und Kernelmodus.

Zunächst ermöglicht CVE-2026-10702 über eine manipulierte Webseite die Ausführung von Schadcode im Firefox-Prozess. Dieser Code ist jedoch noch durch die Browser-Sandbox vom restlichen System getrennt. GhostLock dient anschließend dazu, diese Begrenzung zu überwinden: Der Exploit greift aus dem bereits kompromittierten Browserprozess den Kernel an und erlangt auf dem unterstützten Android-System Root-Rechte. Damit erhält er weitreichende Kontrolle über das Gerät. Nach Angaben von Eten Zou wird GhostLock direkt aus dem übernommenen Firefox-Prozess gestartet – die weniger strenge Browser-Sandbox von Android erleichtert diesen Schritt. Eine stärker abgeschottete Desktop-Sandbox hätte den Angriff nach Einschätzung von Nebula zwar erschwert, ihn aber nicht zwangsläufig verhindert.

Betroffene Versionen und Patch

Eine Quellcodeanalyse führt die fehlerhafte Alias-Deklaration auf Mozilla Bug 1995077 zurück. Diese Programmänderung wurde mit Firefox 147 eingeführt. Sie war noch in Firefox 151.0.2 enthalten und wurde erst mit Version 151.0.3 entfernt. Betroffen sind daher voraussichtlich alle regulären Firefox-Versionen von 147 bis einschließlich 151.0.2. Firefox ESR wird im Mozilla-Advisory nicht als verwundbar aufgeführt; in Firefox ESR 140.12 war die fehlerhafte Überschreibung der vorliegenden Analyse zufolge nicht enthalten.

Mozilla entfernte mit dem Patch die spezielle Read-only-Aliasbehandlung aus ObjectToIterator und passte die zugehörige Iteratoroperation an. Dadurch erkennt der Optimierer den Vorgang nicht mehr als folgenlosen Lesezugriff und darf den alten Speicherzeiger nicht weiterverwenden.

Nutzer sollten Firefox und den Tor Browser umgehend auf die jeweils aktuelle Version aktualisieren. Das Update schließt den dokumentierten Einstieg über den Browser. Die separate Kernel-Lücke GhostLock wird dadurch jedoch nicht beseitigt und erfordert einen eigenen Betriebssystem-Patch.

Bis zum 28. Juli 2026 gab es in den verfügbaren Primärquellen keine bestätigten Hinweise darauf, dass CVE-2026-10702 bereits aktiv gegen Nutzer eingesetzt wurde. Die Veröffentlichung einer vollständigen Exploit-Grundlage erhöht jedoch das Risiko, dass Angreifer die Technik analysieren und auf weitere Plattformen oder Softwareversionen übertragen.

Zusammenhang von Firefox und Tor

Der Tor Browser basiert auf Firefox, genauer auf dem “Extended Support Release” (Firefox ESR) – das Tor Project übernimmt den Firefox-Quellcode und ergänzt beziehungsweise verändert ihn unter anderem für die Verbindung über das Tor-Netzwerk, den Schutz vor Browser-Fingerprinting, Einschränkungen für Cookies, Skripte und andere Tracking-Techniken, einheitliche Browsermerkmale für möglichst viele Nutzer sowie zusätzliche Sicherheits- und Datenschutzfunktionen. Der Tor Browser ist also kein völlig eigenständiger Browser, sondern eine stark gehärtete und für Anonymität angepasste Firefox-Variante.

Auf dieser Basis können Firefox-Schwachstellen grundsätzlich auch den Tor-Browser betreffen – Voraussetzung ist lediglich, dass die jeweilige Tor-Version auch den fehlerhaften Programmcode enthält. Das Tor Project verändert und erweitert Firefox jedoch an vielen Stellen. Dadurch kann eine Schwachstelle im Tor Browser unter Umständen nicht funktionieren oder sich anders ausnutzen lassen als im normalen Firefox.