# Wasmtime : une faille permet lecture/écriture hors limites sur x86_64

_Publié le 9 novembre 2026 — https://ip73.fr/2026/11/09/wasmtime-une-faille-permet-lecture-ecriture-hors-limites-sur-x86-64/_

Une erreur dans le générateur de code de Wasmtime, Cranelift, ouvre une porte dangereuse sur les systèmes x86_64. Selon l'avis de sécurité publié sur github.com, cette faille permet à un module WebAssembly (Wasm) de lire ou d'écrire dans des zones mémoire bien au-delà de ses limites définies, atteignant potentiellement jusqu'à environ 34 gigaoctets de mémoire à partir de la base de l'instance. L'impact est critique : un module malveillant pourrait accéder sans que l'intégrateur ne le sache à des données appartenant à d'autres instances ou même à l'environnement d'hébergement.

Le problème réside dans une mauvaise interprétation des modes d'adressage. Cranelift, lors de la traduction d'une opération Wasm, calcule par erreur une adresse effective de 35 bits au lieu des 33 bits définis par la spécification WebAssembly. Concrètement, lorsque le code Wasm utilise une opération de décalage (comme `i32.shl`), cette valeur est traitée par Cranelift en utilisant des nombres sur 64 bits. Cela donne trois bits d'espace d'adressage supplémentaires, ce qui se traduit par un accès mémoire hors limites. Ce calcul erroné ne garantit pas un plantage système.

Difficile de ne pas s'interroger sur les mécanismes de détection. Les opérations de chargement et de stockage Wasm sont censées générer un piège (trap) en cas d'accès invalide. Or, ce bug permet à l'écriture ou à la lecture de se faire silencieusement dans cette région. Il est donc difficile pour l'intégrateur de déterminer si la faille a été exploitée historiquement, ce qui oblige les développeurs à analyser leurs modules Wasm existants.

## Les correctifs et les solutions de contournement

La Bytecode Alliance a publié des correctifs dans les versions 4.0.1, 5.0.1 et 6.0.1 de Wasmtime pour éliminer ces règles de transposition erronées dans le backend de Cranelift. C'est la solution la plus directe. Mais si la mise à jour n'est pas immédiatement possible, des mesures temporaires existent. On peut, par exemple, forcer des contrôles de limites explicites sur la mémoire en utilisant l'option `Config::static_memory_maximum_size(0)`. Attention, cette vérification supplémentaire affecte la performance d'exécution des modules Wasm.

Une autre approche consiste à augmenter massivement les pages de garde après la mémoire linéaire avec `Config::static_memory_guard_size(1 << 36)`. L'idée est de réserver de l'espace mémoire non mappé pour garantir que tout accès au-delà de la limite soit bloqué par le système d'exploitation. Néanmoins, cette technique consomme une quantité de mémoire virtuelle très importante par instance, ce qui limite le nombre d'instances que l'on peut faire tourner simultanément.

Si l'environnement hôte le permet, basculer vers une architecture autre que x86_64 est un contournement efficace, car ce bug ne touche pas les implémentations AArch64 de Wasmtime ou de Cranelift.

## L'isolation des micro-VMs face aux failles de sandbox

Cette vulnérabilité rappelle la tension constante entre performance et isolation lors de l'exécution de code tiers. Des projets comme Hyperlight, un gestionnaire de machines virtuelles léger (VMM) de la CNCF, cherchent à combler ce fossé. Hyperlight permet d'intégrer un isolateur au cœur d'une application, en exécutant du code non fiable dans des micro-VMs isolées par des extensions de virtualisation matérielle (KVM, MSHV, etc.).

L'avantage principal de ce type de VMM embarqué réside dans sa réactivité. Contrairement aux machines virtuelles traditionnelles qui nécessitent le démarrage d'un système d'exploitation complet, Hyperlight peut créer et détruire des sandboxes en quelques millisecondes. Il est capable d'exécuter des binaires Linux non modifiés. D'ailleurs, le groupe Hyperlight a démontré que même si un exploit ciblant une vulnérabilité Wasmtime corrigée (CVE-2023-26489) pouvait lire des secrets sur l'hôte en mode natif, dans un environnement Hyperlight, l'accès se cantonnait à la mémoire propre de la micro-VM, préservant ainsi la sécurité de l'hôte.

## Fiche technique

| CVE | Produit | Gravité | Exploitée activement | Versions corrigées |
|---|---|---|---|---|
| CVE-2023-26489 | wasmtime (rust), wasmtime (rust) | Critique (CVSS 9,9) | Non signalée | wasmtime 4.0.1, wasmtime 5.0.1, wasmtime 6.0.1, cranelift-codegen 0.91.1, cranelift-codegen 0.92.1, cranelift-codegen 0. |

*Données : [NVD](https://nvd.nist.gov/) (NIST) et [GitHub Advisory Database](https://github.com/advisories) ([CC BY 4.0](https://creativecommons.org/licenses/by/4.0/deed.fr), données adaptées).*

## Sources

- [Guest-controlled out-of-bounds read/write on x86\_64](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8), github.com
- [GitHub - hyperlight-dev/hyperlight: Hyperlight is a lightweight Virtual Machine Manager (VMM) designed to be embedded within applications.…](https://github.com/hyperlight-dev/hyperlight), github.com
- [Run Linux applications in hypervisor-isolated micro-VMs with Hyperlight](https://www.cncf.io/blog/2026/11/09/run-linux-applications-in-hypervisor-isolated-micro-vms-with-hyperlight/), CNCF, 9 novembre 2026 (contenu sous licence CC BY 3.0)
- [Avis de sécurité (groups.google.com)](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ), groups.google.com, 8 mars 2023
- [GHSA-ff4p-7xrq-q5r8](https://github.com/advisories/GHSA-ff4p-7xrq-q5r8) : wasmtime vulnerable to guest-controlled out-of-bounds read/write on x86\_64, GitHub Advisory Database (CC BY 4.0)
- [CVE-2023-26489](https://nvd.nist.gov/vuln/detail/CVE-2023-26489), NVD (NIST)