Évasion de Sandbox Terrarium CVE-2026-5752 (CVSS 9.3) : Ce que signifie le bug de Sandbox Cohere AI pour l’isolation du contenu dans les piles Edge d’entreprise

8 min de lecture · Mis à jour le 23.04.2026

Le 14 avril 2026, la vulnérabilité CVE-2026-5752 a été rendue publique, révélant une échappatoire de bac à sable dans le projet open-source Terrarium de Cohere AI. Depuis le 22 avril, les équipes de sécurité ont une évaluation plus précise de la situation : CVSS 9.3, échappatoire de chaîne de prototypes, exécution de code root dans le conteneur, avec un potentiel de propagation à l’hôte. Terrarium n’est pas un outil de niche, mais une infrastructure largement utilisée pour l’exécution de code dans les charges de travail des grands modèles de langage (LLM). Ceux qui ont développé des fonctionnalités d’IA avec des environnements d’exécution en bac à sable au cours des derniers mois se posent une question cruciale : le bug affecte-t-il également leur propre pile technologique ?

Points clés

CVE-2026-5752 affecte le projet open-source Terrarium de Cohere AI, un bac à sable pour le code généré par les LLM et écrit par les utilisateurs.
Le bug réside dans l’isolation insuffisante de la chaîne de prototypes JavaScript. Les attaquants peuvent accéder au constructeur de fonctions et ainsi à globalThis.
Impact : droits root dans le conteneur, accès à /etc/passwd et aux variables d’environnement, accès réseau dans le réseau du conteneur, éventuelle évasion du conteneur.
Le CERT/CC n’a pas pu coordonner la mise à disposition d’un patch avec le fournisseur avant la publication. La mitigation repose actuellement sur les opérateurs.
Les équipes de sécurité dans les piles Enterprise Edge doivent clarifier dans les 14 prochains jours quels services utilisent Terrarium et quelle couche d’isolation est en place.

Ce qu’est Terrarium et pourquoi ce bug est critique

Qu’est-ce que Terrarium ? Terrarium est un bac à sable open-source développé par Cohere AI, fourni sous forme de conteneur Docker. Il exécute du code non fiable de manière sécurisée, comme des extraits de code Python ou JavaScript, soit entrés par les utilisateurs, soit générés par un grand modèle de langage. Terrarium fait partie des implémentations de référence lorsque les équipes produit intègrent un interpréteur de code dans leur application de grand modèle de langage sans construire eux-mêmes une architecture complète de bac à sable. Son utilisation va des chatbots avec exécution Python aux agents d’entreprise qui effectuent des analyses de données automatisées dans les environnements clients.

Le bug lui-même est une variante d’une classe d’attaques connue. L’échappement de la chaîne de prototypes JavaScript signifie qu’un code chargé dans le bac à sable accède à l’objet global via la propriété prototype du constructeur de fonction. Terrarium génère un objet Document simulé en tant qu’objet littéral JavaScript normal. Celui-ci hérite via Object.prototype les fonctions d’accès dont les attaquants ont besoin pour s’échapper du bac à sable. Ce schéma est connu depuis des années dans les bugs de bac à sable des navigateurs, mais il présente une autre dimension de risque dans un contexte d’exécution de code côté serveur avec des droits root.

Les conséquences pratiques sont graves. Un exploit réussi donne accès root à l’intérieur du conteneur, lit ou modifie /etc/passwd et les clés SSH, lit les variables d’environnement y compris les clés API, atteint les services voisins dans le réseau de conteneurs et rend les chemins d’échappement de conteneur plus probables. Selon la configuration, des accès à l’hôte sont possibles. Particulièrement délicate est la combinaison avec des clés API à courte durée de vie, souvent transmises en tant que variable d’environnement. Un exploit peut extraire des identifiants en quelques secondes avant que les équipes de sécurité ne réagissent à l’incident.

CVSS 9.3

Classification critique pour CVE-2026-5752 avec exécution de code root dans le conteneur Terrarium et potentielle voie d’échappement de conteneur

Source : NVD, GitHub Advisory, CERT/CC VU#414811, au 22 avril 2026

Pourquoi ce bug est stratégiquement plus qu’un simple CVE

La valeur de cet incident ne réside pas dans un simple patch, mais dans la question qu’il soulève. Depuis 2024, les piles d’entreprise en périphérie ont structurellement évolué. De nombreux produits intègrent aujourd’hui une fonction d’interprétation de code, permettant aux utilisateurs ou aux modèles d’IA d’exécuter de petits scripts. Les applications vont des assistants d’analyse de données aux workflows agentiques qui génèrent des scripts de manière autonome. Dans ce contexte, un bac à sable n’est pas optionnel, mais constitue le seul pont entre l’utilité commerciale et un risque acceptable. Si ce pont s’effondre, c’est toute la promesse qui s’écroule.

C’est précisément cette confiance qui est remise en question avec un bug de type Terrarium. Les utilisateurs de Terrarium doivent déterminer si leur propre pile est affectée. Ceux qui utilisent un autre bac à sable, comme Pyodide, E2B, nsjail, Firecracker-VMs ou une solution maison, devraient considérer ce bug comme une opportunité de réviser leur architecture. Les échappements de chaîne de prototypes ne sont pas uniques à Terrarium. La question est de savoir si votre bac à sable dispose d’une défense systématique contre ce type d’attaque ou s’il présente une faille similaire pour d’autres raisons.

Pour les équipes de sécurité, cela signifie concrètement que l’architecture des bacs à sable doit être un sujet de revue à part entière en 2026, et non un simple détail de framework secondaire. Ceux qui n’ont pas pensé leur pipeline de produits IA jusqu’à la couche d’exécution des conteneurs construisent sur du sable. Le bug Terrarium est une occasion désagréable de le reconnaître avant qu’un attaquant ne le fasse.

Ce que les opérateurs doivent faire concrètement maintenant

Inventaire : Quels services dans votre organisation utilisent Terrarium ou des chemins d’exécution de code ?
Atténuation : Conteneurs de bac à sable avec privilèges encore réduits, systèmes de fichiers en lecture seule, filtre de sortie strict
Secrets : Migrer les clés API de l’environnement de conteneur vers des tokens à durée de vie courte basés sur Vault
Détection : Surveiller les anomalies dans l’arborescence des processus de conteneurs et les destinations réseau inhabituelles

Ce qui n’est pas un filet de sécurité fiable

Filtrage d’entrée pur des snippets JavaScript sans contrôle de la chaîne de prototypes
Conteneurs sans profil seccomp, sans nouveaux privilèges ou sans paramètre Drop-All-Caps
Une seule sortie réseau sans liste de sorties autorisées
Absence de surveillance runtime des spawns de processus au sein du bac à sable

À quoi ressemble un plan de mitigation de 10 jours

La durée est délibérément courte. Les bugs de type sandbox avec un potentiel d’exécution de code root nécessitent une cadence claire. Ceux qui dépassent les dix jours de traitement ont un autre problème qu’une CVE (Common Vulnerabilities and Exposures).

Jour 1-2

Inventaire. Quels services utilisent Terrarium ? Rechercher dans les SBOM (Software Bill of Materials), scanner les images de conteneurs pour les manifestes Terrarium, interroger directement les équipes de développement. Bonus : examinez également quelles autres bibliothèques de sandbox sont en service.

Jour 3

Triage. Quels services sont accessibles publiquement, lesquels sont internes ? Lesquels utilisent des identifiants à courte durée de vie, lesquels utilisent des clés API à long terme ? Priorisation selon ces deux axes.

Jour 4-5

Durcissement des conteneurs. Systèmes de fichiers en lecture seule, profils seccomp, no-new-privileges, Drop-All-Caps. Resserrer la liste blanche de sortie. Déplacer les secrets des variables d’environnement vers des tokens à courte durée de vie via Vault ou AWS STS.

Jour 6-7

Détection et chasse. Règles SIEM (Security Information and Event Management) pour les spawns de processus suspects à partir de conteneurs de sandbox, chasse EDR (Endpoint Detection and Response) sur l’accès à /etc/passwd, anomalies dans les connexions sortantes. Vérifier rétrospectivement les 30 derniers jours.

Jour 8-9

Escalade et communication. Signaler au BSI (Bundesamt für Sicherheit in der Informationstechnik) et aux clients concernés si l’opération est multi-tenant. Signaler au délégué à la protection des données si des données personnelles sont traitées dans le contexte de la sandbox. Informer le conseil d’administration en parallèle.

Jour 10

