#Linux & Open Source · 4 Min. Lesezeit · Tim Rinkel

SANDBOX-AUSBRUCH! Zwei kritische Wasmtime-Lücken (CVSS 9,9) lassen bösartige WebAssembly-Module ausbrechen — jetzt neu bauen

SANDBOX-AUSBRUCH! Zwei kritische Wasmtime-Lücken (CVSS 9,9) lassen bösartige WebAssembly-Module ausbrechen — jetzt neu bauen

Wenn du fremden WebAssembly-Code in Wasmtime laufen lässt, solltest du jetzt handeln. The Hacker News berichtet am 26. Oktober 2026 über zwei kritische Fehler im Compiler Cranelift, den Wasmtime nutzt. Beide haben die Höchstnote CVSS 9,9. Die Fixes erschienen bereits am 19. und 20. Oktober, die Advisories am 19. Oktober.

LÜCKE 1: CVE-2026-115889 — ÜBERLAUF IM COMPILER

Cranelift speicherte Wertnummern in 24-Bit-Feldern. In Release-Builds lief ein zu großer Wert ohne Fehlermeldung über. Die Folge: falscher Maschinencode. Betroffen sind alle Architekturen und die Versionen vor 36.0.19 (inklusive 24.x) sowie 37.0.0 bis 42.x. Für diese CVE nicht betroffen sind 43.0.0 bis 47.x, 48.0.0 bis 48.0.6 und 49.0.0 bis 49.0.3.

LÜCKE 2: CVE-2026-115893 — NUR ARM64, ABER TÜCKISCH

Bei der Anweisung br_table leitete Cranelift ungültige Indizes über einen Sprung mit begrenzter Reichweite von etwa 1 MiB. Bei mehr als rund 256.000 Zielen zeigte der Sprung ins Leere oder an falsche Stellen. Das betrifft nur ARM64 (aarch64), dafür aber mehr Versionen: vor 36.0.19, 37.0.0 bis 42.x, 43.0.0 bis 47.x, 48.0.0 bis 48.0.6 und 49.0.0 bis 49.0.3. Die Lücke besteht laut Advisory seit der ARM64-Unterstützung im Jahr 2020.

Achtung: Auch wer im April auf 36.0.7, 42.0.2 oder 43.0.1 aktualisiert hat, ist für diese Lücke weiterhin betroffen.

DIE FIXES

  • Gefixte Versionen: 36.0.19, 48.0.7, 49.0.4 und 50.0.0.
  • Unterstützte Linien: nur 36, 48, 49 und 50. Die LTS-Linie 24.x lief am 20. August 2026 aus und bekommt keinen Fix.
  • Härtung: Die neuen Versionen lehnen br_table mit mehr als 65.520 Zielen ab.
  • Kein Workaround: Die Advisories nennen keinen. Das Risiko besteht bei jedem Modul, das ein Angreifer liefern kann.

CLI-UPDATE REICHT NICHT

Wer nur das Kommandozeilenwerkzeug aktualisiert, hat sein Programm noch nicht gesichert. Anwendungen, die Wasmtime als Bibliothek einbinden, müssen neu gebaut werden. Als Beispiel für Plattformen, die Kundencode mit Wasmtime ausführen, nennt der Artikel Fastly Compute. Das Spin-Framework wechselte am 21. Oktober mit Version 4.2.4 auf Wasmtime 50.0.0.

KEIN ALARM FÜR DEN NORMALEN HOMELAB-BETRIEB

Die Maintainer melden keine Angriffe, und keine der beiden CVEs stand am 26. Oktober im CISA-KEV-Katalog. Gefährdet bist du vor allem, wenn du Module aus nicht vertrauenswürdigen Quellen ausführst. Wer nur eigenen Code laufen lässt, hat ein geringeres Risiko, sollte aber trotzdem patchen. Ein Stolperstein: Für CVE-2026-115889 gibt es einen geprüften Eintrag in der GitHub-Advisory-Datenbank, für CVE-2026-115893 nicht — Dependabot warnt daher nur bei der ersten. Verlass dich nicht allein auf automatische Warnungen.

Häufige Fragen

Bin ich betroffen, wenn ich Wasmtime nur lokal nutze?
Das hängt davon ab, welchen Code du ausführst. Das Risiko entsteht, wenn ein Angreifer ein Modul liefern kann, das Wasmtime kompiliert. Eigener, vertrauenswürdiger Code ist weniger kritisch. Prüfe trotzdem deine Version mit „wasmtime –version“ und aktualisiere auf eine gefixte Linie, damit du später keine Altlast mitschleppst.
Gibt es einen Workaround ohne Update?
Nein. Die Advisories nennen keinen. Bis zum Update besteht das Risiko bei jedem Modul, das ein Angreifer bereitstellen kann. Wer nicht sofort patchen kann, sollte keine fremden Module ausführen und die Ausführung auf vertrauenswürdige, geprüfte Quellen beschränken.
Was ist mit Wasmtime 24.x?
Die LTS-Linie 24.x ist laut Bericht seit dem 20. August 2026 nicht mehr unterstützt und erhält keinen Fix. Wer sie nutzt, muss auf eine unterstützte Linie wechseln. Das sind 36, 48, 49 oder 50. Plane den Wechsel inklusive Tests, da zwischen den Linien API-Änderungen liegen können.
Warum muss ich neu bauen?
Wasmtime lässt sich als Bibliothek in eigene Programme einbinden. Der verwundbare Compiler steckt dann in deiner Binärdatei. Ein Update des CLI-Tools ändert daran nichts. Hebe die Abhängigkeit auf eine gefixte Version an und baue und verteile dein Programm neu.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert