OpenAI Codex : deux failles permettaient de sortir de la sandbox

Pourquoi Codex utilise-t-il une sandbox ?

Les agents de programmation ne se limitent plus à suggérer quelques lignes de code. Ils peuvent lire un projet, modifier des fichiers, exécuter des commandes, lancer des tests, utiliser Git et manipuler différents outils installés sur le poste du développeur.

Cette capacité d’action implique une contrainte essentielle : l’agent ne doit pas dépasser les permissions qui lui sont accordées. C’est le rôle de la sandbox, qui place les commandes locales dans un environnement restreint.

OpenAI explique que Codex s’exécute localement, notamment par l’intermédiaire du CLI, d’une extension d’environnement de développement ou de l’application de bureau. Un processus Codex dispose des permissions d’un véritable utilisateur, tandis que la sandbox réduit les capacités des commandes lancées par l’agent. En mode workspace-write, les écritures doivent notamment rester limitées au workspace autorisé.

Le fonctionnement attendu peut être résumé ainsi :

En août 2026, Oren Yomtov, chercheur chez Accomplish, affirme avoir découvert deux techniques contournant ces protections. L’entreprise indique les avoir signalées à OpenAI le 12 août 2026, puis avoir publié les détails techniques le 15 septembre. Selon Accomplish, les deux problèmes ont été corrigés dans les huit jours suivant leur signalement.

Overpatch : détourner l’outil de modification des fichiers

Codex dispose d’un outil nommé apply_patch, chargé d’appliquer automatiquement des modifications aux fichiers. Dans le mode workspace-write, cet outil doit limiter ses écritures au dossier du projet.

Selon l’analyse d’Accomplish, la vulnérabilité provenait de la manière dont apply_patch déterminait les dossiers auxquels accorder temporairement une permission d’écriture. Lorsqu’un chemin figurait dans un patch, l’outil autorisait l’écriture dans son dossier parent.

Les chercheurs expliquent qu’un chemin spécialement construit pouvait élargir ce périmètre. Dans leur démonstration, un chemin associé à /tmp faisait remonter la permission jusqu’à la racine /. Codex n’obtenait pas pour autant tous les privilèges administrateur, mais pouvait écrire dans des emplacements que la sandbox devait lui interdire.

Pourquoi une écriture hors du workspace est-elle dangereuse ?

La possibilité de modifier un fichier arbitraire peut avoir des conséquences plus importantes qu’une simple altération du projet. Les chercheurs présentent notamment un scénario impliquant ~/.zshrc, un fichier chargé lors du démarrage d’un nouveau shell Zsh.

Dans leur démonstration, un lien symbolique combiné au comportement de apply_patch permettait d’écrire dans ce fichier. Une commande injectée pouvait alors être exécutée ultérieurement, lorsque l’utilisateur ouvrait un terminal, dans son contexte normal et hors de la sandbox Codex.

Heapjack : un secret partagé dans le même espace mémoire

La seconde vulnérabilité repose sur un mécanisme différent. Elle concernait un composant JavaScript installé avec Codex Desktop et configuré par l’intermédiaire de ~/.codex/config.toml.

D’après Accomplish, ce composant utilisait un processus Node.js contenant deux contextes JavaScript V8 : l’un pour du code considéré comme fiable, l’autre pour du code moins fiable exécuté dans le cadre de l’agent. Un token aléatoire devait permettre au composant natif de distinguer les requêtes provenant du contexte fiable.

Le problème résidait dans le partage du même heap mémoire par les deux contextes V8. Le secret établissant la frontière de confiance était ainsi stocké dans un espace mémoire accessible depuis le processus qui exécutait également le code non fiable.

Un snapshot du heap pour retrouver le token

Les chercheurs indiquent avoir utilisé v8.getHeapSnapshot() afin de produire un instantané du heap V8. Le code pouvait ensuite rechercher des chaînes ressemblant à des UUID et tester les valeurs trouvées jusqu’à identifier le token attendu par le composant privilégié.

1. Le code exécuté dans le contexte non fiable génère un snapshot du heap.
2. Il recherche les valeurs susceptibles de correspondre au token d’authentification.
3. Le token récupéré sert à construire une requête conforme au format attendu.
4. Cette requête est envoyée au composant natif disposant de davantage de privilèges.

Contourner la frontière sans désactiver directement la sandbox

Heapjack ne supprimait pas nécessairement les restrictions du processus Node.js. Le code demeurait dans la sandbox, mais pouvait convaincre un processus Rust situé à l’extérieur d’effectuer une action à sa place.

Le composant natif recevait des requêtes au format JSON et vérifiait le token avant de les accepter. Une fois ce secret découvert, le contexte non fiable pouvait forger ses propres requêtes. La frontière de sécurité n’était donc pas détruite directement : elle était contournée par l’intermédiaire d’un composant privilégié.

Une démonstration en mode read-only

Accomplish indique avoir démontré Heapjack alors que Codex fonctionnait en mode read-only, censé empêcher l’agent d’écrire sur la machine. Les chercheurs affirment être parvenus à une exécution de commande non sandboxée sans demande d’autorisation à l’utilisateur.

Le composant natif pouvait notamment appeler la commande macOS open. L’application ainsi lancée démarrait ensuite par l’intermédiaire de launchd, hors de l’arbre de processus soumis à la sandbox Codex.

Un environnement n’est pas réellement en lecture seule si une interface qui lui reste accessible peut écrire ou exécuter des commandes à sa place.

Le danger particulier des dépôts non fiables

Les chercheurs évoquent le scénario d’un développeur utilisant un agent pour examiner un dépôt Git contrôlé par un tiers. Même sans demander explicitement l’exécution d’un programme, le dépôt peut contenir des fichiers ou des instructions conçus pour influencer le comportement de l’agent.

