Dwie krytyczne luki w Wasmtime umożliwiają ucieczkę z sandboxa WebAssembly - Security Bez Tabu

Dwie krytyczne luki w Wasmtime umożliwiają ucieczkę z sandboxa WebAssembly

Cybersecurity news

Wprowadzenie do problemu / definicja

Wasmtime to popularne środowisko uruchomieniowe WebAssembly wykorzystywane poza przeglądarką, m.in. w aplikacjach serwerowych, środowiskach edge oraz systemach uruchamiania rozszerzeń. Ujawnione dwie krytyczne podatności pokazują, że nawet silny model izolacji może zostać przełamany, jeśli błąd pojawi się w warstwie kompilatora generującego kod maszynowy.

W praktyce oznacza to, że złośliwie przygotowany moduł WebAssembly może opuścić granice sandboxa i wpłynąć na proces hosta. To szczególnie groźny scenariusz w usługach, które uruchamiają kod dostarczany przez klientów, partnerów lub użytkowników końcowych.

W skrócie

Podatności oznaczone jako CVE-2026-115889 oraz CVE-2026-115893 dotyczą silnika Wasmtime i jego domyślnego backendu kompilacyjnego Cranelift. Obie otrzymały ocenę 9.9 w skali CVSS, co klasyfikuje je jako luki krytyczne.

  • CVE-2026-115889 wpływa na wszystkie architektury procesorów.
  • CVE-2026-115893 dotyczy wyłącznie platform ARM64.
  • Scenariusz ataku zakłada dostarczenie kontrolowanego modułu Wasm do podatnego hosta.
  • Poprawki opublikowano w wersjach 36.0.19, 48.0.7, 49.0.4 oraz 50.0.0.

Kontekst / historia

Znaczenie Wasmtime rośnie wraz z popularyzacją WebAssembly jako lekkiego mechanizmu izolacji dla obciążeń backendowych i edge computing. W takim modelu bezpieczeństwo zależy nie tylko od samego formatu Wasm, ale też od poprawności walidacji, runtime’u i procesu generowania kodu natywnego.

Obie luki znajdują się w Cranelift, czyli kompilatorze JIT/AOT używanym przez Wasmtime do translacji modułów WebAssembly na instrukcje maszynowe. To sprawia, że problem ma charakter infrastrukturalny, a nie aplikacyjny. Błąd nie wynika z logiki biznesowej hosta, lecz z wadliwej implementacji komponentu odpowiedzialnego za wykonywanie kodu.

Dodatkowym wyzwaniem jest fakt, że starsze linie wydań nie muszą być już wspierane. W środowiskach produkcyjnych może to oznaczać konieczność migracji do nowszych wersji, a nie jedynie wdrożenia standardowej poprawki bezpieczeństwa.

Analiza techniczna

CVE-2026-115889 dotyczy sposobu przechowywania identyfikatorów używanych przez Cranelift do śledzenia wartości wewnątrz funkcji. W starszych wersjach wykorzystywano pola 24-bitowe. W buildach produkcyjnych mogło dojść do cichego przepełnienia, skutkującego błędnym odwzorowaniem wartości i wygenerowaniem nieprawidłowego kodu maszynowego.

W konsekwencji odpowiednio spreparowana, bardzo duża funkcja WebAssembly mogła doprowadzić do type confusion i naruszenia założeń izolacji sandboxa. To szczególnie niebezpieczne, ponieważ źródłem problemu nie jest sam moduł Wasm jako taki, lecz sposób, w jaki host tłumaczy go na kod wykonywany przez procesor.

CVE-2026-115893 ma odmienny charakter i obejmuje wyłącznie architekturę ARM64. Problem występuje przy instrukcji br_table, odpowiedzialnej za realizację skoku do jednego z wielu celów na podstawie indeksu. W określonych warunkach, przy bardzo dużej tablicy skoków, obsługa indeksów spoza zakresu mogła skierować wykonanie do nieprawidłowego miejsca.

Efektem mogło być wymuszenie skoku do arbitralnego kodu, co bezpośrednio narusza model bezpieczeństwa środowiska uruchomieniowego. W praktyce atakujący musi dostarczyć własny moduł Wasm do hosta korzystającego z podatnej wersji Wasmtime, ale w wielu nowoczesnych platformach taki scenariusz jest realistyczny.

