Kritische Wasmtime-Sandbox-Entweichungen in neuesten Versionen behoben

Die Maintainer der Wasmtime-WebAssembly-Laufzeitumgebung haben am 19. und 20. Oktober 2026 dringende Sicherheitspatches veröffentlicht, um zwei kritische Schwachstellen zu beheben. Diese Fehler, die auf der CVSS-Skala mit 9,9 von 10 Punkten bewertet wurden, könnten es einem bösartigen Modul ermöglichen, seine Sandbox zu verlassen und beliebigen Code auf dem Hostsystem auszuführen.

Was passiert ist

Die Bytecode Alliance, die Wasmtime pflegt, identifizierte zwei separate Fehler in Cranelift, dem Standardcompiler zur Übersetzung von WebAssembly in Maschinencode. Die erste Schwachstelle, verfolgt als CVE-2026-115889, betrifft Wasmtime-Installationen auf allen Prozessorarchitekturen. Die zweite, CVE-2026-115893, ist spezifisch für ARM64-(aarch64-)Systeme. Beide Probleme erlauben einen Sandbox-Ausbruch, wenn ein Angreifer ein präpariertes WebAssembly-Modul an eine verwundbare Laufzeitumgebung liefern kann.

Das Risiko ist am höchsten für Plattformen, die benutzerdefinierten Code kompilieren und ausführen, wie etwa serverlose Compute-Umgebungen. Dienste wie die Fastly-Compute-Plattform verlassen sich beispielsweise auf Wasmtime, um den Kundencode zu isolieren. Obwohl die Warnungen keine konkreten Opfer nennen oder Details zum Zugriff nach einer Kompromittierung angeben, ist das Potenzial für eine vollständige Host-Kompromittierung schwerwiegend. Stand 26. Oktober wurden keine aktiven Exploits gemeldet, und keiner der beiden Fehler erscheint im CISA-Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities).

Der Supportstatus spielt eine entscheidende Rolle für die Exposition. Nur die Release-Zweige 36, 48, 49 und 50 erhalten derzeit Sicherheitsupdates. Ältere Zweige, einschließlich des 24.x-LTS-Zweigs, dessen Support am 20. August 2026 endete, werden keine Korrekturen mehr erhalten. Benutzer auf nicht unterstützten Versionen müssen auf einen unterstützten Zweig aktualisieren, um diese Risiken zu mindern.

Wie es funktioniert

CVE-2026-115889 resultiert aus einem Ganzzahlüberlauf bei der Verfolgung von Werten innerhalb einer Funktion durch Cranelift. In Versionen vor 43.0.0 speicherte der Compiler diese Tracking-Nummern in 24-Bit-Feldern. Wenn eine Funktion groß oder komplex genug war, um dieses Limit zu überschreiten, lief der Wert in Release-Builds stillschweigend über. Dies führte dazu, dass Cranelift falsche Werte referenzierte, was zu Typverwirrung und generiertem Maschinencode führte, der die Sandbox-Einschränkungen verletzte. Der Fix erweitert diese Felder auf 32 Bit, eine Änderung, die ursprünglich im Februar aus Leistungsgründen zusammengeführt wurde, aber am 19. Oktober aus Sicherheitsgründen auf den 36.x-LTS-Zweig zurückportiert wurde.

Der ARM64-spezifische Fehler, CVE-2026-115893, betrifft die br_table-Anweisung, die Multi-Way-Branches behandelt. Wenn ein Index außerhalb des Tabellenbereichs liegt, springt die Laufzeitumgebung zu einem Standardziel. Auf ARM64 implementierte Cranelift dies unter Verwendung einer Branch-Anweisung mit einer begrenzten Reichweite von etwa 1 MiB. Wenn eine br_table mehr als ungefähr 256.000 Ziele enthielt, überschritt die Sprungtabelle diesen Bereich, wodurch der Branch auf eine unbeabsichtigte Speicheradresse zeigte. Dies ermöglichte es einem präparierten Modul, die Ausführung zu beliebigem Code umzuleiten. Der Patch ändert den Kontrollfluss so, dass Indizes außerhalb des Bereichs über die Sprungtabelle selbst geleitet werden, und begrenzt die Größe von br_table auf 65.520 Ziele.

Wichtige Details

• CVE-2026-115889 betrifft alle Architekturen; CVE-2026-115893 betrifft nur ARM64-Systeme.
• Beide Schwachstellen tragen einen CVSS-Score von 9,9, was eine kritische Schweregradstufe anzeigt.
• Behobene Versionen umfassen 36.0.19, 48.0.7, 49.0.4 und 50.0.0.
• Der 24.x-LTS-Zweig wird nicht unterstützt und erhielt keinen Patch; Benutzer müssen migrieren.
• Dependabot alarmiert möglicherweise nicht für den ARM64-Fehler, da GitHub keinen geprüften Eintrag dafür hat.
• Die Spin-Framework-Version 4.2.4 wurde am 21. Oktober auf Wasmtime 50.0.0 aktualisiert.

Warum es wichtig ist

Für Ingenieure, die Plattformen erstellen, die nicht vertrauenswürdigen WebAssembly-Code ausführen, stellen diese Bugs ein grundlegendes Versagen der Isolation dar. Das Sandboxing ist der primäre Verteidigungsmechanismus in solchen Architekturen. Wenn ein Modul entweichen kann, erhält es die Berechtigungen des Host-Prozesses, was potenziell Datenexfiltration, laterale Bewegung oder Dienstunterbrechungen ermöglicht. Die Tatsache, dass ein Bug seit 2020 existierte, unterstreicht die Schwierigkeit, Low-Level-Compiler-Logik zu auditieren, insbesondere bei architekturspezifischen Edge-Cases.

Darüber hinaus kann die Abhängigkeit von automatisierten Tools wie Dependabot ein falsches Sicherheitsgefühl vermitteln. Da GitHub geprüfte Einträge erfordert, um Alarme auszulösen, und der ARM64-Fehler Ende Oktober keinen solchen Eintrag hatte, könnten einige Teams ihre Exposition weiterhin nicht kennen. Dies unterstreicht die Notwendigkeit einer manuellen Überprüfung der Abhängigkeitsbäume gegen offizielle Anbieterwarnungen, insbesondere für kritische Infrastrukturkomponenten wie Laufzeitumgebungen.

Was Sie tun können

• Identifizieren Sie Ihre aktuelle Wasmtime-Version und prüfen Sie, ob sie in die betroffenen Bereiche fällt, die in der Warnung aufgelistet sind.
• Aktualisieren Sie auf 36.0.19, 48.0.7, 49.0.4 oder 50.0.0, abhängig von Ihrem Release-Zweig.
• Wenn Sie Wasmtime als Bibliothek verwenden, bauen Sie Ihre Anwendung mit der gepatchten Version neu; das Update des CLI-Tools reicht nicht aus.
• Migrieren Sie weg von nicht unterstützten Release-Zweigen wie 24.x, da sie zukünftige Sicherheitskorrekturen nicht mehr erhalten.
• Führen Sie cargo-audit aus, um RUSTSEC-2026-0380 und RUSTSEC-2026-0379 in Ihren Abhängigkeits-Lock-Dateien zu überprüfen.
• Überwachen Sie Updates von nachgelagerten Frameworks wie Spin, wenn Sie Wasmtime nicht direkt verwalten.