Wasmtime wordt steeds vaker ingebouwd in software die WebAssembly-modules uitvoert buiten de browser. Juist daarom vraagt een Wasmtime sandbox lek om snelle aandacht: twee kritieke kwetsbaarheden in de Cranelift-compiler kunnen een kwaadwillende module in staat stellen om uit de bedoelde afscherming te ontsnappen.
De ontwikkelaars melden dat er op het moment van de publicatie geen gerapporteerde aanvallen bekend waren. Toch is de impact potentieel groot, omdat het risico het hoogst is bij diensten die code van derden compileren of verwerken met een kwetsbare Wasmtime-versie.
Wat is het Wasmtime sandbox lek en waarom is het belangrijk?
Wasmtime is een WebAssembly-runtime die je als bibliotheek in andere programma’s kunt opnemen. De kern van het probleem zit in Cranelift, de compiler die Wasmtime standaard gebruikt om WebAssembly naar machinecode om te zetten.
De sandbox-idee is eenvoudig: een module mag alleen binnen vooraf ingestelde grenzen opereren. Concreet gaat het om beperkingen op toegang tot eigen geheugen, hostfuncties die je expliciet aanbiedt, en gecontroleerde sprongen binnen het gegenereerde codepad.
Volgens de advisories kunnen de twee bugs de bescherming ondermijnen. Met een module die de aanvaller zelf controleert, kan de uitvoering mogelijk niet meer correct binnen de sandbox blijven.
De twee kritieke CVE’s: wat ze doen
De onderzoekers benoemen twee kwetsbaarheden, met een opvallend verschil: één geldt breed voor meerdere processorarchitecturen, de andere specifiek voor ARM64.
- CVE-2026-115889: beïnvloedt Wasmtime op alle processorarchitecturen. Bytecode Alliance beoordeelt de ernst met een hoge score (9.9/10 op CVSS).
- CVE-2026-115893: beperkt tot ARM64 (ook wel aarch64). Ook hier geldt de hoge CVSS-score (9.9/10).
Hoe CVE-2026-115889 werkt
Deze bug komt voort uit de manier waarop Cranelift getallen bijhoudt om waarden in functies te representeren. In versies vóór 43 werden deze nummers in 24-bit velden gepakt. In release-builds kan een te groot getal door een overflow zonder foutmelding in verkeerde waarden veranderen.
Daardoor kan de compiler verwijzen naar het verkeerde getal, wat leidt tot incorrecte machinecode. Een aanvaller kan dit volgens de advisory uitbuiten met een WebAssembly-functie die extreem groot is of juist is ontworpen om veel interne waarden te manipuleren, met als doel typeverwarring en uiteindelijk sandbox-escape.
Hoe CVE-2026-115893 werkt (ARM64)
Deze kwetsbaarheid draait om de WebAssembly-instructie br_table. Daarmee springt de runtime op basis van een index naar één van meerdere bestemmingen; als de index niet klopt, gaat hij naar een standaardtarget.
Op ARM64 kan Cranelift out-of-range indexwaarden volgens de advisory afhandelen via een sprong die alleen tot een beperkt bereik reikt. Als de br_table te veel targets bevat (ruim boven een orde van grootte van 256.000), wordt de interne tabel te groot en wijst de code stilzwijgend naar een verkeerde plek.
De advisory formuleert het scherp: elke Wasmtime-engine op ARM64 met standaardinstellingen kan worden gedwongen tot een sprong naar arbitraire code via een door de gebruiker gecontroleerde Wasm-module.
Waarom het risico hoger is bij services voor derden
Er is een belangrijke beperking: een aanvaller heeft een module nodig die hij zelf controleert. Dat betekent dat het risico vooral groot is bij omgevingen waar niet alleen WebAssembly wordt afgespeeld, maar waar ook code van buitenaf wordt gecompileerd of verwerkt.
Als voorbeeld noemt de melding een compute-platform waar klantcode draait via Wasmtime. Ook zonder de exacte getroffen services te noemen, is de boodschap duidelijk: waar externe modules worden gecompileerd of ingeladen, moet je mitigeren.
De advisories geven geen specifieke details over wat een aanvaller na sandbox-escape precies kan bereiken. Wel maken ze het directe punt duidelijk: de bescherming kan falen.
Welke Wasmtime-versies zijn getroffen?
De fixes zijn op verschillende momenten beschikbaar gekomen. Daardoor hangt “ben je kwetsbaar?” af van je release line én bij één bug van je processorarchitectuur.
Wasmtime heeft ook long-term support (LTS). LTS-releases lopen twee jaar en zijn genummerd in veelvouden van 12. Andere releases krijgen doorgaans slechts twee maanden ondersteuning. Securityfixes gelden alleen voor ondersteunde releases.
Actief ondersteunde release lines zijn volgens de melding nog: 36, 48, 49 en 50. Alle andere lines — inclusief een 24.x LTS die eerder eindigde op 20 augustus 2026 — kregen geen patch.
Concreet: wat moet je nu updaten?
De ontwikkelaars adviseren je Wasmtime te brengen naar een van deze vaste releases:
- 36.0.19
- 48.0.7
- 49.0.4
- 50.0.0 (fix voor beide kwetsbaarheden)
Voor ARM64 geldt bovendien extra context: als je ARM64-hosts in april al naar 36.0.7, 42.0.2 of 43.0.1 had bijgewerkt voor een eerdere sandbox-escape op ARM64, dan kun je nog steeds kwetsbaar zijn voor CVE-2026-115893.
Niet alleen updaten: rebuild kan nodig zijn
Een cruciale valkuil is dat Wasmtime soms niet alleen als los command-line tool draait, maar als bibliotheek is ingebouwd. De melding stelt dat een update van de cli-versie de onderliggende integraties niet automatisch herstelt.
Met andere woorden: elk programma dat Wasmtime meeneemt moet worden gerebuilt met een versie van Wasmtime die al gepatcht is.
Er is bovendien geen workaround opgenomen in de adviezen. Totdat je hosts zijn bijgewerkt en je applicaties opnieuw zijn opgebouwd, blijft het risico bestaan — vooral als een aanvaller in staat is een module aan te leveren.
Wat betekent dit voor je SDLC en supply chain?
Hoewel dit incident technische sandboxing betreft, raakt het ook je ontwikkel- en dependenciestrategie. De kwetsbaarheden staan vermeld in RustSec, bedoeld om Cargo-lock controles te automatiseren via tools zoals cargo-audit. Ze zijn daarnaast gelinkt aan entries die tooling kan oppakken: RUSTSEC-2026-0380 en RUSTSEC-2026-0379.
Daarnaast meldt GitHub dat alleen “reviewed” advisories worden getriggerd voor Dependabot-alerts. Daardoor kan het ARM64-gerelateerde item mogelijk niet zichtbaar zijn in bepaalde automatiseringen, zelfs als je afhankelijkheid wél op dat pad zit.
Om dit soort gaten te verkleinen, helpt het om updates niet uitsluitend op alerts te baseren, maar ook actief je build-artefacten en ingebouwde runtime-componenten te controleren.
Snelle checklist voor mitigatie
- Inventariseer waar Wasmtime wordt gebruikt: alleen hosts, of ook als ingebouwde bibliotheek.
- Check de versie per release line: 36/48/49/50 met de genoemde vaste patches.
- Wees extra alert op ARM64: controleer of je nog kwetsbaar bent voor CVE-2026-115893.
- Rebuild applicaties die Wasmtime als library bevatten; alleen een cli-update is niet voldoende.
- Valideer je deployment: zorg dat de gepatchte artefacten daadwerkelijk draaien in productie.
Vergelijkbare aandachtspunten bij WebAssembly security
Sandboxing is een terugkerend thema in moderne security. Ook in andere contexten zien we dat aanvallen misbruik maken van zwakheden in compilers, vertalers of runtime-logica, met als doel controle buiten de verwachte grenzen te krijgen.
Als je geïnteresseerd bent in hoe verdediging en detectie samenkomen in omgevingen met AI en security-operaties, lees dan ook AI SOC: bewijs tussen alerts voor context. Dat artikel helpt je nadenken over hoe je signalen kunt ordenen wanneer één incident meerdere oorzaken kan hebben.
Conclusie
De Wasmtime sandbox lek draait om twee kritieke Cranelift-kwetsbaarheden die een kwaadaardige WebAssembly-module kunnen helpen ontsnappen aan de sandbox. De fix is beschikbaar: update naar de genoemde vaste releases, en rebuild applicaties waarin Wasmtime als bibliotheek is geïntegreerd.
Omdat er geen workaround is, komt de veiligheid neer op correct patchen en gecontroleerde heruitrol. Zeker als je diensten van derden code compileren of draaien, is dit het soort issue waarvoor je niet kunt wachten.
Bron: https://thehackernews.com/2026/10/two-critical-wasmtime-flaws-could-let.html
