Deux façons de sortir du bac à sable OpenAI Codex : Heapjack et Overpatch

Le 15 septembre 2026, Oren Yomtov, chercheur principal en sécurité chez Accomplish AI, a publié un compte rendu technique sur deux moyens distincts de s'échapper du bac à sable qui entoure l'agent de codage Codex d'OpenAI. Les deux ont été signalés à OpenAI le 12 août 2026 et tous deux ont été corrigés en huit jours, selon son compte rendu : Heapjack dans Codex Desktop version 26.818.21641 et Overpatch dans Codex CLI 0.149.0. Heapjack est le plus grave des deux. Il n'exige rien de la personne attaquée, sinon d'ouvrir un dépôt dans Codex et de poser une question sur le code, et il s'exécute en lecture seule, le mode le plus strict proposé par le produit, sans demande d'approbation et sans rien afficher à l'écran. Aucun CVE n'a été attribué à l'une ou l'autre faille et aucun avis autonome d'OpenAI n'a été publié, selon la Cloud Security Alliance, et personne n'a été signalé comme ayant été lésé par elles. Il est répertorié aux côtés des autres entrées de l'année relatives au contrôle des agents dans l'archive des incidents d'IA, où chaque fiche indique ses documents source, son niveau de confiance et son indicateur de contestation.

Heapjack : le jeton se trouvait dans un tas que le côté non fiable pouvait lire

Codex Desktop ne demande aucune confirmation avant d'installer le composant que Yomtov a attaqué. Au moment de l'installation, il écrit un bloc node_repl dans le fichier de configuration global situé à ~/.codex/config.toml, et Yomtov rapporte qu'il n'existe ni opt-in ni réglage permettant de le désactiver. Comme l'entrée réside dans la configuration partagée plutôt que dans un choix propre à chaque utilisateur, un simple utilisateur de Codex CLI hérite du même outil sans jamais avoir été consulté.

L’outil node_repl est lui-même un programme natif qui s’exécute en dehors du sandbox. Il peut ouvrir des applications, se connecter à des sockets Unix et modifier le fichier de configuration global. Ce qu’il démarre à l’intérieur du sandbox est un unique processus Node.js, et ce processus contient deux contextes d’exécution JavaScript : un contexte de confiance contenant le code propre à OpenAI, et un contexte non fiable exécutant tout ce qu’on a demandé à l’agent de faire.

Le contexte de confiance prouve qu’il est digne de confiance en présentant un jeton aléatoire, généré à chaque exécution. C’est censé être la frontière entre les deux contextes. Or, ce n’en est pas une, car les deux contextes vivent dans un seul isolat V8 partageant un unique tas mémoire, de sorte que le jeton est une chaîne résidant en mémoire que le code non fiable peut lire. Un commentateur réagissant à la divulgation sur X a formulé le point plus crûment, dans une phrase citée par BleepingComputer : « Les contextes V8 isolent les variables globales, pas la mémoire, donc le bac à sable était en réalité une promesse que le tas n’a jamais acceptée. » Il s’agit d’une caractérisation, pas d’une preuve ; la preuve, c’est la preuve de concept.

L’exploit de Yomtov fait exactement ce que cette description implique. Du JavaScript non fiable appelle v8.getHeapSnapshot(), analyse l’instantané obtenu à la recherche de chaînes ayant la forme d’un UUID, et teste chaque candidat. Une mauvaise supposition renvoie « not authorized ». Un jeton correct associé à un argument invalide renvoie quant à lui une véritable erreur de validation. La différence entre les deux messages d’erreur constitue l’oracle qui identifie la bonne valeur.

Avec le jeton en main, le processus en bac à sable écrit sa propre requête JSON sur le descripteur de fichier 1 — le même pipe stdout que le contexte de confiance utilise pour atteindre le parent natif. Le parent valide le jeton, en trouve un valide, et effectue le travail. Dans la preuve de concept, ce travail était la commande système open, qui transmet la requête à launchd et lance l'application entièrement en dehors de l'arborescence de processus de Codex. Le même jeton autorise des connexions à des sockets Unix arbitraires, dont un socket de démon Docker, et permet d'atteindre un outil pour modifier le fichier de configuration global.

Tout cela s'exécute en lecture seule, le mode qu'un utilisateur prudent choisit précisément parce que le dépôt qu'il a sous les yeux n'est pas fiable. Aucune demande d'approbation n'est apparue à aucun moment. Le scénario concret est bref : ouvrir un dépôt cloné dans Codex, en mode lecture seule, et poser une question sur le code. Celui qui a écrit ce dépôt obtient l'exécution de commandes sans sandbox sur la machine, et rien à l'écran ne le signale.

