# OpenAI Codex: two flaws allowed sandbox escapes > Two flaws fixed in OpenAI Codex allowed its sandbox to be bypassed through writes outside the workspace or a privileged component. AI & cybersecurity ## OpenAI Codex: two flaws allowed sandbox escapes Two vulnerabilities discovered in OpenAI Codex allowed its sandbox to be bypassed. Overpatch allowed writes outside the workspace, while Heapjack could lead to the execution of non-sandboxed commands. ![openai codex two flaws sandbox escape overpatch heapjack](https://sdx-development.com/media/News/openai-codex-deux-failles-sortie-sandbox-overpatch-heapjack.webp?v=1789916469) [AI & cybersecurity](https://sdx-development.com/en/news/ai-cybersecurity)Published on 20 September 2026 at 17:08 Des chercheurs en sécurité ont découvert deux moyens de contourner les protections de la sandbox d’OpenAI Codex. Baptisées **Overpatch** et **Heapjack**, ces techniques pouvaient donner au code exécuté par l’agent des capacités normalement interdites. Selon leur rapport, les vulnérabilités ont depuis été corrigées. À retenir ## Deux chemins distincts vers un même risque Overpatch permettait d’étendre le périmètre d’écriture au-delà du workspace. Heapjack pouvait exploiter un secret présent dans une mémoire partagée pour solliciter un composant natif exécuté hors 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 : 01 ### Demande de l’utilisateur L’utilisateur confie à Codex une tâche impliquant la lecture d’un projet ou l’exécution d’outils. 02 ### Exécution restreinte Les commandes de l’agent sont placées dans la sandbox et leurs processus enfants doivent hériter de ses restrictions. 03 ### Périmètre autorisé Les opérations permises s’effectuent dans le workspace et selon le mode de sécurité choisi. 04 ### Refus des actions interdites Une tentative d’écriture hors du projet ou d’accès à une capacité non autorisée doit être bloquée. 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. Comportement attendu ### Une écriture limitée au projet ` apply_patch ` reçoit une modification, vérifie sa destination et n’autorise que les fichiers situés dans le workspace. Contournement ### Un chemin élargit la permission Un chemin conçu pour influencer le calcul du dossier parent étend la zone accessible au-delà du projet. ### 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. Conséquence ## Une écriture peut préparer une exécution différée Le risque ne se limite pas à la modification d’un fichier extérieur au projet. Si ce fichier est ensuite interprété par un shell ou une autre application, l’écriture peut devenir un moyen d’exécuter ultérieurement une commande hors de la sandbox. ## 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. Overpatch ### Les données contrôlent le périmètre ` apply_patch ` recevait les chemins et s’en servait pour déterminer les permissions. Un chemin spécialement construit pouvait donc élargir ces permissions. Heapjack ### Le secret partage la mémoire Le contexte fiable détenait un token, mais le contexte non fiable partageait le même heap et pouvait tenter de retrouver cette valeur. ## 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. | Composant | Vulnérabilité | Version corrigée indiquée | | --- | --- | --- | | Codex CLI | Overpatch | 0.149.0 ou ultérieure | | Codex Desktop | Heapjack | Build 26.818.21641 ou ultérieur | 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é. ## Réduire l’exposition du poste de développement 1. **Mettre à jour les agents et leurs CLI.** Une sandbox obsolète peut rendre inefficaces les restrictions affichées dans l’interface. 2. **Limiter les secrets disponibles.** Les tokens Git, clés cloud et identifiants doivent disposer de permissions minimales et, si possible, d’une durée de vie courte. 3. **Traiter les dépôts inconnus comme non fiables.** Leur contenu peut chercher à influencer un agent capable d’exécuter des outils. 4. **Réduire les outils accessibles.** MCP, Docker, sockets système et services externes étendent la surface d’attaque. 5. **Ajouter une couche d’isolation.** Une machine virtuelle ou un environnement jetable crée une frontière supplémentaire pour les projets réellement non fiables. 6. **Ne pas se fier uniquement au mode lecture seule.** Les processus et interfaces privilégiés accessibles indirectement doivent également être pris en compte. ## 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. AI & CYBERSECURITY ## Reliable AI agents start with a controlled security framework. Architecture, permissions, sandboxing and human validation turn automation into a useful capability without exposing your production systems. - Clearly defined scope and permissions - Isolated execution and controlled sensitive actions - Integrated testing, traceability and human validation [Secure your AI project](https://sdx-development.com/en/contact)[Explore AI & RAG](https://sdx-development.com/en/ai-rag-automation) --- [View the HTML page](https://sdx-development.com/en/news/ai-cybersecurity/openai-codex-two-flaws-allowed-sandbox-escapes)