Zwei Wasmtime-Schwachstellen machen den Neuaufbau eingebetteter Apps erforderlich
Zwei kritische Wasmtime-Schwachstellen könnten es einem von Angreifern kontrollierten WebAssembly-Modul ermöglichen, den Beschränkungen zu entkommen, die es isolieren sollen. Wasmtime ist eine runtime, also Software, die WebAssembly-Code außerhalb eines Webbrowsers ausführt, und kann außerdem als Bibliothek in andere Anwendungen eingebettet werden. Die Bytecode Alliance, die das Projekt betreut, bewertete beide Schwachstellen nach dem Common Vulnerability Scoring System (CVSS), einem Standardmaß für den Schweregrad von Sicherheitsproblemen, mit 9,9 von 10 Punkten. Korrigierte Releases erschienen am 19. und 20. Oktober, und die Verantwortlichen haben keine Angriffe gemeldet.
Die Schwachstellen befinden sich in Cranelift, dem standardmäßigen compiler von Wasmtime, der WebAssembly-Module in Anweisungen umwandelt, die ein Prozessor ausführen kann. CVE-2026-115889 betrifft Wasmtime auf jeder Prozessorarchitektur, während CVE-2026-115893 auf ARM64 beschränkt ist, das auch als aarch64 bezeichnet wird. Für eine Ausnutzung muss ein anfälliger Wasmtime-Build ein vom Angreifer kontrolliertes Modul kompilieren. Dadurch sind Dienste, die Module anderer Personen annehmen und kompilieren, den größten Risiken ausgesetzt. Fastly gibt beispielsweise an, dass seine Compute-Plattform Wasmtime zur Ausführung von Kundencode nutzt. Die Sicherheitshinweise nennen jedoch weder betroffene Dienste noch die Bereiche, auf die ein Angreifer nach einem Ausbruch zugreifen könnte.
Eine Wasmtime-sandbox soll ein Modul auf den ihm zugewiesenen Speicher und die von der Anwendung bereitgestellten host functions beziehungsweise genehmigten Funktionen beschränken. Außerdem begrenzt sie die Codeausführung auf geprüfte Ziele. Die beiden Schwachstellen untergraben diese Grenzen während der Kompilierung. Mit Stand vom 26. Oktober war keine der Schwachstellen im Katalog Known Exploited Vulnerabilities der US-amerikanischen Cybersecurity and Infrastructure Security Agency (CISA) aufgeführt.
Die betroffenen Releases unterscheiden sich bei den beiden Schwachstellen. Versionen vor 36.0.19, einschließlich der 24.x-Linie, sind auf ARM64 für beide Probleme und auf anderen Architekturen für CVE-2026-115889 anfällig. Version 36.0.19 behebt beide Schwachstellen. Releases von 37.0.0 bis 42.x sind dort, wo ARM64 zum Einsatz kommt, von beiden Schwachstellen betroffen. Releases von 43.0.0 bis 47.x sind nicht von CVE-2026-115889 betroffen, bleiben jedoch für die ARM64-spezifische Schwachstelle anfällig. Die Versionen 48.0.0 bis 48.0.6 sowie 49.0.0 bis 49.0.3 sind ebenfalls von CVE-2026-115893 betroffen. Die korrigierten Releases sind 36.0.19, 48.0.7, 49.0.4 und 50.0.0 oder höher.
Wasmtime bezeichnet Releases mit Versionsnummern, die ein Vielfaches von 12 sind, als Versionen mit long-term support (LTS) und unterstützt sie zwei Jahre lang. Andere Releases erhalten zwei Monate Support, wobei Sicherheitskorrekturen nur für unterstützte Linien garantiert werden. Zum Zeitpunkt der Sicherheitshinweise wurden nur noch die Linien 36, 48, 49 und 50 unterstützt. Andere Linien erhielten keine Korrektur, darunter der 24.x-LTS-Branch, dessen Support am 20. August 2026 endete. ARM64-Systeme, die im April wegen eines früheren Cranelift-Ausbruchs auf 36.0.7, 42.0.2 oder 43.0.1 aktualisiert wurden, sind weiterhin für CVE-2026-115893 anfällig.
Administratoren sollten je nach verwendeter Release-Linie auf 36.0.19, 48.0.7, 49.0.4 oder 50.0.0 wechseln. Nicht unterstützte Installationen müssen auf einen dieser korrigierten Branches migriert werden. Nur das Wasmtime-Kommandozeilenprogramm zu aktualisieren, reicht nicht aus, wenn eine Anwendung Wasmtime als Bibliothek enthält. Jede betroffene Anwendung muss mit einer korrigierten Version neu gebaut werden. Keiner der Sicherheitshinweise nennt einen Workaround. Daher bleibt jedes von einer externen Partei bereitgestellte Modul eine potenzielle Risikoquelle, bis die betreffende Host-Software aktualisiert und neu gebaut wurde.
CVE-2026-115889 entstand durch die Art und Weise, wie ältere Cranelift-Versionen Kennungen speicherten, mit denen Werte innerhalb einer Funktion verfolgt wurden. Vor Version 43 belegten diese Kennungen 24-Bit-Felder. In Release-Builds konnte eine für dieses Feld zu große Kennung überlaufen, ohne einen Fehler auszulösen. Dadurch konnte Cranelift auf den falschen Wert verweisen und fehlerhaften Maschinencode erzeugen. Laut Sicherheitshinweis konnte eine sehr große WebAssembly-Funktion oder eine absichtlich so konstruierte Funktion, dass sie zahlreiche Werte erzeugt, type confusion auslösen und aus der sandbox ausbrechen.
In der Hauptentwicklungslinie von Wasmtime war diese Bedingung bereits entfernt worden, bevor ihre Sicherheitsauswirkungen dokumentiert wurden. Eine am 18. Februar zusammengeführte Änderung erweiterte die betroffenen Felder auf 32 Bit und wurde am 20. März mit Wasmtime 43.0.0 veröffentlicht. Die Änderung wurde damals als Unterstützung für das Kompilieren größerer Funktionen beschrieben, ohne einen Sicherheitsaspekt zu erwähnen. Der 36.x-LTS-Branch erhielt dieselbe Änderung am 19. Oktober. Der Sicherheitshinweis gibt nicht an, wann die Verantwortlichen die Sicherheitsauswirkungen erkannten.
CVE-2026-115893 betrifft br_table, eine WebAssembly-Anweisung, die anhand eines Index eines von vielen Codezielen auswählt und ein Standardziel verwendet, wenn der Index außerhalb der Tabelle liegt. Auf ARM64 verarbeitete Cranelift einen außerhalb des zulässigen Bereichs liegenden Index mit einem Sprung, der nur eine Entfernung von etwa 1 MiB erreichen konnte. Eine br_table mit mehr als ungefähr 256.000 Zielen konnte für diese Reichweite zu groß werden, wodurch der Sprung unbemerkt auf die falsche Stelle zeigte. Die Verantwortlichen erklären, dass ein benutzergesteuertes Modul diesen Zustand nutzen könnte, um eine standardmäßige Wasmtime-engine auf ARM64 zu beliebigem Code springen zu lassen. Die Schwachstelle bestand seit Einführung der ARM64-Unterstützung im Jahr 2020. Die Korrektur leitet außerhalb des zulässigen Bereichs liegende Indizes durch die jump table selbst und weist eine br_table mit mehr als 65.520 Zielen zurück.
Beide Schwachstellen sind in RustSec, der von cargo-audit zur Prüfung von Cargo.lock-Abhängigkeitsdateien verwendeten Sicherheitsdatenbank, als RUSTSEC-2026-0380 und RUSTSEC-2026-0379 verzeichnet. Mit Stand vom 26. Oktober enthielt die Sicherheitsdatenbank von GitHub einen geprüften Eintrag für CVE-2026-115889, jedoch keinen geprüften Eintrag für CVE-2026-115893. Da GitHub angibt, dass Dependabot-Warnungen einen geprüften Eintrag voraussetzen, sollten Nutzer zu diesem Zeitpunkt nicht damit rechnen, über die ARM64-Schwachstelle benachrichtigt zu werden. Spin, ein Open-Source-Werkzeug für serverlose WebAssembly-Anwendungen, übernahm Wasmtime 50.0.0 am 21. Oktober in Version 4.2.4.
Betreiber von Websites und Cloud-Anwendungen sollten daher sowohl direkte Wasmtime-Installationen als auch Software prüfen, welche die runtime einbettet. Besondere Aufmerksamkeit sollte dabei ARM64-Hosts und nicht unterstützten Release-Linien gelten. Organisationen, die Unterstützung bei der Überprüfung ihrer Technologieumgebung benötigen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen. Die entscheidende Abhilfemaßnahme bleibt die Installation eines korrigierten Wasmtime-Release und der Neuaufbau jeder Anwendung, die die anfällige Bibliothek enthält.