Décision. Migration vers une sandbox alternative ou poursuite de l’exploitation avec un durcissement renforcé. Consigner le résultat dans la documentation d’architecture, planifier une révision dans 90 jours.

Ce que les équipes de sécurité peuvent tirer structurellement de l’affaire Terrarium

Deux leçons méritent réflexion. La première concerne le choix de l’architecture du bac à sable. Ceux qui ont besoin d’un bac à sable devraient, d’ici 2026, empiler au moins deux couches d’isolation. Un bac à sable linguistique comme Terrarium ou Pyodide constitue la première couche. Une limite de conteneur rigide ou une micro-VM Firecracker constitue la deuxième. À ce deuxième niveau, les bugs de la chaîne de prototypes peuvent encore s’échapper, mais ils n’ont pas de credentials de production ni d’accès au réseau. Pour les charges de travail sensibles, cette structure à deux couches est un minimum.

La deuxième leçon concerne la relation avec les fournisseurs de projets open-source dans l’écosystème de l’IA. Cohere est un fournisseur commercial, Terrarium un projet open-source largement utilisé. Le CERT/CC n’a pas réussi à coordonner la mise à disposition d’un patch. Ce n’est pas inhabituel pour des projets qui ne sont pas au centre des préoccupations de commit d’un fournisseur. Les équipes de sécurité devraient évaluer chaque composant de leur propre stack en fonction de la fiabilité de la réaction du fournisseur en cas d’urgence. La faille de Vercel via Context.ai OAuth du 22 avril était un exemple de problème structurel similaire dans la chaîne d’approvisionnement de l’infrastructure IA. Ce schéma se répète plus rapidement que le marché ne peut le résoudre.

Un troisième point, moins souvent abordé : les tests. Les bugs des bacs à sable IA ne sont pas détectés par les scans classiques des applications web. Ils nécessitent des vérifications spécialisées qui testent les attaques par chaîne de prototypes, les astuces d’héritage d’objets et les variantes d’échappement. Les tests de pénétration pour les produits IA devraient, d’ici 2026, inclure une section spécifique aux bacs à sable. Ceux qui achètent des vérifications selon le Top 10 OWASP classique et pensent que cela couvre l’application IA n’achètent qu’un demi-test. Ceux qui intègrent cette prise de conscience dans le prochain cycle de vérification trouveront des bugs avant que l’autre camp ne les découvre.

Comment traduire la résilience des bacs à sable dans la communication du conseil d’administration

Une partie du travail ne se fait pas dans la salle des serveurs, mais dans la salle du conseil. Lorsqu’un conseil d’administration pose la question de savoir si l’entreprise est affectée par la CVE-2026-5752, le responsable informatique doit avoir une réponse fiable. « Nous vérifions » ne suffit pas. La bonne réponse décrit en trois phrases quels services utilisent Terrarium, quelles mesures d’atténuation sont en place et quand la décision finale sera prise. Celui qui peut fournir cette structure en 24 heures dispose d’une gouvernance de sécurité fonctionnelle. Celui qui ne le peut pas sait où investir en 2026.

Pour le niveau du conseil de surveillance, une deuxième phrase est utile. Il n’existe pas de sécurité totale dans les environnements d’exécution de code, mais il existe des classes de risques définies et des tolérances aux erreurs acceptables. Une entreprise mature peut documenter sa tolérance aux erreurs et fournir des chiffres sur les incidents. Une entreprise immature parle de sécurité de manière abstraite, sans chiffres. La réaction de Terrarium est un bon levier de diagnostic pour déterminer ce niveau de maturité.

Un dernier point concerne les décisions en matière de personnel. La sécurité des bacs à sable AI est un domaine spécialisé qui rendra les talents plus rares en 2026 que la sécurité classique des applications web. Celui qui embauche précocement un ingénieur en sécurité senior spécialisé dans les bacs à sable ou qui passe par des contrats de services gérés sera mieux préparé pour le prochain incident. La pénurie sur le marché s’aggravera au cours des 18 prochains mois, car de plus en plus d’entreprises intègreront des fonctionnalités AI dans leurs produits. Investir maintenant permet de sécuriser les connaissances et les ressources.

Que les régulateurs pourraient déduire de l’affaire Terrarium

