Wasmtime corrige deux accidents graves à Cranelift (CVE-2026-115889, CVE-2026-115893)

Au cours des dernières semaines, deux défaillances graves ont été corrigées à Wasmtime, l'environnement de fonctionnement WebAssembly qui est intégré dans les programmes à l'extérieur du navigateur. Les responsables ont évalué chaque vulnérabilité avec 9,9 / 10 sur l'échelle CVSS et ont publié des correctifs entre le 19 et le 20 octobre. Les erreurs permettent, sous certaines conditions, un module d'assemblage Web malveillant pour échapper au bac à sable qui devrait le limiter et exécuter le code en dehors de votre zone autorisée. Selon les notes officielles, il n'y a pas de rapports publics d'exploitation active avant la date limite indiquée dans les avis.

Ce qui est confirmé: les deux échecs sont implémentationnels dans Cranelift, le compilateur par défaut Wasmtime utilise pour convertir Wasm en code machine. Ils sont enregistrés comme CVE-2026-115889 (touche toutes les architectures) et CVE-2026-115893 (touche seulement ARM64 / aarch64). Les responsables ont publié des versions corrigées (p. ex. Wasmtime 50.0.0 et patchs point sur les lignes supportées) qui éliminent les conditions vulnérables. En outre, les deux entrées sont énumérées dans la base de vulnérabilité RustSec sous les identificateurs susmentionnés, et le catalogue des vulnérabilités exploitées connu de la CISA ne comprenait pas ces CVE au 26 octobre.

Comment les défauts fonctionnent techniquement (résumé technique vérifiable): CVE-2026-115889 vient de la façon dont les numéros codés internes de Cranelift ont permis d'identifier des valeurs dans une fonction : à l'origine, ces identifiants ont été ajustés dans des champs 24 bits et, dans les compilations de lancement, un identifiant qui dépassait cet espace n'a pas été détecté, ce qui pourrait amener le compilateur à se référer à la mauvaise valeur et générer un code incorrect. Ce comportement permet de construire des fonctions Wasm extrêmement grandes ou conçues pour consommer de nombreux identifiants et forcer une confusion de type qui pourrait briser les garanties de bac à sable. CVE-2026-115893 explorations ARM64, Cranelift a généré une branche "long range" vers l'entrée de saut par défaut qui ne pouvait atteindre qu'une portée limitée (h1 MiB). Lorsqu'une table de sauts avait trop d'entrées (plus de ~ 256 000), la branche dépassait la portée et pointait tranquillement vers une mauvaise direction, permettant au module contrôlé de sauter dans le code arbitraire dans les processus avec la configuration par défaut dans ARM64. La correction modifie la génération de sorte que les indices hors gamme soient passés à travers la table elle-même plutôt que d'utiliser une branche à longue distance et ajoute un seuil de rejet pour les tables trop grandes (tableau Br avec plus de 65.520 destinations sont refusées).

