Évasion du bac à sable Wasmtime par compilation incorrecte (CVE-2026-115889)

En bref

• Wasmtime compile WebAssembly avec Cranelift, son propre backend de compilation. Dans la représentation intermédiaire du compilateur, chaque enregistrement de valeur stockait un indice d'instruction, de bloc ou de valeur dans 24 bits d'un mot de 64 bits, avec une garde qui ne déclenche une panique que dans les compilations de débogage.
• Une fonction Wasm qui pousse l'un de ces indices d'instruction, de bloc ou de valeur au-delà de 2^24 - 1, soit environ 16.7 millions, fait déborder les champs de 24 bits dans les compilations de production. Il peut s'agir d'une fonction réellement immense ou conçue pour gonfler le nombre d'indices. La valeur référence alors la mauvaise instruction, le mauvais bloc ou la mauvaise valeur. Le compilateur génère du code machine à partir de ces données corrompues. Il peut en résulter une confusion de types, c'est-à-dire une évasion du bac à sable.
• La Bytecode Alliance classe la faille comme critique, CVSS v3.1 9.9, avec le backend Cranelift par défaut affecté sur toutes les architectures. La branche principale est corrigée depuis Wasmtime 43.0.0 (mars 2026) ; la branche de maintenance 36.x a reçu le rétroportage dans 36.0.19, publié le 19 octobre 2026, le même jour que l'avis.
• Installez 36.0.19 ou ultérieur sur la branche 36.x. Sur la branche principale, 43.0.0 ne corrige que CVE-2026-115889 ; pour éliminer les trois failles ci-dessous, utilisez 48.0.7 ou ultérieur, ou 49.0.4 ou ultérieur sur la branche 49. Aucune exploitation dans la nature n'est connue au 24 octobre 2026.
• Deux autres évasions de bac à sable ont été annoncées dans la même période d'octobre. CVE-2026-115893 permet à un br_table comportant plus d'environ 256 000 cibles de sauter vers un décalage choisi par l'attaquant sur aarch64 ; elle est corrigée dans 36.0.19, 48.0.7 et 49.0.4. GHSA-m9f7-9w4p-gv38 permet à un invité de déplacer tout répertoire de l'hôte dans son bac à sable via le renommage d'un lien symbolique sur macOS et FreeBSD ; elle est corrigée dans 36.0.18, 48.0.6 et 49.0.3.

Suis-je concerné ?

Vous êtes concerné si toutes ces conditions sont réunies :

• Vous exécutez Wasmtime, ou un produit qui l'intègre, avec le backend de compilation Cranelift par défaut.
• Votre version est antérieure à 36.0.19 sur la branche de maintenance 36.x, ou comprise entre 37.0.0 et 42.x sur la branche principale.
• Les modules Wasm invités ne sont pas entièrement fiables : ils proviennent de locataires, d'utilisateurs ou d'autres parties dont vous confinez le code plutôt que de lui faire confiance.

L'énoncé d'impact de l'avis est explicite : « Un moteur Wasmtime avec les paramètres par défaut (utilisant le backend Cranelift), sur toute architecture ou plateforme, pourrait subir une évasion de bac à sable depuis un module Wasm spécialement conçu. » Les moteurs qui n'exécutent que des modules internes fiables ne sont pas exposés à cette faille.

La période des avis d'octobre 2026 comprend deux autres évasions de bac à sable avec des plages de versions différentes ; le tableau détaille donc chaque faille séparément :

L'avis aarch64 indique que toutes les versions de Wasmtime prenant en charge aarch64 sont affectées par CVE-2026-115893, jusqu'à la prise en charge initiale de 2020 avant v1.0. L'avis sur le système de fichiers nécessite un invité disposant d'un accès en écriture à un répertoire de son bac à sable et un hôte macOS ou FreeBSD ; Linux et Windows ne sont pas affectés, car leur renameat ne suit pas un lien symbolique terminé par une barre oblique.

Vérifiez ce que vous exécutez :

# CLI version
wasmtime --version

