Une équipe de recherche en cybersécurité a signalé une vulnérabilité critique affectant isolated-vm bac à sable, une bibliothèque open source très utilisée côté Node.js pour exécuter du JavaScript non fiable. Le problème ne remet pas en cause la logique d’isolation au niveau de V8, mais met en défaut une partie du “pont” C++ utilisé pour transférer des valeurs entre l’hôte et le bac à sable.
Concrètement, une exploitation réussie pourrait mener à une corruption de mémoire dans le processus hôte. Selon les démonstrations fournies, l’impact minimal constaté correspond à un arrêt contrôlé (déni de service), tandis que l’impact maximal envisagé inclut une prise de contrôle du flux du processus hôte, ce qui pourrait ouvrir la voie à de la RCE.
Ce qu’est isolated-vm bac à sable
isolated-vm sert à exécuter du JavaScript “non digne de confiance” à l’intérieur d’une instance isolée de V8, appelée Isolate. L’intérêt principal est de permettre l’exécution simultanée de plusieurs environnements sandboxés sans qu’ils partagent directement des données ou interfèrent entre eux.
Chaque Isolate dispose de son propre état et de son propre espace mémoire (heap). Pour cette raison, il n’est pas possible de transférer simplement des objets JavaScript du thread Node.js principal vers le bac à sable. La bibliothèque propose alors une classe dédiée, ExternalCopy, qui vise à sérialiser des objets depuis l’Isolate hôte et à les désérialiser dans l’Isolate invité.
La vulnérabilité identifiée
La faille, référencée GHSA-864f-rcv7-6rh4, n’avait pas encore d’identifiant CVE au moment de la publication. Elle concerne toutes les versions de la bibliothèque avant et incluant la 7.0.0.
Les correctifs ont été intégrés dans 6.2.0 et 7.0.1 (sortie plus tôt le mois en cours, selon l’annonce). Les utilisateurs qui ont isolated-vm dans leurs environnements de développement devraient donc mettre à jour vers une version corrigée afin de réduire le risque.
Où la faille se cache : ExternalCopy
Le point central du rapport est l’implémentation de ExternalCopy. D’après les informations publiées, le code s’exécutant dans le sandbox pourrait exploiter un défaut de type (“type confusion”) dans le traitement de l’option transferList pour corrompre la mémoire du processus hôte.
Les auteurs indiquent qu’en partant de la seule capacité représentée par un ivm.Reference (le mécanisme standard par lequel un hôte attribue une capacité au sandbox), la démonstration a été poussée d’un crash “contrôlé” jusqu’à un scénario de détournement du contrôle du processus hôte.
Résultats d’exploitation : crash, puis évasion
En cas d’exploitation réussie, la corruption mémoire peut provoquer l’arrêt du processus hôte avec une erreur de type segmentation fault (SIGSEGV). Cet aspect correspond à l’impact minimal mis en évidence : un déni de service déclenchable par n’importe quel invité qui a reçu une ivm.Reference.
Au-delà du crash, les démonstrations décrivent aussi un chemin vers une évasion du sandbox vers l’hôte et une atteinte à la frontière de confiance. L’idée est importante : l’objectif de isolated-vm n’est pas seulement d’empêcher des échanges directs de données, mais aussi de préserver l’intégrité du périmètre d’isolation.
Pourquoi l’isolement V8 tient… mais pas le pont
Un point a été souligné par les chercheurs : la “primitive” d’isolation elle-même n’est pas le cœur du problème. La barrière Isolate de V8 reste valide.
Ce qui échoue se situe plutôt dans le code d’assemblage (la “colle”) qui permet de faire passer les valeurs entre le monde hôte et le monde invité. Autrement dit, un composant de base robuste est fragilisé par la couche C++ qui gère la marshalling et la sérialisation/désérialisation des données.
Ce que cela signifie pour votre application
Si votre application utilise isolated-vm bac à sable pour exécuter du JavaScript non fiable, la vulnérabilité augmente la surface d’attaque dès qu’un invité sandboxé dispose des capacités appropriées, notamment via ivm.Reference. Dans un scénario réaliste, cela peut concerner des plugins, scripts fournis par des utilisateurs, ou tout traitement où vous “autorisez” le sandbox à interagir avec l’hôte.
Le risque n’est pas universellement identique pour tous les déploiements, car l’exploitation nécessite que la configuration expose les mécanismes visés. Toutefois, le conseil reste simple et prudent : mettre à jour vers une version corrigée.
Mise à jour recommandée et mesures additionnelles
Les mainteneurs indiquent que l’attaque la plus probable concerne les versions incluant celles jusqu’à 7.0.0. Pour une protection optimale, il est recommandé d’installer 6.2.0 ou 7.0.1, ces versions ayant intégré les corrections.
Par ailleurs, les détails techniques complets de l’exploit ont été volontairement limités afin de réduire la possibilité qu’un acteur malveillant réutilise directement la méthode. Cela ne supprime pas le besoin de correctifs, mais montre que les informations sensibles ne sont pas toutes publiées.
Enfin, même après mise à jour, gardez un principe de durcissement : limitez au maximum les capacités accordées au sandbox. Plus vous réduisez ce que le code invité peut manipuler côté hôte, plus vous réduisez le potentiel d’abus.
Message clé à retenir
La conclusion la plus importante est la suivante : l’isolation V8 fonctionne, mais le mécanisme de transfert via la couche ExternalCopy présentait un défaut exploitable. Dans le meilleur des cas, cela se traduit par un crash contrôlé ; dans le pire, la démo suggère une capacité à faire dérailler le processus hôte.
Si vous utilisez isolated-vm bac à sable en environnement de développement ou en production, mettez à jour dès que possible vers les versions corrigées et vérifiez que votre intégration n’accorde pas plus de capacités que nécessaire.
Source: https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
