Les failles du bac à sable d’OpenAI Codex transforment l’analyse des dépôts en exécution de commandes au niveau de l’hôte

Deux vulnérabilités d’OpenAI Codex permettaient à des opérations contrôlées par l’agent de sortir de leurs limites de sécurité prévues et d’affecter le système hôte du développeur. L’une fonctionnait même avec la politique de lecture seule la plus stricte, tandis que l’autre contournait les restrictions d’écriture limitées à l’espace de travail.

Les chercheurs ont baptisé ces failles Heapjack et Overpatch. Heapjack affecte Codex Desktop et peut permettre l’exécution de commandes hors bac à sable, sans demande d’autorisation ni avertissement visible. Overpatch affecte le Codex CLI open source et peut modifier des fichiers situés en dehors du répertoire de projet autorisé, notamment le fichier .zshrc de l’utilisateur.

Les deux vulnérabilités ont été signalées à OpenAI le 12 août 2026. OpenAI les a corrigées dans les huit jours, en publiant Codex Desktop build 26.818.21641 pour Heapjack et Codex CLI 0.149.0 pour Overpatch.

Aucun identifiant CVE ni score CVSS officiel n’a été communiqué. Aucun élément ne fait non plus état d’une exploitation de ces vulnérabilités dans la nature.

Heapjack brise la limite de sécurité du mode lecture seule

Heapjack est la plus grave des deux failles, car elle permet de passer de l’analyse de code en bac à sable à des opérations au niveau de l’hôte. Un développeur pouvait déclencher l’attaque en ouvrant dans Codex le dépôt d’une autre personne et en demandant à l’agent une information sur son contenu.

L’exploitation reste possible lorsque Codex est configuré en mode lecture seule. Avec cette politique, les utilisateurs s’attendent normalement à ce que l’agent inspecte les fichiers sans modifier le système ni exécuter d’opérations hors bac à sable sur l’hôte.

Heapjack cible en réalité le composant node_repl installé par Codex Desktop. Lors de l’installation, Codex Desktop ajoute ce composant au fichier de configuration global situé à l’emplacement suivant :

~/.codex/config.toml

Le composant est activé par défaut. Il ne nécessite pas d’activation distincte, et aucune option dédiée permettant de le désactiver n’a été communiquée. Comme la configuration est globale, les utilisateurs du Codex CLI peuvent eux aussi hériter de cet outil sans recevoir de nouvelle demande d’autorisation.

La capacité vulnérable n’est donc pas limitée à un seul dépôt ou à une session explicitement approuvée. Elle devient une composante de l’environnement Codex partagé de l’utilisateur.

Un jeton secret stocké à côté de JavaScript non fiable

La conception vulnérable de node_repl utilise un processus Node.js contenant deux contextes JavaScript distincts. Le premier est fiable et exécute du code d’OpenAI. Le second est non fiable et exécute du code contrôlé par l’agent.

Le contexte fiable communique avec un processus parent natif qui s’exécute en dehors du bac à sable. Il authentifie chaque requête à l’aide d’un jeton généré aléatoirement pour cette exécution.

La séparation des contextes JavaScript ne sépare toutefois pas leur mémoire sous-jacente. Les deux contextes utilisent le même tas Node.js, ce qui laisse le jeton d’authentification à la portée du code exécuté dans le contexte non fiable.

La preuve de concept de Heapjack appelle :

v8.getHeapSnapshot()

Elle examine ensuite l’instantané du tas V8 obtenu à la recherche de chaînes correspondant à la structure attendue, semblable à celle d’un UUID, du jeton. Trouver des valeurs candidates n’est toutefois qu’une première étape. L’exploitation doit également déterminer laquelle est valide.

Les chercheurs y sont parvenus en observant la réponse du processus parent à différentes requêtes. Un jeton incorrect provoquait un échec d’autorisation. Un jeton correct accompagné d’un argument invalide produisait une autre erreur de validation. Cette distinction servait d’oracle d’authentification et permettait de confirmer que le véritable jeton avait été récupéré.

Le contexte non fiable pouvait alors écrire une requête forgée dans le même canal de communication que celui utilisé par le composant fiable. Comme le message contenait le jeton valide, le processus parent hors bac à sable l’acceptait et exécutait l’opération demandée.

Dans l’attaque présentée, le processus parent appelait la commande système open pour lancer une application en dehors de l’arborescence des processus Codex. L’opération ne générait ni demande d’autorisation ni indication visible à l’écran dans Codex.

Les résultats techniques publiés ont également identifié les sockets Unix comme une cible potentiellement intéressante. Un socket Docker accessible pourrait être particulièrement critique, car il peut exposer des capacités allant bien au-delà de l’analyse ordinaire d’un dépôt. Les chercheurs ont aussi découvert un accès à un outil capable de modifier la configuration globale de Codex.

Overpatch étend les droits d’écriture au-delà de l’espace de travail

Overpatch s’attaque à un autre mécanisme de contrôle du Codex CLI open source. Il affecte le mode d’écriture dans l’espace de travail, qui est censé permettre à l’agent de modifier les fichiers du projet tout en empêchant les écritures ailleurs.

Avec cette politique, les tentatives directes d’écriture dans le répertoire personnel du développeur depuis un shell sont rejetées. Le contournement exploite à la place le propre outil apply_patch de Codex.