# Rust dependency tree
cargo tree -i wasmtime -e features | head
cargo tree --depth 1 | grep wasmtime

# Docker image check
docker run --rm <your-image> wasmtime --version

Wasmtime est généralement intégré plutôt qu'exécuté comme outil en ligne de commande : vérifiez sa version dans l'arbre des dépendances de votre plateforme, car les plateformes serverless et de plugins la verrouillent souvent.

Comment corriger le problème ?

Mettez Wasmtime à jour. Pour éliminer les trois failles simultanément, les versions corrigées minimales sont 36.0.19 sur la branche 36.x, 48.0.7 sur la branche 48 et 49.0.4 sur la branche 49 :

# Rust, 36.x maintenance line
cargo update -p wasmtime --precise 36.0.19
# Rust, 48 line
cargo update -p wasmtime --precise 48.0.7
# Rust, 49 line
cargo update -p wasmtime --precise 49.0.4

# CLI install script (installs the latest release)
curl https://wasmtime.dev/install.sh -sSf | bash

La version 43.0.0 ne corrige que CVE-2026-115889. Les versions 43.0.0 à 48.0.6 et 49.0.0 à 49.0.3 conservent l'évasion aarch64 via br_table. Les versions 43.0.0 à 48.0.5 et 49.0.0 à 49.0.2 conservent l'évasion du système de fichiers.

L'avis ne propose aucun contournement. Rejeter les corps de fonctions inhabituellement volumineux avant compilation réduit les entrées pouvant atteindre le débordement, mais ne constitue pas un correctif. L'avis distingue une fonction conçue pour utiliser de nombreuses valeurs SSA d'un corps de fonction très volumineux : un plafond en octets n'est donc pas une frontière fiable. Considérez la mise à jour du moteur comme la remédiation et tout plafond comme une mesure provisoire.

Analysez vos dépôts Rust et images de conteneurs avec Ostorlab pour repérer chaque build verrouillant encore une version wasmtime antérieure à 36.0.19, 48.0.7 ou 49.0.4.

Quelle est la cause profonde ?

La représentation intermédiaire de Cranelift suit chaque valeur SSA dans un enregistrement ValueDataPacked. Pour maintenir cet enregistrement à 64 bits, le compilateur regroupait quatre champs dans un mot : une étiquette de 2 bits, un type de 14 bits et deux champs de 24 bits nommés x et y.

Le champ y contient l'indice de l'instruction définissant la valeur, l'indice du bloc ou l'indice de la valeur d'origine pour un alias. Ces indices augmentent avec la taille de la fonction. Pour les résultats d'instructions et les paramètres de blocs, x ne contient que le numéro de sortie ou de paramètre, qui reste petit. Pour une union, un nœud créé par l'optimiseur, les deux champs contiennent des indices de valeurs. Voici l'organisation issue du code affecté :

// cranelift/codegen/src/ir/dfg.rs (before the fix)
//        | tag:2 |  type:14        |    x:24       | y:24          |
//
// Inst       00     ty               inst output     inst index
// Param      01     ty               blockparam num  block index
// Alias      10     ty               0               value index
// Union      11     ty               first value     second value

La fonction de compactage ne protégeait la largeur du champ que par une assertion de débogage, un contrôle supprimé des compilations de production :

// cranelift/codegen/src/ir/dfg.rs (before the fix)
fn encode_narrow_field(x: u32, bits: u8) -> u32 {
    let max = (1 << bits) - 1;
    if x == 0xffff_ffff {
        max
    } else {
        debug_assert!(
            x < max,
            "{x} does not fit into {bits} bits (must be less than {max} to \
             allow for a 0xffffffff sentinel)"
        );
        x
    }
}

Sans l'assertion, encode_narrow_field renvoie l'indice inchangé. Le code de compactage le décale à sa position et l'ajoute au mot par un OU binaire sans masquage : les bits au-delà du 24e débordent donc dans le champ voisin. La relecture de l'enregistrement masque chaque champ à 24 bits. Un indice d'instruction de 2^24 dans y est relu comme 0, une instruction complètement différente, et corrompt également x.