Ważny jest również aspekt operacyjny. Sama aktualizacja narzędzia Wasmtime nie wystarczy, jeśli silnik został osadzony jako biblioteka w innym produkcie. W takiej sytuacji konieczne jest przebudowanie oraz ponowne wdrożenie zależnych aplikacji i binariów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem obu luk jest możliwość ucieczki z sandboxa WebAssembly. To z kolei może prowadzić do przejęcia kontroli nad procesem hosta, naruszenia integralności wykonywania kodu, dostępu do pamięci lub funkcji hosta, a także do dalszego ruchu bocznego w środowisku.

Ryzyko jest szczególnie wysokie dla organizacji, które opierają swoje usługi na wykonywaniu nie w pełni zaufanych modułów Wasm.

  • Platformy uruchamiające moduły klientów
  • Rozwiązania serverless oparte na Wasm
  • Usługi edge i CDN wykorzystujące Wasmtime
  • Systemy pluginów i rozszerzeń bazujące na WebAssembly
  • Środowiska ARM64, gdzie dodatkowo występuje CVE-2026-115893

Organizacje powinny ocenić zarówno bezpośrednie użycie Wasmtime, jak i zależności pośrednie. Luka może pozostawać aktywna mimo pozornie aktualnego środowiska systemowego, jeśli podatny komponent jest osadzony w bibliotece lub aplikacji, która nie została przebudowana po aktualizacji.

Rekomendacje

W pierwszej kolejności warto zidentyfikować wszystkie systemy korzystające z Wasmtime oraz Cranelift, zarówno bezpośrednio, jak i poprzez zależności projektowe. Następnie należy ustalić, czy środowisko kompiluje lub uruchamia moduły WebAssembly pochodzące od użytkowników, klientów albo niezweryfikowanych procesów wewnętrznych.

  • Zaktualizować Wasmtime do wersji naprawionych: 36.0.19, 48.0.7, 49.0.4 lub 50.0.0
  • Na niewspieranych liniach wydań przeprowadzić migrację do wspieranej wersji
  • Przebudować wszystkie aplikacje osadzające Wasmtime jako bibliotekę
  • Przeprowadzić audyt środowisk ARM64 pod kątem obecności CVE-2026-115893
  • Ograniczyć lub czasowo wstrzymać wykonywanie modułów Wasm pochodzących od podmiotów zewnętrznych do czasu pełnej remediacji
  • Dodać kontrolę zależności w pipeline CI/CD, w tym skanowanie plików Cargo.lock i monitoring wpisów RustSec
  • Zweryfikować, czy obrazy kontenerowe i systemy produkcyjne zawierają rzeczywiście przebudowane binaria

W środowiskach wysokiego ryzyka warto wdrożyć dodatkowe mechanizmy kompensacyjne, takie jak uruchamianie hostów Wasm w odseparowanych kontenerach, maszynach wirtualnych lub z dodatkowymi ograniczeniami systemowymi. Nie zastępuje to aktualizacji, ale może ograniczyć skutki udanej eksploatacji.

Podsumowanie

Dwie krytyczne luki w Wasmtime przypominają, że bezpieczeństwo WebAssembly nie kończy się na samym modelu sandboxa. Kluczowe znaczenie ma również poprawność działania runtime’u i kompilatora odpowiedzialnego za generowanie kodu wykonywanego przez procesor.

CVE-2026-115889 oraz CVE-2026-115893 stwarzają realne ryzyko ucieczki z izolacji, szczególnie w usługach uruchamiających nieufne moduły Wasm. Organizacje korzystające z Wasmtime powinny potraktować aktualizację jako działanie priorytetowe i upewnić się, że obejmuje ona także wszystkie osadzone zależności oraz przebudowę binariów produkcyjnych.

Źródła

  1. Two Critical Wasmtime Flaws Could Let Malicious WebAssembly Modules Escape Sandboxes
  2. RUSTSEC-2026-0380: wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation
  3. RUSTSEC-2026-0379: wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm br_table instruction
  4. Tiers of Support in Wasmtime