Qui est le plus à risque - faits et estimations : Le risque réel est confirmé par la possibilité qu'un tiers charge ou livre un module Wasm que l'hôte rivalise avec une version vulnérable de Wasmtime. Par conséquent, les services qui acceptent et compilent le code d'utilisateur externe - par exemple, les plates-formes de calcul de bord ou "serverless" qui exécutent WebAssembly - sont les plus exposés. Ceci est conforme aux exemples publics : des fournisseurs comme Fastly ont documenté l'utilisation de Wasmtime sur des plateformes qui utilisent le code client, ce qui illustre le modèle de menace même si les avis officiels ne mentionnent pas les services touchés ou ne prétendent pas des incidents connus. Il s'agit d'une estimation raisonnable (mais non d'une confirmation) que les environnements qui ne compilent pas des modules tiers ou qui n'exécutent que des modules signés / certifiés sont à un risque beaucoup plus faible.

Portée des versions et soutien - faits clés pour l'atténuation : Wasmtime maintient des lignes avec un soutien différent: LTS (multiple de 12) reçoivent un soutien pendant deux ans; d'autres lignes seulement deux mois. Les responsables ont indiqué que seules les lignes 36, 48, 49 et 50 étaient appuyées au moment de l'avis; de nombreuses anciennes succursales, dont la LTS 24.x dont le soutien a pris fin le 20 août 2026, n'ont pas été corrigées. Les versions selon chaque ligne sont: mise à jour à 36.0.19, 48.0.7, 49.0.4 ou Wasmtime 50.0.0 (ce dernier corrige les deux défauts). Important : Wasmtime est habituellement intégré comme bibliothèque : la mise à jour de l'outil en ligne de commande n'atténue pas les dépendances gaufrées; chaque produit, y compris Wasmtime, doit être reconstruit en reliant la version sécurisée.

Mesures spécifiques et prioritaires que vous devez prendre maintenant : 1) Utilisations de l'inventaire : identifier tous les binaires, conteneurs et paquets qui incluent Wasmtime dans votre environnement et déterminer la ligne de version (p. ex. 36, x, 48, x, 49, x, 50,x ou lignes non prises en charge). 2) Mise à jour et remodelage: pour les environnements pris en charge, mise à jour vers les versions corrigées indiquées ci-dessus; pour les produits qui incarnent Wasmtime comme librairie, reconstruire ces programmes avec la version sécurisée; pour les lignes non prises en charge, migrer vers une ligne prise en charge et appliquer le patch. 3) Analysez l'exposition : si votre service compile des modules utilisateurs, traitez ces points d'entrée comme une priorité absolue pour le stationnement et le déploiement. 4) Détecter les dépendances : exécuter des outils comme l'audit-cargo pour détecter les entrées de RUSTSEC (les ID associés sont listés dans RustSec); cela aide à trouver Wasmtime affecté dans les chaînes de dépendance. 5) Contrôles compensatoires si vous ne pouvez pas vous garer immédiatement: il limite la possibilité pour des tiers de télécharger ou de compiler des modules (par exemple, désactiver la compilation JIT de modules non vérifiés, mettre en œuvre le rejet de charges, exiger la signature de modules ou isoler la compilation dans des boîtes de sable OS supplémentaires comme conteneurs avec des politiques seccomp / SELinux). 6) Enregistrer et surveiller : Activer les journaux d'exécution détaillés et surveiller les comportements atypiques (sauts inhabituels, exécution hors mémoire assignée) et surveiller les alertes et les entrées publiques sur des bases telles que GitHub Advisory Database, RustSec et CISA.

Les éléments suivants ne sont ni clairs ni confirmés: Les avis ne précisent pas les ressources spécifiques qu'un attaquant pourrait obtenir après avoir échappé au bac à sable ou à la liste des fournisseurs touchés; ils ne précisent pas non plus précisément quand l'équipe a reconnu l'impact sur la sécurité de la première vulnérabilité (la correction technique, qui étend les champs à 32 bits, a été introduite auparavant pour des raisons de capacité). Il n'y a pas non plus de données d'exploitation vérifiées dans les campagnes actives à la clôture des avis. Dans ARM64, le deuxième échec a existé depuis que Wasmtime a soutenu cette architecture (2020), mais il n'y a aucune preuve publique d'abus massif de celle-ci.

Pour les corrections et le téléchargement des versions publiées, voir la page de lancement du projet : Wasmtime v50.0.0, et vérifier les billets de sécurité pour RustSec: RUSTSEC-2026-0380 et RUSTSEC-2026-0379. Pour le contexte de la liste des vulnérabilités exploitées et de leur suivi par les infrastructures essentielles, voir le catalogue de la CISA: Catalogue CISA KEV.

En bref : traiter ces corrections comme une priorité élevée si votre infrastructure compile ou exécute Modules Wasm d'origine peu fiable; la correction et la reconstruction des bibliothèques est la mesure sûre et directe. Si vous ne pouvez pas le faire immédiatement, réduire l'exposition en limitant l'admission et la compilation des modules et appliquer des contrôles supplémentaires au niveau des conteneurs et l'authentification des modules jusqu'à ce que la solution finale soit déployée.