En une phrase : une structure du compilateur stockait des indices d'entités dans des champs trop étroits, et le seul contrôle de débordement était supprimé des compilations de production ; une fonction comportant assez de valeurs corrompait donc la correspondance interne entre valeurs et définitions avant le début de la génération de code.

La conséquence est une compilation incorrecte influencée par l'attaquant. Une Value qui revendique la mauvaise instruction de définition hérite du type de résultat et de la sémantique de cette instruction. Le compilateur émet alors du code machine dans lequel la sortie d'une opération est consommée comme un autre type : une confusion de types dans le code compilé de l'invité, qui brise le bac à sable que Wasmtime doit faire respecter.

Comment la faille est-elle exploitée ?

Un attaquant fournit un module Wasm avec une fonction qui pousse les indices d'instructions, de blocs ou de valeurs de Cranelift au-delà de 2^24 - 1. Dans une compilation de production, les indices débordent silencieusement et le code mal compilé, avec confusion de types, s'exécute avec les privilèges de l'hôte. Aucune preuve de concept publique n'existe et aucune exploitation dans la nature n'est connue au 24 octobre 2026. Voici le chemin, d'après l'avis et le correctif :

1. L'attaquant peut fournir un module Wasm au moteur : un locataire déployant du code, un utilisateur téléversant un plugin, tout auteur de code invité. C'est pourquoi le vecteur CVSS v3.1 indique des privilèges requis faibles.
2. Le module contient une fonction qui pousse un indice d'instruction, de bloc ou de valeur au-delà de 2^24 moins 1, soit environ 16.7 millions. L'avis mentionne deux formes : un corps de fonction Wasm très volumineux ou une fonction spécialement conçue pour utiliser de nombreuses valeurs SSA.
3. Pendant la traduction en représentation intermédiaire Cranelift et l'optimisation, les indices d'instructions, de blocs ou de valeurs dépassent les champs de 24 bits. Dans une compilation de production, aucune panique n'est déclenchée ; les enregistrements compactés désignent silencieusement d'autres indices.
4. L'optimiseur et le backend lisent la correspondance corrompue. Une valeur se résout vers la mauvaise définition, avec le mauvais type, et le code machine généré effectue des opérations que le vérificateur n'a jamais vues : par exemple, des bits d'entier réinterprétés comme une référence ou une valeur d'un autre type.
5. Dans l'invité, l'attaquant utilise le code à confusion de types pour lire ou écrire au-delà des limites de la mémoire linéaire Wasm, ou atteindre des mécanismes de l'hôte que le bac à sable devrait rendre inaccessibles : une évasion de bac à sable, avec les privilèges du processus hôte.

L'attaque entière tient dans un module compilé. Aucun détournement d'API hôte, aucune mauvaise configuration du moteur et aucune seconde vulnérabilité ne sont nécessaires.

Comment un module conçu pour l'attaque passe-t-il du débordement à l'évasion ?

Le contrôle défaillant se situe en C : la seule garde contre le débordement n'existe pas dans les compilations de production.

Que peut faire un attaquant ?

S'échapper du bac à sable WebAssembly et exécuter du code avec les privilèges du processus hôte. Le modèle de sécurité de Wasmtime considère le code invité comme non fiable : une évasion signifie que l'invité accède directement à la mémoire de l'hôte, aux API de l'hôte et aux capacités du processus. Le vecteur CVSS v3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H attribue un impact élevé sur la confidentialité, l'intégrité et la disponibilité avec changement de périmètre, ce qui correspond à un invité compromettant son hôte.

Les conditions nécessaires à l'attaque :

• Wasmtime avec le backend Cranelift par défaut, sur toute architecture, dans une compilation de production.
• Une version affectée : avant 36.0.19 sur la branche 36.x, ou de 37.0.0 à 42.x.
• Le code de l'attaquant doit effectivement être compilé par le moteur : les moteurs qui ne précompilent que des modules fiables ou utilisent un autre backend se trouvent donc hors du chemin démontré.

Quelles sont les deux autres évasions de bac à sable ?