Le problème vient de la manière dont apply_patch détermine l’étendue des écritures autorisées. L’outil calcule les permissions à partir des répertoires parents des chemins inclus dans un correctif. Or ces chemins peuvent être fournis dans le contenu d’un correctif contrôlé par l’agent.

L’exploitation fonctionnelle comporte deux modifications. La première fait référence à /tmp, non pas nécessairement parce que l’attaquant doit y modifier un fichier, mais parce que ce chemin amène l’outil à élargir son périmètre d’autorisation jusqu’à la racine du système de fichiers.

La seconde suit un lien symbolique et ajoute une commande contrôlée par l’attaquant au fichier .zshrc du développeur. Avec l’entrée /tmp présente, l’écriture externe aboutit. Si cette entrée est supprimée, la même opération est refusée.

La commande injectée ne s’exécute pas immédiatement. Elle s’exécute en dehors du bac à sable Codex lorsque le développeur ouvre ultérieurement un terminal qui traite le fichier .zshrc.

Overpatch crée donc un mécanisme différé d’exécution et de persistance. L’agent semble travailler dans le projet, mais son opération de correctif modifie le comportement de démarrage du shell dans le répertoire personnel de l’utilisateur.

Les deux failles placent le contrôle au mauvais endroit

Heapjack et Overpatch utilisent des techniques différentes, mais leur faiblesse de conception sous-jacente est similaire : le composant restreint est autorisé à participer à l’application de ses propres restrictions.

Dans Heapjack, un secret d’authentification privilégié est stocké dans une mémoire partagée avec du JavaScript hostile. Le modèle de sécurité fait confiance à un jeton que l’environnement d’exécution non fiable peut récupérer et rejouer.

Dans Overpatch, le composant de correction déduit ses privilèges à partir de chemins fournis par l’agent même qu’il est censé contraindre. Un correctif hostile peut donc influencer le calcul servant à déterminer les emplacements où l’écriture est autorisée.

Il s’agit de problèmes de confiance mal définie plutôt que de simples failles d’analyse syntaxique. L’agent n’a pas besoin de briser directement un bac à sable du noyau s’il peut convaincre un mécanisme externe de confiance d’effectuer l’action sensible.

Des défaillances comparables de la limite de confiance des agents, impliquant Cursor, Codex, Gemini CLI et Antigravity de Google, ont été signalées en juillet 2026. Dans ces cas, l’agent pouvait rester techniquement dans son bac à sable tout en faisant exécuter par un outil plus fiable un fichier qu’il avait créé.

La leçon récurrente est précise : isoler le processus de l’agent dans un bac à sable ne suffit pas lorsque des outils auxiliaires, des mémoires partagées, des gestionnaires de configuration ou des exécuteurs externes acceptent des entrées influencées par l’agent.

Les développeurs doivent corriger les deux produits Codex

Les utilisateurs doivent installer Codex Desktop build 26.818.21641 ou une version ultérieure pour corriger Heapjack. Ils doivent également mettre à niveau Codex CLI vers la version 0.149.0 ou une version ultérieure pour corriger Overpatch.

L’installation d’une seule mise à jour ne suffit pas, car les vulnérabilités affectent des composants et des modes de sécurité différents.

En attendant le déploiement des mises à jour, les développeurs devraient éviter d’ouvrir dans Codex des dépôts provenant d’auteurs non fiables. L’analyse en lecture seule ne doit pas être considérée comme une protection complète contre les instructions fournies dans un dépôt ou l’exécution contrôlée par un agent.

Les équipes de défense et les utilisateurs concernés peuvent également vérifier :

• ~/.codex/config.toml à la recherche d’une configuration node_repl inattendue ou d’autres modifications non autorisées.
• .zshrc et les autres fichiers de démarrage du shell à la recherche de commandes ajoutées inhabituelles.
• Les appels à la commande système open effectués par Codex.
• Les accès inattendus à des sockets Unix, en particulier aux sockets du daemon Docker.
• Les opérations de correction impliquant /tmp, la racine du système de fichiers ou des liens symboliques menant en dehors du projet.
• Les applications lancées en dehors de l’arborescence de processus Codex attendue.

Heapjack peut laisser moins de traces évidentes, car il ne nécessite pas d’écriture classique dans un fichier et peut s’exécuter sans invite visible. Les données de télémétrie des processus, les journaux d’accès aux sockets et les traces d’exécution des commandes peuvent donc être plus utiles qu’une simple vérification du dépôt.

Overpatch est davantage susceptible de laisser une trace persistante dans .zshrc, mais la commande malveillante peut ne s’exécuter qu’à la prochaine session du terminal.

Aucune exploitation n’a été signalée

Aucun élément ne permet actuellement d’affirmer que des attaquants ont utilisé Heapjack ou Overpatch contre des utilisateurs de Codex avant la mise à disposition des correctifs. L’absence d’attaques signalées ne réduit pas l’exposition créée par l’ouverture d’un dépôt contrôlé par un attaquant.

Aucun identifiant CVE, score CVSS, plage de versions affectées ni entrée dans le catalogue des vulnérabilités exploitées connues de la CISA n’a été signalé. Les builds vulnérables précis précédant les versions corrigées ne sont pas connus non plus.

La référence opérationnelle est donc la version corrigée : Codex Desktop build 26.818.21641 et Codex CLI 0.149.0. Toute installation antérieure à ces versions respectives doit être mise à niveau, plutôt que de s’appuyer sur le mode lecture seule ou le mode d’écriture dans l’espace de travail pour se protéger.