La réflexion réglementaire mérite un paragraphe à part. L’Acte européen sur l’IA (AI Act) n’aborde pas les pipelines de production d’IA au niveau des implémentations individuelles de sandbox. Cependant, pour les applications à haut risque, il exige une gestion des risques robuste. Un bug de sandbox non corrigé avec un score CVSS 9.3 rentre dans n’importe quelle matrice de risque raisonnablement bien conçue. Quiconque exploitera une application d’IA à haut risque en 2026 sans avoir de revue de sandbox documentée créera un déficit de conformité qui se révélera lors de la première série d’audits en 2027.

Parallèlement, le cadre de la NIS2 fonctionne selon des principes similaires. Les opérateurs d’installations essentielles et d’importance particulière doivent prendre des mesures techniques et organisation appropriées pour protéger les systèmes de réseau et d’information. L’architecture sandbox en fait partie. Une interprétation qui ne considère l’exécution de code IA que comme une nouvelle classe de fonctionnalités est insuffisante. Dès qu’un sandbox obtient des droits root dans le conteneur et a accès au réseau, il devient un système de réseau et d’information au sens de la directive.

Pour les responsables de la protection des données, l’affaire ouvre une autre discussion. Si les conteneurs sandbox ont accès aux variables d’environnement et aux destinations réseau internes, les données personnelles sont potentiellement accessibles, même si la sandbox ne communique formellement pas avec une base de données. L’article 32 du RGPD sur les mesures techniques et organisationnelles prend une dimension pratique avec de tels bugs. Celui qui peut documenter, sans incident, quelles données circulent vers quelle couche de conteneur dispose d’une base solide. Celui qui traite cela seulement après un incident se trouve dans une situation juridiquement plus délicate et doit fournir des justifications supplémentaires aux autorités de contrôle et à sa propre clientèle, qui n’auraient jamais été nécessaires avant un incident.

La leçon à en tirer est pragmatique : la documentation prime sur la perfection. Un bref aperçu de l’architecture sandbox avec un paragraphe par couche, un paragraphe sur les flux de données et un paragraphe sur les cycles de correction est préférable à un rapport parfait qui ne sera jamais finalisé.

Questions fréquentes

Comment puis-je détecter de manière fiable si mon application utilise Terrarium ?

Parcourir les SBOMs (Software Bills of Materials), vérifier les images de conteneurs à la recherche de paquets Cohere ou Terrarium, interroger directement les équipes de développement. Des outils d’analyse de dépendances automatiques comme Trivy, Snyk ou Grype trouvent généralement la référence de manière fiable, à condition que les SBOMs soient à jour.

Quelles alternatives à Terrarium seront établies en 2026 ?

E2B comme sandbox d’entreprise avec son propre modèle d’isolation, Pyodide pour les scénarios Python dans le navigateur, Firecracker-MicroVMs pour une séparation stricte des conteneurs, nsjail pour les sandbox spécifiques à Linux et Wasmtime pour l’isolation basée sur WebAssembly. Le choix dépend du cas d’utilisation et du profil de performance.

Est-il suffisant d’isoler uniquement le conteneur sans corriger la sandbox ?

Seulement si la deuxième couche est vraiment stricte, c’est-à-dire qu’aucune credential de production et aucun accès réseau étendu ne sont disponibles dans le conteneur sandbox. En pratique, la défense en profondeur (Defense-in-Depth) est meilleure : corriger ou remplacer la sandbox et renforcer en parallèle la couche de conteneur.

Que dit CERT/CC au sujet du manque de coordination avec le fournisseur ?

L’avis CERT/CC VU#414811 documente la tentative de contact et l’absence de mise à disposition correcte. Ce n’est pas unique dans les contextes open source et oblige les opérateurs à assumer leur propre responsabilité en matière de mitigation et de décision de poursuite des opérations.

Comment le bug affecte-t-il les environnements multi-tenants ?

Particulièrement critique, car un attaquant avec un accès root dans le conteneur sandbox peut potentiellement atteindre les données d’autres locataires si l’isolation est insuffisante. Les opérateurs multi-tenants devraient immédiatement préparer une communication client et procéder à une analyse forensique des 30 derniers jours.

Quel rôle joue le monitoring après la mitigation ?

Un rôle central. Même si le correctif ou la mitigation est efficace, des incertitudes persistent. Un monitoring spécifique des activités suspectes de la sandbox, des accès à /etc/passwd et des connexions de sortie de conteneur inhabituelles devrait être actif pendant au moins 90 jours.