La même période d'avis d'octobre comprend deux autres évasions de bac à sable Wasmtime, publiées les 19 octobre et 14 octobre 2026, avec des versions corrigées différentes de celles de CVE-2026-115889.

CVE-2026-115893 : comment un grand br_table permet-il l'évasion du bac à sable sur aarch64 ?

Sur le backend aarch64, un module Wasm comportant plus d'environ 256 000 cibles dans une instruction br_table est compilé en branchement conditionnel avec une cible incorrecte. Le branchement peut sauter vers du code arbitraire à un décalage contrôlé par le module, ce qui, selon l'avis, permet des évasions arbitraires du bac à sable.

Toutes les versions de Wasmtime prenant en charge aarch64 sont affectées, jusqu'à la prise en charge initiale de 2020 avant v1.0. Le correctif a été livré dans 36.0.19, 48.0.7 et 49.0.4 le 19 octobre 2026. Les versions de la branche principale de 43.0.0 à 48.0.6 corrigent CVE-2026-115889 mais conservent cette faille.

GHSA-m9f7-9w4p-gv38 : comment le renommage d'un lien symbolique permet-il l'évasion du bac à sable du système de fichiers ?

Dans la crate wasmtime-wasi, un invité pouvait déplacer tout répertoire de l'hôte accessible au processus dans son propre bac à sable, puis le lire et y écrire.

Lors d'un renommage, wasmtime-wasi retire la barre oblique finale du chemin source pour résoudre son répertoire parent. Il la rajoute ensuite avant d'appeler renameat. Un invité crée un lien symbolique relatif pointant hors de son bac à sable, par exemple symlink("../outside", "up"), puis renomme "up/" dans le bac à sable. Le noyau hôte suit le lien symbolique et y déplace le répertoire extérieur. Le correctif antérieur GHSA-vqjp-4c8c-hfgg modifiait la manière d'ouvrir les chemins, pas de les renommer.

Les hôtes macOS et FreeBSD sont affectés. Linux et Windows ne le sont pas, car leur renameat ne suit pas un lien symbolique terminé par une barre oblique. L'invité doit disposer d'un accès en écriture à un répertoire de son bac à sable. Le correctif a été livré dans 36.0.18, 48.0.6 et 49.0.3 le 14 octobre 2026. Aucun contournement n'est connu et aucune CVE n'a été attribuée.

Aucun des deux avis associés ne signale d'exploitation dans la nature.

Pourquoi le correctif fonctionne-t-il ?

Le correctif supprime les champs étroits : x et y deviennent des indices u32 complets, de sorte qu'aucune taille de fonction ne puisse faire déborder un indice vers une autre définition. Sur la branche principale, la pull request #12613 (fusionnée le 18 février 2026, livrée dans Wasmtime 43.0.0) a remplacé le u64 compacté par :

// cranelift/codegen/src/ir/dfg.rs (after the fix)
-struct ValueDataPacked(u64);
+#[repr(Rust, packed)]
+struct ValueDataPacked {
+    x: u32,
+    y: u32,
+    flags_and_type: u16,
 }

Le commentaire d'organisation passe de x:24 | y:24 à x:32 | y:32 : les deux champs contiennent désormais toute leur plage u32, et les fonctions encode_narrow_field et decode_narrow_field sont supprimées puisqu'il n'y a plus rien à réduire. L'enregistrement passe de 8 à 10 octets. La PR a néanmoins mesuré une accélération de compilation de 3 à 5 pour cent dans ses benchmarks.

Le rétroportage 36.0.19, pull request #14818, applique le même changement à la branche de maintenance, avec les correctifs de deux autres avis dans la même version : un problème de longueurs de contenu contradictoires dans wasi-http (GHSA-r8xh-cgf7-392j) et le problème de cible de saut br_table sur aarch64 (CVE-2026-115893, GHSA-mghf-wjfp-p5xm).

