DEF CON 34 : une faille de Pyodide a exposé sept produits

À mesure que les agents d’IA et les plateformes d’automatisation exécutent de plus en plus souvent du code généré par des modèles ou des utilisateurs, les limites de sécurité qui entourent ce code sont devenues essentielles. 

Des recherches présentées à DEF CON 34 par les chercheurs de Cyera Vladimir Tokarev et Saar Pearl ont révélé que sept produits utilisant Pyodide s’appuyaient sur des restrictions au niveau de Python qui n’isolaient pas complètement le code non fiable de l’environnement hôte sous-jacent.

Principales conclusions des recherches de Cyera

• Les chercheurs ont identifié des échappements du bac à sable de Pyodide dans sept produits, constatant que les restrictions au niveau de Python n’isolaient pas complètement le code non fiable de l’environnement hôte sous-jacent.
• Les recherches ont abouti à quatre CVE, notées de 8,3 à 9,9, dont une vulnérabilité critique dans n8n susceptible d’exposer les identifiants associés aux intégrations connectées.
• L’environnement hôte détermine l’impact potentiel d’un échappement du bac à sable, mettant en danger les identifiants d’API, le code source, les clés de signature, les services internes, les bases de données et autres ressources sensibles.
• Les organisations doivent appliquer des mesures de défense en profondeur pour l’exécution de code non fiable, notamment une isolation indépendante, un accès selon le principe du moindre privilège, des restrictions réseau, des identifiants à courte durée de vie, une surveillance et des tests réguliers de réponse aux incidents.

Pourquoi la sécurité du bac à sable de Pyodide est importante pour les applications d’IA

Pyodide exécute CPython dans WebAssembly (WASM), ce qui permet aux applications d’exécuter du code Python dans des environnements JavaScript tels que les navigateurs, Node.js et Deno. 

Les développeurs peuvent restreindre des modules Python potentiellement dangereux tels que os et subprocess, créant ce qui ressemble à un bac à sable pour l’exécution de code non fiable.

Cependant, les chercheurs ont constaté que les restrictions appliquées dans les sept produits testés ne prenaient pas en compte le module Python ctypes ni les fonctions exportées par Emscripten. 

Cela créait une voie permettant au code Python prétendument restreint d’accéder à l’environnement d’exécution hôte JavaScript. 

Ces divulgations ont abouti à quatre CVE, avec des scores de gravité allant de 8,3 à 9,9.

Le problème fondamental était d’ordre architectural, et non propre à une application particulière. 

WASM protège sa propre mémoire linéaire, mais n’empêche pas les logiciels d’accéder aux capacités que l’environnement hôte expose intentionnellement. 

Dans les configurations testées, ctypes restait disponible et pouvait résoudre les fonctions Emscripten pertinentes.

Sept produits affectés par les vulnérabilités du bac à sable de Pyodide

Les chercheurs ont reproduit des échappements de bac à sable similaires dans l’automatisation des flux de travail, les tableurs, les environnements d’exécution d’agents d’IA, les applications de bureau et les outils d’intégration et de livraison continues (CI/CD).

L’une des découvertes les plus graves concernait CVE-2025-68668, notée 9,9, qui affectait n8n. 

Son nœud Code autorisait l’exécution de Python via Pyodide sur Node.js. 

Ce contournement pouvait permettre à des attaquants d’atteindre le processus du service n8n et d’accéder potentiellement aux identifiants liés aux intégrations connectées. 

En réponse, n8n a déplacé l’exécution du code Python vers un exécuteur externe, l’isolant davantage du service principal.

Grist, une plateforme open source de tableurs et de bases de données prenant en charge les formules basées sur Python, était affectée par la CVE-2026-24002. La vulnérabilité a reçu un score CVSS de 9,1. 

Terrarium de Cohere, un environnement en bac à sable destiné à l’exécution de code généré par l’IA, était affecté par CVE-2026-61522, qui affiche un score CVSS de 9,3. 

smolagents de Hugging Face, un framework destiné à créer des agents d’IA capables d’exécuter du code et d’utiliser des outils externes, était également affecté par CVE-2026-10613 et a reçu un score CVSS de 8,3.

Les recherches ont également identifié des problèmes de sécurité concernant langchain-sandbox, stlite et cibuildwheel. 

Les réponses des mainteneurs variaient selon les projets : certains ont mis en œuvre des changements architecturaux, d’autres ont archivé les composants affectés, tandis que certains estimaient qu’une isolation appropriée devait être appliquée au niveau du déploiement.

