Zwei kritische Lücken in Wasmtime erlauben Ausbruch aus der WebAssembly-Sandbox

CVE-2026-115889 betrifft Wasmtime auf allen Prozessorarchitekturen, CVE-2026-115893 nur ARM64 (aarch64). Voraussetzung für einen Angriff ist in beiden Fällen, dass eine verwundbare Wasmtime-Installation ein vom Angreifer kontrolliertes Modul übersetzt. Die Sandbox soll ein Modul innerhalb fester Grenzen halten: Es darf nur den eigenen Speicher und die ihm zugewiesenen Host-Funktionen nutzen, und sein Code darf nur an geprüfte Stellen springen.

Besonders betroffen sind damit Dienste, die von Dritten geschriebene Module kompilieren. Fastly etwa gibt an, auf seiner Compute-Plattform Kundencode mit Wasmtime auszuführen. Die Sicherheitshinweise benennen jedoch keine betroffenen Dienste und sagen auch nicht, worauf ein Angreifer nach einem Ausbruch zugreifen könnte. Im Katalog bekannter ausgenutzter Schwachstellen (KEV) der US-Behörde CISA war mit Stand 26. Oktober keine der beiden Lücken verzeichnet.

Betroffene Versionen

Wasmtime pflegt LTS-Ausgaben, deren Nummern Vielfache von 12 sind, zwei Jahre lang; andere Releases erhalten zwei Monate Pflege. Sicherheitsfixes sind nur für unterstützte Releases zugesichert. Unterstützt werden derzeit allein die Linien 36, 48, 49 und 50. Alle anderen Linien, darunter die LTS-Linie 24.x, deren Pflege am 20. August 2026 endete, erhielten keinen Fix.

ARM64-Hosts, die im April auf 36.0.7, 42.0.2 oder 43.0.1 aktualisiert hatten, um einen früheren Cranelift-Sandbox-Ausbruch auf ARM64 zu beheben, sind von CVE-2026-115893 weiterhin betroffen.

Maßnahmen

Verfügbar sind die korrigierten Ausgaben 36.0.19, 48.0.7 und 49.0.4. Das am 20. Oktober erschienene Wasmtime 50.0.0 behebt beide Fehler. Wer eine nicht mehr unterstützte Linie einsetzt, muss auf eine dieser Ausgaben wechseln.

Da Wasmtime als Bibliothek in andere Programme eingebaut werden kann, genügt ein Update des Kommandozeilenwerkzeugs nicht: Jedes Programm, das Wasmtime enthält, muss mit einer fehlerbereinigten Version neu gebaut werden. Einen Workaround nennt keiner der beiden Hinweise. Bis ein Host aktualisiert ist, geht das Risiko von jedem Modul aus, das von außen zugeliefert werden kann.

Beide Lücken sind in RustSec geführt, der Datenbank, die das Werkzeug cargo-audit zur Prüfung von Cargo.lock-Dateien nutzt – als RUSTSEC-2026-0380 und RUSTSEC-2026-0379. In GitHubs Advisory-Datenbank gab es mit Stand 26. Oktober einen geprüften Eintrag zu CVE-2026-115889, aber keinen zu CVE-2026-115893. Da laut GitHub nur geprüfte Einträge Dependabot-Warnungen auslösen, ist für die ARM64-Lücke keine Dependabot-Meldung zu erwarten.

Spin, ein quelloffenes Werkzeug zum Bau serverloser WebAssembly-Anwendungen auf Basis von Wasmtime, ist in Version 4.2.4 am 21. Oktober auf Wasmtime 50.0.0 umgestiegen.

Technischer Hintergrund

CVE-2026-115889 geht darauf zurück, wie Cranelift die Nummern speicherte, mit denen es Werte innerhalb einer Funktion verfolgt. Vor Version 43 packte der Compiler diese Nummern in 24-Bit-Felder; in Release-Builds lief eine zu große Nummer ohne jede Fehlermeldung über. Cranelift konnte sich dann auf den falschen Wert beziehen und fehlerhaften Maschinencode erzeugen. Eine sehr große WebAssembly-Funktion oder eine gezielt mit vielen Werten konstruierte Funktion lässt sich laut Sicherheitshinweis nutzen, um Typverwirrung zu erzwingen und aus der Sandbox auszubrechen.

In der Hauptentwicklungslinie war das Problem bereits beseitigt: Eine am 18. Februar eingepflegte Änderung verbreiterte die Felder auf 32 Bit und wurde am 20. März mit Wasmtime 43.0.0 ausgeliefert. Ihre Beschreibung stellte sie als Möglichkeit dar, größere Funktionen zu übersetzen, und erwähnte keinen Sicherheitsbezug. Die LTS-Linie 36.x erhielt dieselbe Änderung am 19. Oktober. Wann die Sicherheitsrelevanz erkannt wurde, sagt der Hinweis nicht.

CVE-2026-115893 betrifft br_table, eine WebAssembly-Instruktion, die anhand eines Index an eine von vielen Stellen im Code springt. Ein Index außerhalb der Tabelle führt zum Standardziel. Auf ARM64 leitete Cranelift solche Indizes mit einem Sprungbefehl zum Standardziel, der nur rund 1 MiB weit reicht. Eine br_table mit mehr als etwa 256.000 Zielen machte die Sprungtabelle zu groß für diese Reichweite, sodass der Sprung still auf die falsche Stelle zeigte.

Jede Wasmtime-Engine auf ARM64 mit Standardeinstellungen „kann durch ein benutzerkontrolliertes Wasm-Modul dazu gebracht werden, zu beliebigem Code zu springen", heißt es im Sicherheitshinweis. Der Fehler besteht, seit Wasmtime 2020 erstmals ARM64 unterstützte. Der Fix leitet außerhalb des Bereichs liegende Indizes über die Sprungtabelle selbst, sodass kein weiter Sprung nötig ist. Zusätzlich verweigern die korrigierten Versionen die Übersetzung einer br_table mit mehr als 65.520 Zielen.