Le correctif couvre entièrement cette catégorie de débordement dans cette structure : les valeurs ne passent plus par une réduction de largeur, donc aucune taille de fonction ne peut corrompre la correspondance. L'avis ajoute que Cranelift utilise désormais un indice u32 complet et vérifie le dépassement de cette limite : même le plafond u32 est donc contrôlé plutôt que dépassé silencieusement.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'a été publié pour cet avis. Les évasions de bac à sable par compilation incorrecte n'ont ni signature publiée ni IOC, et aucune exploitation n'est connue. Si vous utilisez un moteur affecté avec des invités non fiables et souhaitez l'auditer :

• Examinez les modules compilés et leurs auteurs, si votre plateforme enregistre les empreintes des modules ou l'historique des téléversements des locataires. Un module conçu pour cette faille contient une fonction avec un nombre de valeurs SSA inhabituellement élevé par rapport à sa taille en octets.
• Traitez tout signalement d'anomalie côté invité, lecture hors limites se manifestant par un plantage de l'hôte ou comportement impossible selon le vérificateur, comme un motif d'enquête sur le processus hôte, pas seulement sur l'invité.
• Si une compromission est suspectée, considérez le processus hôte comme entièrement compromis : renouvelez tous ses secrets et reconstruisez depuis un état sain connu, car le code invité échappé s'exécute avec les privilèges de l'hôte.

Chronologie

• 18 février 2026 : la pull request #12613, « Cranelift : mettre à jour ValueDataPacked pour prendre en charge toute la plage Value », est fusionnée sur la branche principale.
• 20 mars 2026 : Wasmtime 43.0.0 livre l'encodage sur toute la largeur.
• 14 octobre 2026 : la Bytecode Alliance publie GHSA-m9f7-9w4p-gv38, l'évasion du bac à sable du système de fichiers wasmtime-wasi via le renommage de liens symboliques terminés par une barre oblique sur macOS et FreeBSD, et publie 36.0.18, 48.0.6 et 49.0.3 avec le correctif.
• 19 octobre 2026 : l'auteur du signalement jaydns est crédité ; la Bytecode Alliance publie l'avis GHSA-897f-g5gm-fmxm et l'avis associé GHSA-mghf-wjfp-p5xm (CVE-2026-115893, l'évasion aarch64 via br_table), puis publie 36.0.19 avec les deux rétroportages ainsi que 48.0.7 et 49.0.4 avec le correctif br_table.
• 23 octobre 2026 : publication de CVE-2026-115889.
• 24 octobre 2026 : publication de cet article. Aucune exploitation dans la nature n'est connue pour les trois failles ; aucune ne figure dans le catalogue KEV de la CISA.
• 26 octobre 2026 : mise à jour avec les deux avis associés, GHSA-mghf-wjfp-p5xm (CVE-2026-115893) et GHSA-m9f7-9w4p-gv38.

FAQ

Pourquoi la branche principale a-t-elle reçu le correctif des mois avant l'avis ?

Le passage à des champs u32 complets en février a levé une limite sur la taille des corps de fonctions. Il s'agissait d'une amélioration de correction fonctionnelle, pas d'un correctif de sécurité publié. L'impact de sécurité de l'ancien encodage a été signalé plus tard, et l'avis d'octobre consigne les deux faits : v43 et les versions ultérieures ne sont pas vulnérables, et 36.0.19 rétroporte le changement vers la branche de maintenance.

Faut-il 16.7 millions d'instructions dans une fonction pour être exposé ?

Non. Le seuil porte sur les indices compactés dans l'enregistrement de valeur : indices d'instructions, de blocs et de valeurs, environ 16.7 millions de chaque. Les indices de valeurs augmentent avec le nombre de valeurs SSA, et l'avis précise qu'une fonction peut être « spécialement conçue pour utiliser de nombreuses valeurs SSA ». Un plafond en octets n'est donc pas une frontière fiable. Effectuez plutôt la mise à jour.

Les compilations de débogage sont-elles affectées ?

Non. Dans les compilations de débogage, debug_assert! se déclenche et la compilation s'arrête au lieu de corrompre la correspondance. Les moteurs de production utilisent des compilations de production, d'où le périmètre de l'avis.

Le backend Winch ou le chemin des modules précompilés sont-ils affectés ?