Comment les environnements d’exécution hôtes accroissent les risques de sécurité du bac à sable de Pyodide

Sortir de Pyodide ne représentait qu’une partie de l’équation de sécurité. Les chercheurs ont souligné que l’environnement d’exécution hôte et l’environnement environnant déterminaient l’impact potentiel.

Par exemple, les processus Node[.]js peuvent exposer des API de système de fichiers, de processus et d’environnement. 

Deno utilise des autorisations explicites qui peuvent limiter des capacités telles que l’accès au système de fichiers, au réseau et aux sous-processus. 

Dans les environnements CI/CD, un échappement du bac à sable pourrait exposer des actifs sensibles tels que des jetons de publication, des clés de signature, du code source propriétaire et des artefacts de version. 

Les environnements d’agents d’IA présentent des risques similaires, en pouvant donner aux attaquants accès à des identifiants d’API, des services internes, des bases de données, des outils connectés et des données clients sensibles.

Comment sécuriser Pyodide grâce à des mesures de défense en profondeur

Ces résultats montrent pourquoi les organisations ne doivent pas considérer les restrictions d’importation Python comme une limite de sécurité complète. 

Les équipes produit doivent restreindre les fonctionnalités inutiles de ctypes, privilégier les listes d’autorisation de modules, supprimer les exportations Emscripten inutiles et réduire au minimum les autorisations de l’environnement d’exécution hôte. 

Le code non fiable doit également s’exécuter derrière une limite d’isolation indépendante, par exemple dans un processus ou un conteneur distinct.

Les organisations utilisant les frameworks concernés doivent effectuer une mise à niveau vers des versions corrigées ou appliquer les mesures d’atténuation recommandées par les fournisseurs. 

Au-delà du traitement des vulnérabilités individuelles, les équipes doivent mettre en œuvre des mesures de défense en profondeur destinées à limiter ce à quoi un attaquant peut accéder si le bac à sable est contourné.

• Appliquer le principe du moindre privilège en utilisant des comptes de service dédiés et des autorisations strictement limitées pour les charges de travail exécutant du code non fiable.
• Limiter l’accès au réseau sortant à afin d’empêcher les charges de travail compromises d’atteindre des services internes inutiles ou d’exfiltrer des données sensibles.
• Utiliser des identifiants à courte durée de vie et spécifiques aux charges de travail et éviter d’exposer des secrets persistants aux environnements en bac à sable.
• Séparer les fonctions et les identifiants CI/CD sensibles, notamment pour la compilation, la signature, la publication et l’accès à la production, afin de limiter l’impact d’une étape de pipeline compromise.
• Restreindre l’accès au système de fichiers et à l’hôte au moyen de montages en lecture seule, d’autorisations minimales sur l’hôte et d’un accès limité aux ressources nécessaires à la charge de travail.
• Utiliser des conteneurs éphémères ou des processus isolés pour les charges de travail non fiables, afin de pouvoir supprimer les environnements après l’exécution plutôt que de conserver un accès ou un état persistant.
• Surveiller les charges de travail en bac à sable pour détecter les comportements suspects, notamment la création inattendue de processus, les connexions réseau, l’accès aux fichiers et les tentatives d’élévation de privilèges.
• Tester régulièrement les scénarios d’échappement du bac à sable et de réponse aux incidents avec des outils de simulation d’attaque afin de vérifier que les équipes peuvent contenir les charges de travail compromises, révoquer les accès et renouveler rapidement les identifiants exposés.

La combinaison de ces mesures peut réduire à la fois la probabilité d’un échappement réussi du bac à sable et l’ampleur potentielle des dégâts lorsqu’un mécanisme d’isolation échoue.

En résumé

Ces recherches mettent en évidence une leçon plus générale pour la sécurité de l’IA : un bac à sable n’est aussi robuste que les limites qui le sous-tendent. 

À mesure que les systèmes d’IA acquièrent davantage de pouvoirs pour exécuter du code et interagir avec des ressources sensibles, les organisations doivent sécuriser non seulement ce que le code peut appeler à l’intérieur d’un interpréteur, mais aussi ce à quoi il peut accéder si cette limite au niveau de l’interpréteur échoue.

Une architecture zero trust peut contribuer à renforcer ces limites en vérifiant continuellement les accès, en appliquant le principe du moindre privilège et en limitant ce à quoi les charges de travail d’IA compromises peuvent accéder dans l’ensemble de l’environnement.