Avec une vulnérabilité permettant de franchir la sandbox, un dépôt malveillant devient un vecteur d’attaque potentiel. Accomplish affirme que, dans le scénario Heapjack testé, un dépôt spécialement préparé pouvait conduire à une exécution non sandboxée, y compris en mode read-only.

Ce risque rapproche la sécurité des agents de développement des problématiques de chaîne d’approvisionnement logicielle : le contenu d’un dépôt inconnu doit être considéré comme non fiable dès lors qu’un agent peut l’interpréter et orchestrer des outils à partir de celui-ci.

Il ne s’agit pas d’une IA qui « s’échappe »

Ces vulnérabilités ne décrivent pas un modèle d’intelligence artificielle décidant volontairement de contourner les protections de son système. Elles concernent l’infrastructure logicielle entourant l’agent : le mécanisme d’application des patchs, l’attribution des permissions, un composant Node.js, un processus Rust privilégié et la séparation entre les composants fiables et non fiables.

Codex s’appuie sur ces composants pour exécuter les actions proposées par le modèle. Une faiblesse dans l’un d’eux peut donc donner à l’agent davantage de capacités que prévu, comme une vulnérabilité de navigateur peut permettre à une page web de dépasser les limites qui lui sont normalement imposées.

Pourquoi la sécurité des agents IA est-elle complexe ?

Un agent de développement peut orchestrer Git, npm, Python, Node.js, Docker, SSH, un shell, un compilateur, des scripts du projet ou des outils MCP. Cette polyvalence augmente mécaniquement sa surface d’attaque.

Une sandbox ne se résume donc pas à trois permissions de lecture, d’écriture et d’exécution. Même limité à un dossier, un agent peut éventuellement atteindre un socket Unix, un daemon Docker, un gestionnaire de paquets, un serveur MCP, un outil système ou une application intermédiaire disposant de privilèges supplémentaires.

Chaque pont entre la sandbox et la machine hôte doit appliquer la même politique de sécurité. Heapjack montre qu’un processus correctement restreint peut rester dangereux lorsqu’il communique avec un composant qui ne l’est pas.

Deux failles différentes, un principe commun

Overpatch et Heapjack reposaient sur des mécanismes distincts, mais Accomplish souligne un point commun : une partie du mécanisme de contrôle restait trop proche de l’environnement non fiable.

Les vulnérabilités ont-elles été corrigées ?

Oui, selon le rapport d’Accomplish. L’entreprise indique avoir signalé les deux problèmes à OpenAI le 12 août 2026 et précise qu’ils ont été corrigés dans les huit jours suivants.

Ces numéros sont ceux communiqués par Accomplish dans son analyse. Pour le CLI, la version installée peut être vérifiée avec la commande suivante :

codex --version

Les utilisateurs ont intérêt à maintenir à jour le CLI comme l’application de bureau. Les agents de développement constituent désormais une couche logicielle sensible, dont les mécanismes d’isolation doivent être traités comme des composants de sécurité critiques.

Quelques bonnes pratiques avec les agents de développement

La mise à jour est la première mesure à appliquer, mais elle ne suffit pas à réduire tous les risques liés à une future vulnérabilité.

Un problème qui dépasse OpenAI Codex

Cette affaire ne concerne pas uniquement Codex. Les assistants de programmation deviennent progressivement des agents capables d’accomplir eux-mêmes des opérations autrefois réservées au développeur. Leur sécurité ressemble désormais davantage à celle d’un système d’exécution qu’à celle d’un simple chatbot.

Le modèle n’est qu’une couche de l’architecture. Autour de lui se trouvent l’agent, ses outils, la sandbox, le système d’exploitation, les secrets et l’infrastructure. Une faiblesse dans n’importe laquelle de ces couches peut modifier le niveau de sécurité réel de l’ensemble.

Le mode « read-only » ne doit pas créer un faux sentiment de sécurité

Pour l’utilisateur, une configuration en lecture seule signifie naturellement que l’agent peut consulter les données sans rien modifier. Pour que cette promesse soit effective, toutes les voies de modification indirecte doivent également être bloquées.

Une restriction appliquée au système de fichiers ne suffit pas si l’agent peut envoyer une requête à un processus privilégié capable d’accomplir l’action à sa place. C’est la différence entre une permission locale et une véritable frontière de sécurité.

Conclusion : sécuriser l’agent et tout son environnement

Overpatch et Heapjack illustrent la complexité croissante de la sécurité des agents de programmation. Dans le premier cas, un outil destiné à modifier du code pouvait élargir son périmètre d’écriture. Dans le second, un secret séparant du code fiable et non fiable pouvait être retrouvé dans une mémoire partagée, puis utilisé pour communiquer avec un composant privilégié.

Les vulnérabilités ont été corrigées selon Accomplish, mais leurs enseignements dépassent cet incident. À mesure que les agents manipulent des fichiers, des terminaux, des conteneurs, des API et des outils externes, la sandbox devient l’une des protections essentielles du poste du développeur.

La question ne porte donc plus seulement sur ce que l’IA est capable de générer, mais aussi sur ce que l’agent chargé de l’exécuter peut réellement atteindre sur la machine.

Sources et méthode Informations communiquées dans le brief

L’analyse des vulnérabilités repose sur le rapport technique publié le 15 septembre 2026 par Oren Yomtov, chercheur principal en sécurité chez Accomplish. L’entreprise indique avoir signalé Overpatch et Heapjack à OpenAI le 12 août 2026 et précise que les deux problèmes ont été corrigés dans les huit jours.

La présentation du fonctionnement général de la sandbox et du modèle de permissions de Codex s’appuie également sur la documentation technique d’OpenAI datée du 13 mai 2026, telle qu’elle est décrite dans le brief éditorial.