L'avis limite la faille au backend Cranelift, utilisé par défaut. Les moteurs qui exécutent des modules précompilés sautent l'étape de compilation où survient la corruption, mais doivent néanmoins être mis à jour, car l'avis n'exclut pas d'autres chemins de backend ou de précompilation.

Quelle est l'étendue du déploiement de Wasmtime ?

La crate wasmtime compte 41 373 089 téléchargements cumulés et 11 809 615 téléchargements sur les 90 derniers jours sur crates.io. Elle est le moteur de plateformes serverless et de plugins qui confinent du code tiers, précisément la frontière qu'un attaquant franchit avec cette faille.

Les plateformes basées sur wasmtime qui limitent les modules sont-elles affectées ?

Oui, si le moteur intégré est une version affectée. Les limites réduisent les entrées mais ne font pas partie du correctif : mettez donc le moteur à jour plutôt que de vous fier aux plafonds.

Passer à 43.0.0 ou ultérieur élimine-t-il les trois failles ?

Non. Sur la branche principale, CVE-2026-115889 est corrigée à partir de 43.0.0. L'évasion du système de fichiers est d'abord corrigée dans 48.0.6 (49.0.3 sur la branche 49), et l'évasion aarch64 via br_table dans 48.0.7 (49.0.4 sur la branche 49). Sur la branche de maintenance 36.x, 36.0.19 élimine les trois.

Références

• Avis Bytecode Alliance GHSA-897f-g5gm-fmxm : https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-897f-g5gm-fmxm (consulté le 24 octobre 2026)
• Avis Bytecode Alliance GHSA-mghf-wjfp-p5xm, CVE-2026-115893, l'évasion du bac à sable aarch64 via br_table, critique, CVSS v3.1 9.9, corrigée dans 36.0.19, 48.0.7 et 49.0.4 : https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-mghf-wjfp-p5xm (consulté le 26 octobre 2026)
• Avis Bytecode Alliance GHSA-m9f7-9w4p-gv38, l'évasion du bac à sable du système de fichiers wasmtime-wasi via le renommage de liens symboliques terminés par une barre oblique sur macOS et FreeBSD, gravité élevée, aucune CVE, corrigée dans 36.0.18, 48.0.6 et 49.0.3 : https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m9f7-9w4p-gv38 (consulté le 26 octobre 2026)
• Fiche CVE-2026-115889 (CVSS v3.1 9.9, CWE-197 et CWE-843, plages affectées) : https://cveawg.mitre.org/api/cve/CVE-2026-115889 (consulté le 24 octobre 2026)
• Correctif de la branche principale, pull request #12613, fusionnée le 18 février 2026 : https://github.com/bytecodealliance/wasmtime/pull/12613 (consulté le 24 octobre 2026)
• Avis Bytecode Alliance GHSA-r8xh-cgf7-392j, longueurs de contenu contradictoires dans wasi-http, corrigé dans le même rétroportage 36.0.19 : https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-r8xh-cgf7-392j (consulté le 27 octobre 2026)
• Rétroportage 36.x, pull request #14818 : https://github.com/bytecodealliance/wasmtime/pull/14818 (consulté le 24 octobre 2026)
• Version Wasmtime 36.0.19 (publiée le 19 octobre 2026) : https://github.com/bytecodealliance/wasmtime/releases/tag/v36.0.19 (consulté le 24 octobre 2026)
• Version Wasmtime 43.0.0 (publiée le 20 mars 2026) : https://github.com/bytecodealliance/wasmtime/releases/tag/v43.0.0 (consulté le 24 octobre 2026)
• dfg.rs vulnérable sur la branche 36.x (encodage ValueDataPacked) : https://github.com/bytecodealliance/wasmtime/blob/v36.0.18/cranelift/codegen/src/ir/dfg.rs (consulté le 24 octobre 2026)
• Statistiques de téléchargements crates.io pour wasmtime (41 373 089 cumulés, 11 809 615 sur les 90 derniers jours) : https://crates.io/api/v1/crates/wasmtime (consulté le 24 octobre 2026)