Deux failles permettent de sortir du sandbox de Codex et d’exécuter des commandes sur la machine du développeur
Des chercheurs ont trouvé deux voies de sortie du sandbox de Codex d’OpenAI, dont une capable d’exécuter des commandes sur la machine depuis le mode le plus verrouillé, sans invite ni trace à l’écran. Mettez à jour Codex et ne faites jamais tourner un agent de code avec un accès au socket Docker ou au répertoire personnel.
12 août 2026. Oren Yomtov, chercheur chez Accomplish AI, signale deux failles du sandbox de Codex à OpenAI. 20 septembre 2026. Les détails techniques sont publiés, les deux failles ayant été corrigées en huit jours. 26.818.21641. La build de Codex Desktop qui corrige la plus grave. Pourquoi c’est important : ouvrir le dépôt de quelqu’un d’autre dans Codex et poser une question sur son code suffisait à donner à l’auteur du dépôt une exécution de commandes non sandboxée sur votre machine.
Heapjack : lire le jeton dans la mémoire partagée
La plus grave des deux failles, baptisée Heapjack, transforme une action banale en exécution de code à distance. Codex est l’agent de codage d’OpenAI, disponible en ligne de commande et en application de bureau. Comme ses concurrents, il exécute les actions du modèle dans un sandbox pour que du code non fiable ne touche pas le système. Heapjack fait tomber cette frontière de l’intérieur.
La cible est un composant nommé node_repl, que Codex Desktop écrit dans le fichier global ~/.codex/config.toml à l’installation. Il n’y a ni opt-in ni réglage pour le désactiver, et comme l’entrée vit dans la configuration partagée, les utilisateurs du simple Codex CLI héritent du même outil sans jamais avoir été prévenus.
node_repl lance un unique processus Node.js qui contient deux contextes JavaScript distincts. L’un est de confiance, il contient le code d’OpenAI. L’autre n’est pas de confiance, il exécute le code de l’agent. Le contexte de confiance prouve son identité en présentant un jeton aléatoire généré à chaque exécution. Le problème : les deux contextes vivent dans le même processus Node et partagent le même tas mémoire. Le jeton n’est donc qu’une chaîne posée en mémoire, que le côté non fiable peut lire.
L’attaque est alors mécanique. Le code non fiable prend un instantané du tas avec v8.getHeapSnapshot() et essaie chaque chaîne qui ressemble à un UUID. Une mauvaise supposition répond « not authorized ». Un jeton correct avec un mauvais argument répond par une vraie erreur de validation — ce qui révèle que le jeton est le bon. Une fois le jeton connu, le code non fiable écrit sa propre requête sur le même pipe que le contexte de confiance utilise pour parler au processus parent natif, non sandboxé. Le parent vérifie le jeton, le voit valide, et exécute.
La preuve de concept utilise la commande système open pour lancer une application entièrement hors de l’arbre de processus de Codex. Le même accès atteint n’importe quel socket Unix — le socket du démon Docker étant la cible évidente — ainsi qu’un outil d’édition du fichier de configuration global. Le tout en mode lecture seule, le mode sandbox le plus strict, celui où l’agent n’est censé rien écrire du tout.
Overpatch : écrire hors du dossier via le parent du chemin
La seconde faille, Overpatch, siège dans le Codex CLI open source. En mode workspace-write, l’agent ne peut écrire que dans le dossier du projet, et une commande shell visant le répertoire personnel est refusée. Les chercheurs ont obtenu de l’outil de patch de Codex, apply_patch, qu’il y écrive quand même.
apply_patch accorde un accès en écriture au dossier parent de chaque chemin nommé dans un patch. Nommer /tmp, et il accorde l’accès en écriture à la racine du disque. L’exploit fonctionnel utilise un patch à deux changements : l’un nomme /tmp et ne fait rien d’utile sinon élargir la permission ; l’autre ajoute une ligne à .zshrc à travers un lien symbolique pointant vers le répertoire personnel.
Retirez le premier changement, et l’écriture est refusée. Avec lui, le prochain terminal que le développeur ouvre exécute la ligne de l’attaquant, hors sandbox. Le mécanisme de contrôle calcule ses propres permissions à partir d’une entrée fournie par l’attaquant, puis se plie à ce qu’il vient de calculer.
Le même défaut, deux fois
Les deux bugs partagent une même forme : le mécanisme de contrôle vivait à l’intérieur de la chose qu’il était censé contrôler. apply_patch déduisait ses permissions d’une entrée fournie par l’attaquant. node_repl gardait le secret qui sépare le code de confiance du code non fiable dans la même mémoire que le code non fiable. Dans les deux cas, le sandbox s’est vu dire, de l’intérieur, de laisser passer quelque chose.
Un commentaire sous la publication de Yomtov résume le défaut avec une formule qui mérite de rester : « V8 contexts isolate globals, not memory » — les contextes V8 isolent les variables globales, pas la mémoire. Le sandbox était « une promesse que le tas n’a jamais tenue ». Un autre lecteur qualifie la frontière de confiance de « séparateur de pièce » : il délimite, mais il n’arrête rien.
Un problème de classe, pas un incident isolé
La faille n’est pas propre à OpenAI. En juillet 2026, les chercheurs de Pillar Security avaient démontré la même idée sur Cursor, Codex, Gemini CLI et Antigravity de Google : un agent qui reste dans son sandbox écrit un fichier qu’un outil de confiance, situé hors du sandbox, exécute ensuite. Le défaut est structurel, il tient à la façon dont ces agents emboîtent un interpréteur non fiable dans un outillage de confiance.
La nouveauté de Heapjack est ailleurs : elle ne repose pas sur une chaîne d’outils, mais sur un défaut de conception du sandbox lui-même — un secret de confiance placé dans une mémoire partagée avec du code non fiable. C’est une erreur que des sandbox matures, fondés sur des frontières de processus ou de machine virtuelle, ne commettent pas.
Pour un utilisateur, la leçon est directe : ces agents téléchargent et exécutent du code que vous n’avez pas écrit — celui d’un dépôt inconnu, d’une suggestion de modèle, d’une bibliothèque. Le sandbox est votre dernière ligne de défense, et il est, au mieux, jeune.
Ce que cela change pour qui utilise un agent de code
OpenAI a corrigé Heapjack dans la build 26.818.21641 de Codex Desktop, et Overpatch dans Codex CLI 0.149.0. Les utilisateurs doivent passer à ces versions ou à des versions plus récentes. Yomtov crédite OpenAI d’avoir résolu les deux failles en huit jours après son signalement.
Mais la mise à jour ne suffit pas. Tant que ces sandbox partagent la mémoire ou déduisent leurs permissions d’entrées non fiables, la frontière reste fragile. Les précautions minimales sont de ne jamais exécuter un agent de code avec un accès au socket Docker, aux clés SSH, ou au répertoire personnel contenant des fichiers de configuration sensibles. Un agent qui ouvre un dépôt tiers devrait tourner dans un environnement jetable, sans accès au reste de la machine.
La question de fond dépasse le correctif : un outil qui exécute du code non fiable sur votre machine, avec vos identités et vos accès, est un canal d’attaque à part entière. Le fait que le mode le plus verrouillé — la lecture seule — ait suffi à Heapjack montre que la sévérité d’un mode ne garantit rien si la frontière elle-même est poreuse.
Verdict
Si vous utilisez Codex, mettez à jour immédiatement vers Codex Desktop 26.818.21641 et Codex CLI 0.149.0 ou plus récent, et considérez toute version antérieure comme exposée. Si vous laissez vos équipes utiliser des agents de codage, isolez leur exécution : pas de socket Docker, pas de clés SSH, pas de répertoire personnel réel, et un environnement jetable pour tout dépôt tiers. Si vous concevez un outil qui exécute du code non fiable, retenez la règle que Heapjack illustre : la frontière de confiance ne doit jamais partager la mémoire avec ce qu’elle isole, et le mécanisme de contrôle ne doit jamais calculer ses permissions à partir d’une entrée contrôlée par l’attaquant.