Overpatch : un outil de correctif qui accordait le parent de tout ce qu’il touchait

La seconde faille se trouve dans Codex CLI, l’agent en ligne de commande open source, et il s’agit d’un bug de permissions plutôt que d’un bug de mémoire. En mode workspace-write, l’agent peut écrire à l’intérieur du dossier du projet et nulle part ailleurs ; une commande shell visant le répertoire personnel est refusée. L’outil apply_patch était censé maintenir cette limite. Au lieu de cela, il tirait ses permissions des chemins nommés dans le patch qu’il appliquait, et accordait un accès en écriture au répertoire parent de chacun d’eux.

Nommez un chemin sous /tmp dans un patch et l’autorisation s’élargit jusqu’à la racine du disque, car le parent de /tmp est /. Voilà toute l’astuce.

L'exploit fonctionnel utilise deux entrées dans un seul patch. La première désigne /tmp et ne sert à rien — elle échoue, car un fichier ne peut pas écraser un répertoire — et n'existe que pour élargir l'autorisation. La seconde ajoute une ligne à .zshrc via un lien symbolique vers le répertoire personnel. Supprimez la première entrée et l'écriture est refusée. Conservez-la, et le prochain terminal que le développeur ouvre exécute la ligne de l'attaquant sans bac à sable, le bac à sable n'intervenant plus du tout.

Cela fait d’Overpatch un bug de persistance plutôt qu’un phénomène ponctuel. Le fichier de démarrage empoisonné s’exécute de nouveau à chaque shell que le développeur ouvre, jusqu’à ce que quelqu’un lise .zshrc et remarque la ligne ajoutée — c’est pourquoi les recommandations de la Cloud Security Alliance sont de partir à la recherche d’un tel mécanisme plutôt que d’attendre un symptôme.

Les deux bugs placent le mécanisme de contrôle à l’intérieur même de ce qu’il est censé contrôler.

La manière dont Yomtov présente les choses est la partie qui va au-delà de Codex. apply_patch calculait ses propres autorisations à partir d’une entrée fournie par un attaquant. node_repl gardait en mémoire, que le code non fiable pouvait lire, le secret séparant le code de confiance du code non fiable. Dans chaque cas, on a dit au bac à sable, de l’intérieur, de laisser passer quelque chose.

La forme n’est pas nouvelle. BleepingComputer, qui a rapporté la divulgation le 20 septembre 2026, note qu’en juillet 2026, des chercheurs de Pillar Security ont démontré la même idée sur Cursor, Codex, Gemini CLI et Antigravity de Google, où un agent qui reste à l’intérieur de son bac à sable écrit un fichier qu’un outil de confiance situé hors du bac à sable exécute ensuite. Ce qui distingue la paire Codex, c’est le contournement en lecture seule dans Heapjack et l’absence de tout paramètre permettant de désactiver le composant qui le porte.

Les corrections, et ce qu'OpenAI a dit et n'a pas dit

OpenAI a corrigé Heapjack dans Codex Desktop build 26.818.21641 et Overpatch dans Codex CLI 0.149.0, selon Accomplish. Les deux correctifs ont été déployés dans les huit jours suivant le rapport du 12 août — soit le 20 août, à en croire cette chronologie — et Yomtov a attribué à OpenAI le mérite de ce revirement.

OpenAI n'a publié aucun avis de sécurité autonome pour l'une ou l'autre faille, et aucun identifiant CVE n'a été attribué ; la Cloud Security Alliance consigne ces deux absences dans une note de recherche datée du 22 septembre 2026. Sollicité pour un commentaire, un porte-parole d'OpenAI a déclaré à BleepingComputer : « Nous remercions les chercheurs de nous avoir contactés et de nous avoir fait part de leurs conclusions. Nous avons traité les deux problèmes en août, mais nous renforçons continuellement nos bacs à sable, avec de récentes mises à jour qui resserrent les contrôles sur les emplacements où les agents peuvent écrire des fichiers et étendent les tests de ces protections sur toutes les plateformes. »

Cette déclaration confirme les correctifs et ne dit rien des mécanismes. Elle ne précise pas si les changements d’août ont supprimé le schéma de conception ou fermé les deux voies spécifiques qui en découlaient. Personne en dehors d’OpenAI ne l’a dit non plus.

Qu’est-ce qui est établi, et qu’est-ce qui repose sur un seul chercheur ?

Les archives classent cette entrée comme un résultat de recherche, avec une gravité élevée, une région mondiale et un niveau de confiance B — documenté, mais à partir d’une source unique ou secondaire — non contesté, sans aucun préjudice réel consigné. Ce niveau est le bon prisme pour lire la suite de cet article, car la fracture entre ce que plusieurs parties confirment et ce que seul l’auteur de la découverte affirme traverse tout le récit.

