Failles du sandbox Wasmtime : mettre à jour la CLI ne corrige pas le runtime embarqué
Reliez les dépendances Wasmtime aux artefacts livrés, choisissez le bon correctif et vérifiez les déploiements avec un processus de preuves Plexicus.
Au-delà de l’ASPM
Une AppSec fondée sur la preuve pour les équipes qui développent avec l’IA
Plexicus utilise AI Swarm Pentest pour explorer des chemins d’application autorisés, valider ce qui est exploitable et fournir les preuves nécessaires pour prioriser la remédiation.
Découvrir AI Swarm PentestLa mise à jour Wasmtime la plus facile à vérifier peut concerner un outil que votre application n’utilise pas. Un développeur actualise la ligne de commande et vérifie wasmtime --version. Le service de production conserve pourtant une ancienne dépendance Rust dans son propre binaire.
Le problème concerne donc aussi l’inventaire et le déploiement. La question essentielle devient : quel runtime compile les modules non fiables, et quel artefact déployé le contient ?
Deux avis, des versions corrigées différentes
Le 19 octobre, deux avis Cranelift ont décrit des sorties du sandbox : débordement d’indices SSA et compilation incorrecte de br_table sur aarch64. Avis SSA · Avis aarch64.
| Avis | Versions affectées | Correctifs publiés |
|---|---|---|
| GHSA-897f-g5gm-fmxm | <36.0.19; >=37.0.0, <43.0.0 | 36.0.19, 43.0.0 |
| GHSA-mghf-wjfp-p5xm | <36.0.19; >=37.0.0, <48.0.7; >=49.0.0, <49.0.4 | 36.0.19, 48.0.7, 49.0.4 |
Tenez compte du backend et de l’architecture propres à chaque avis. 43.0.0 corrige le premier problème, pas le second. Ce tableau a été vérifié le 27 octobre 2026. Il ne garantit pas qu’une version traite toutes les vulnérabilités ultérieures. Choisissez une version maintenue après examen des avis actuels et de la compatibilité.
Identifier le runtime réellement livré
Un service de plugins peut recevoir du WebAssembly client et intégrer Wasmtime directement, via une dépendance transitive ou dans une bibliothèque précompilée. Son responsable doit identifier l’artefact de production, pas seulement les outils des développeurs.
Partez des entrées du véritable build. Dans un workspace Rust, ces commandes facilitent la découverte :
cargo tree --locked | rg 'wasmtime|cranelift'
cargo metadata --locked --format-version 1 > dependency-metadata.json
Utilisez le workspace et la configuration adéquats. Une entrée ne prouve pas l’accessibilité à l’exécution. Son absence n’exclut pas une bibliothèque native téléchargée ou un binaire fournisseur. Documentez ces limites.
Pour chaque artefact pertinent, conservez dépôt et commit, version résolue, architecture cible, backend, fonctionnalités, tâche de build et empreinte immuable. Identifiez ensuite les instances exécutant cette empreinte. Une étiquette multiarchitecture ne démontre pas ce qu’exécute un worker ARM.
Transformer l’inventaire en décision
Chaque entrée pertinente doit avoir un responsable et une décision. Le service accepte-t-il des modules non fiables ? La compilation appartient-elle à l’application, à un worker distinct ou à la chaîne de déploiement ? Quel backend et quelle cible sont sélectionnés ? Sans réponse, conservez le statut « inconnu » plutôt que « non affecté » sans preuve.
Le guide de sécurité Wasmtime explique le sandbox et les interfaces du système hôte. Un objectif de conception ne prouve pas l’absence d’erreur dans un build donné.
Traitez d’abord les chemins de compilation affectés et accessibles. Justifiez séparément les autres déploiements. N’appliquez pas la condition aarch64 au premier avis et ne supposez pas qu’un changement de configuration atténue les deux problèmes.
Reconstruire, déployer et vérifier
Modifier le fichier de verrouillage propose une correction. Les preuves suivantes montrent ce qui a réellement changé.
| Étape | Preuve à conserver |
|---|---|
| Dépendance | Version résolue et modification examinée |
| Reconstruction | Configuration, tâche réussie et empreinte |
| Déploiement | Empreinte exécutée sur chaque architecture pertinente |
| Test fonctionnel | Comportement attendu du plugin et résultats de régression |
| Clôture | Justification par avis, responsable et lacunes restantes |
Incluez les workers persistants et les artefacts de retour arrière. Remplacer une image dans un registre ne remplace pas un processus actif. Un test applicatif réussi ne reproduit ni ne réfute indépendamment une sortie du sandbox provoquée par le compilateur. Précisez ce qu’il vérifie réellement.
Le rôle de Plexicus
Plexicus XBOM présente les inventaires logiciels, cryptographiques et IA dans un même processus. Deep Code Analysis apporte le contexte des flux de code et des impacts métier. Demandez lors d’une présentation XBOM comment intégrer les dépendances résolues et les preuves d’artefacts. Examinez ensuite comment les modules clients atteignent l’application qui embarque le runtime.
Ces descriptions ne garantissent ni découverte automatique de chaque copie de Wasmtime, ni reproduction d’exploits du compilateur, ni couverture complète des binaires. Rendez ces exigences explicites et demandez des preuves de couverture.
La chaîne utile est avis → dépendance → build → empreinte déployée → vérification. Une capture isolée de version ne la remplace pas.
Besoin de relier inventaire et correction ? Demandez une présentation XBOM ou découvrez Deep Code Analysis. Apportez un service, ses entrées de build et son empreinte déployée.