Établi, au sens où plus d’une partie le dit :

• La divulgation existe et est datée. L'article de Yomtov a été publié le 15 septembre 2026 ; les deux failles ont été signalées à OpenAI le 12 août 2026 et, selon lui, corrigées en huit jours.

• OpenAI confirme avoir agi en août. Son porte-parole a déclaré à BleepingComputer que les deux problèmes avaient été traités, ce qui corrobore la chronologie de signalement et de correction indépendamment du découvreur, même si l’entreprise n’a publié aucun avis ni aucun compte rendu technique de son propre chef.

• Les versions corrigées sont indiquées de manière cohérente. Le build 26.818.21641 pour Codex Desktop et la version 0.149.0 pour Codex CLI sont donnés par Accomplish, repris par BleepingComputer et mentionnés dans un avis du 22 septembre 2026 du Uganda National Computer Emergency Response Team and Coordination Center, qui a classé les deux « Red ».

• Aucune CVE, aucun avis du fournisseur et aucune exploitation signalée. La note de la Cloud Security Alliance du 22 septembre 2026 consigne l’absence tant d’une CVE que d’un avis OpenAI distinct, et ne signale aucun cas confirmé où une organisation aurait constaté que le mécanisme de persistance d’Overpatch était en place.

• L’archive ne conteste aucun de ces éléments. La fiche est marquée comme non contestée, et son niveau de confiance reflète le mode de sourçage plutôt qu’un désaccord sur les faits.

Non établi, ou établi par personne d'autre que celui qui l'a trouvé :

Le détail du mécanisme est celui de Yomtov. L’oracle d’instantané de tas, le descripteur de fichier partagé, l’autorisation accordée sur le répertoire parent — tout cela provient de son analyse et de sa preuve de concept. La Cloud Security Alliance, dont la note est le résumé tiers le plus détaillé en circulation, décrit la synthèse de son compte rendu et de la couverture de BleepingComputer, et ne déclare pas avoir reproduit l’un ou l’autre des exploits ni testé l’un ou l’autre des correctifs. L’avis de CERT.UG compile les mêmes éléments.

• Les plages de versions vulnérables n’ont jamais été publiées. Seules les versions de correction sont nommées, si bien qu’aucune liste n’indique quelles versions antérieures présentaient chaque faille.

• On ne précise pas si une installation corrigée est à l’abri de cette catégorie de bogues, plutôt que seulement de ces deux cas. La formule d’OpenAI « renforcer continuellement nos sandboxes » est un engagement général, et non une affirmation concernant un mécanisme précis.

• Personne n'a été signalé comme ayant exploité l'une ou l'autre de ces failles. Il s'agit d'une absence de signalement, et non d'une absence constatée, et la preuve de concept montre que la voie Heapjack ne laisse rien à l'écran qui permette à l'utilisateur de s'en apercevoir.

Ce sur quoi un utilisateur peut agir

Toute personne utilisant une version de Codex Desktop antérieure à 26.818.21641, ou une version de Codex CLI antérieure à 0.149.0, se trouve du côté vulnérable de la limite définie par Accomplish, et la mise à jour est le seul remède proposé par la divulgation. Au-delà, la Cloud Security Alliance recommande d’auditer les sessions Codex Desktop passées ayant impliqué des dépôts non fiables, afin d’y rechercher launchd ou une activité open et des connexions au socket Docker, ainsi que de lire les fichiers de démarrage du shell — .zshrc, .bashrc et leurs équivalents — pour y rechercher des commandes qui ont été ajoutées plutôt qu’écrites par l’utilisateur.

La même note déconseille de considérer le mode lecture seule comme une protection lorsque le dépôt n’est pas fiable, ce qui est la conclusion que Heapjack impose de son propre chef. Ses recommandations structurelles vont plus loin : une isolation physique des processus et de la mémoire au lieu de secrets partagés et de conventions, des identifiants maintenus hors de portée de l’agent, et des correctifs faisant référence à des chemins extérieurs au projet traités comme suspects au premier regard. Ce sont des propositions émanant d’un tiers. On ne sait pas publiquement si OpenAI en a adopté certaines au-delà des deux incréments de version.

Pour finir, deux choses méritent d’être distinguées. L’une est une paire de bugs dans un agent de codage largement utilisé, signalés le 12 août 2026, corrigés en huit jours et fermés en deux numéros de build. L’autre est la question de conception que Yomtov nomme — de savoir si un bac à sable peut être imposé par le code qu’il est censé contenir — et ce n’est pas une question à laquelle un numéro de version répond. Ni Accomplish ni OpenAI n’a déclaré que les changements d’août règlent cette question.