For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/fr/articles/openai-codex-security-issues-curated-plug-d8ba6dc7.md.
OpenAI utilise l’IA pour détecter des vulnérabilités logicielles avec Codex Security et Patch the Planet, tandis que Codex a lui-même été co...
OpenAI a consacré une grande partie de l’année 2026 à approfondir l’utilisation de l’IA dans la sécurité logicielle.
En mars, l’entreprise a lancé Codex Security en préversion de recherche, sous la forme d’un agent de sécurité applicative conçu pour détecter, valider et contribuer à corriger les vulnérabilités. En juin, OpenAI a présenté Patch the Planet, une initiative Daybreak menée avec Trail of Bits pour aider les mainteneurs de projets open source à identifier et corriger les problèmes de sécurité. Fin juillet, OpenAI a également publié le CLI open source Codex Security et son SDK TypeScript.
La question de la sécurité autour de Codex revêt donc une importance particulière.
Codex n’est pas seulement un modèle de génération de code. Il s’agit d’un agent de programmation connecté localement et au cloud, capable de lire des dépôts, de modifier des fichiers, d’appeler des outils, d’exécuter des commandes, de charger des plugins, de se connecter à des services MCP et de fonctionner dans des environnements de développement qui contiennent souvent du code source et des identifiants.
En septembre, un article de BAAI/New智元 a présenté une nouvelle allégation de sécurité concernant Codex, attribuée à 360 Tulongfeng, un système chinois de test de sécurité de l’IA. Selon cet article, le problème concernait le mécanisme de synchronisation des plugins Git sélectionnés de Codex et pouvait contourner la limite d’approbation que les utilisateurs s’attendent normalement à voir appliquée avant les actions sensibles.
Cette nouvelle découverte spécifique de 360 n’a pas été accompagnée d’un avis public d’OpenAI ni d’un rapport technique public détaillé démontrant de manière indépendante qu’il s’agit d’un zero-day distinct. Cependant, le risque général décrit dans l’article est réel : des rapports publics antérieurs sur Codex avaient déjà montré que la synchronisation initiale des plugins sélectionnés pouvait s’exécuter en dehors du bac à sable du modèle et, dans certaines configurations Git, agir sur le dépôt de l’utilisateur au lieu du cache des plugins.
Cette distinction est importante. Cet article conserve la structure du récit original tout en séparant les incidents publics confirmés, les résultats rapportés par les chercheurs et les allégations attribuées aux fournisseurs.
OpenAI a présenté Codex Security le 6 mars 2026.
Le produit est conçu pour établir le contexte d’une base de code, identifier les faiblesses de sécurité, vérifier la pertinence d’un résultat et proposer des correctifs. Contrairement à un simple analyseur de motifs, OpenAI le présente comme un système de sécurité agentique capable de raisonner à l’échelle d’un projet et de réduire les faux positifs.
OpenAI a ensuite élargi cette démarche avec Patch the Planet.
Cette initiative associe la recherche de vulnérabilités assistée par l’IA à une revue humaine, afin que les mainteneurs reçoivent des résultats vérifiés pouvant être accompagnés de correctifs et de tests.
Le message sous-jacent est simple : l’IA peut accélérer à la fois la création de logiciels et la découverte de vulnérabilités. Les équipes de défense ont donc besoin de méthodes plus rapides pour examiner et corriger le code.
L’ironie soulignée par l’article source est que le même type d’infrastructure d’agent de programmation utilisé pour trouver les failles des autres est également devenu une cible précieuse pour les chercheurs en sécurité.
L’article source attribue une nouvelle vulnérabilité de Codex au système Tulongfeng de 360 et indique que le problème est lié au mécanisme de synchronisation des plugins Git sélectionnés de Codex.
En temps normal, Codex s’appuie sur plusieurs contrôles de sécurité :
Le risque apparaît lorsque du code de démarrage ou d’infrastructure s’exécute en dehors du même bac à sable que celui utilisé pour les commandes dirigées par le modèle.
Cette distinction est déjà visible dans les rapports publics consacrés aux problèmes de Codex.
Un ticket GitHub publié en juillet a documenté un cas dans lequel la synchronisation initiale des plugins sélectionnés lançait des commandes Git sans isoler complètement les variables d’environnement GIT_* propres au dépôt. Lorsque Codex était démarré dans certains contextes de hooks Git ou de worktrees, la synchronisation pouvait agir sur le dépôt de l’utilisateur au lieu du cache de plugins prévu.
Le rapporteur a notamment indiqué que --sandbox read-only ne suffisait pas à contenir ce comportement, car la synchronisation relevait de l’infrastructure de démarrage de Codex, et non d’une commande exécutée par le modèle à l’intérieur du bac à sable.
OpenAI a intégré le 24 juin 2026 un correctif intitulé Isolate curated plugin sync Git environment. Les tickets publics concernant les versions 0.142.x affectées et les premières versions 0.143 montraient que le correctif était d’abord présent dans main avant d’être intégré aux versions stables.
Cet historique public confirme le point principal de l’article : les limites de sécurité d’un agent doivent couvrir sa propre infrastructure, et pas seulement les commandes shell demandées directement par le modèle.
En revanche, il reste difficile de déterminer si l’allégation de septembre attribuée à Tulongfeng correspond à un chemin d’exploitation distinct, allant au-delà du problème public antérieur d’isolation de la synchronisation au démarrage. En l’absence d’un avis public, d’un CVE ou d’une analyse technique publiée par OpenAI ou 360, cette version ne présente pas cette allégation de « nouveau zero-day » comme un fait établi indépendamment.
Un modèle de sécurité courant pour Codex ressemble à ceci :
Les recommandations actuelles d’OpenAI en matière de sécurité des agents suivent le même principe général : les effets secondaires à haut risque doivent être limités de manière indépendante et, si nécessaire, suspendus pour faire l’objet d’un contrôle humain explicite.
Le problème est qu’une demande d’autorisation ne peut protéger une action que si celle-ci passe effectivement par le chemin de code qui applique cette demande.
Si un programme de mise à jour en arrière-plan, un synchroniseur de plugins, un processus auxiliaire ou un autre sous-système de confiance effectue une opération en dehors de ce chemin, l’interface d’approbation visible peut ne pas constituer la véritable limite de sécurité.
C’est l’un des enseignements les plus importants des rapports de vulnérabilités concernant Codex en 2026.
Le modèle de menace d’un outil de programmation doté d’IA ne se limite plus à la question suivante :
« Le modèle va-t-il demander l’exécution d’une commande dangereuse ? »
Il faut également se demander :
« Quelles parties de la plateforme de l’agent peuvent modifier des fichiers, lancer des processus, récupérer du code, charger des plugins, lire des identifiants ou interagir avec Git avant ou en dehors du flux normal d’approbation du modèle ? »
L’article source illustre l’impact potentiel au moyen d’un scénario lié à la chaîne d’approvisionnement logicielle.
Ce scénario ne nécessite pas qu’un logiciel malveillant arrive par l’intermédiaire d’un téléchargement manifestement malveillant.
Une séquence plus réaliste serait la suivante :
C’est pourquoi les postes de travail des développeurs constituent des cibles de grande valeur.
Ils peuvent contenir :
La première machine compromise n’est pas nécessairement la véritable cible de l’attaquant.
La cible peut être la confiance associée à l’identité du développeur et à son pipeline de publication.
C’est la caractéristique centrale du risque lié à la chaîne d’approvisionnement : l’attaquant tente de transformer un chemin logiciel de confiance en mécanisme de distribution.
Le problème des plugins sélectionnés s’inscrit dans une séquence plus large de recherches de sécurité consacrées aux agents de programmation dotés d’IA.
L’article source regroupe plusieurs incidents survenus en 2026, dont la plupart peuvent être vérifiés indépendamment.
Pwn2Own Berlin 2026 a introduit une catégorie dédiée aux agents de programmation, avec OpenAI Codex, Anthropic Claude Code et Cursor comme cibles.
Les résultats officiels du premier jour publiés par la Zero Day Initiative montrent que Compass Security a exploité OpenAI Codex à l’aide d’un problème CWE-150 et a obtenu 40 000 dollars ainsi que quatre points de Master of Pwn.
Doyensec a également démontré une exploitation contre Codex, mais le résultat a été classé comme une collision, car le fournisseur connaissait déjà le bug sous-jacent.
L’événement s’est achevé avec 47 vulnérabilités zero-day uniques et 1 298 250 dollars de récompenses, toutes catégories confondues.
Pwn2Own constitue un point de référence particulièrement utile, car ses règles concernant les agents de programmation excluaient les simples jailbreaks et les modes non sûrs. Pour être retenue, une attaque devait franchir une limite de sécurité significative par l’intermédiaire d’un flux de travail courant d’agent de programmation.
Le 12 août, 360 a déclaré publiquement que son système de sécurité IA Tulongfeng avait découvert six vulnérabilités importantes dans OpenAI Codex.
Selon l’annonce de 360, ces résultats comprenaient des cas à haut risque pouvant mener à l’exécution de code arbitraire à distance et au contournement des demandes de confiance de Codex lorsque les utilisateurs ouvraient des répertoires de projets non fiables.
La divulgation a été reprise par plusieurs médias chinois ainsi que par Xinhua dans un article syndiqué.
Cependant, les rapports techniques détaillés et les identifiants de type CVE correspondant aux six résultats n’étaient pas publics dans les sources examinées pour cet article.
La formulation correcte est donc la suivante :
360 affirme que Tulongfeng a découvert six vulnérabilités importantes dans Codex, dont certaines pourraient avoir un impact d’exécution de code à distance.
Cela ne revient pas à valider indépendamment les six chaînes d’exploitation à partir de documents techniques publics.
Le chercheur en sécurité Oren Yomtov, d’Accomplish, a signalé deux échappements du bac à sable de Codex à OpenAI le 12 août.
Les chercheurs les ont nommés Overpatch et Heapjack.
Overpatch concernait le chemin de correction du CLI Codex open source et pouvait permettre de sortir de la limite workspace-write prévue.
Heapjack ciblait un assistant JavaScript utilisé par Codex Desktop et pouvait, selon les chercheurs, aboutir à l’exécution de commandes sans bac à sable, même lorsque Codex fonctionnait en mode lecture seule.
Les chercheurs indiquent qu’OpenAI a corrigé les deux problèmes en huit jours.
Leurs recommandations de remédiation publiées indiquent que les utilisateurs doivent effectuer une mise à jour vers les versions suivantes :
| Problème | Version corrigée rapportée par les chercheurs |
|---|---|
| Overpatch | Codex CLI 0.149.0 ou version ultérieure |
| Heapjack | Codex Desktop build 26.818.21641 ou version ultérieure |
Ces numéros de version proviennent de la divulgation des chercheurs et non d’un avis de sécurité distinct publié par OpenAI.
AIR Security a divulgué Plugin4Shell le 17 septembre.
La faille concernait la logique d’installation et de mise à jour des plugins dans :
AIR l’a décrite comme une voie d’exécution de code arbitraire à distance sans clic, fondée sur l’absence de vérification entre le code récupéré après l’installation d’un plugin et le commit que la marketplace devait épingler.
Comme Codex et Claude Code pouvaient mettre automatiquement à jour les plugins installés, un plugin auparavant approuvé pouvait devenir un vecteur de chaîne d’approvisionnement sans nécessiter un nouveau clic de l’utilisateur.
AIR indique qu’OpenAI a corrigé Codex dans la version 0.146.0.
Plugin4Shell est important, car il ne s’agissait pas d’un échec du comportement du modèle. C’était une faille classique de conception de la chaîne d’approvisionnement logicielle dans la couche de distribution entourant l’agent.
Les résultats de sécurité concernant Codex en 2026 ne partagent pas tous la même cause première.
Certains concernent les limites du bac à sable.
D’autres impliquent des processus auxiliaires.
D’autres encore concernent la gestion de l’environnement Git.
Certains touchent la distribution des plugins.
En revanche, ils ont en commun l’élargissement de la base informatique de confiance.
Un agent de programmation moderne ne se résume pas à ceci :
demande utilisateur -> modèle -> réponse
Il ressemble davantage à ceci :
utilisateur
-> modèle
-> environnement de l’agent
-> routeur d’outils
-> shell
-> système de fichiers
-> Git
-> gestionnaire de plugins
-> services MCP
-> identifiants
-> réseau
-> CI/CD
Chaque couche apporte des capacités utiles.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Chaque couche peut également introduire une nouvelle limite de sécurité.
C’est pourquoi l’affirmation « le modèle est placé dans un bac à sable » ne constitue pas à elle seule un argument de sécurité complet.
La plateforme de l’agent doit également démontrer que le programme de mise à jour, le chargeur de plugins, l’éditeur de fichiers, le pont terminal, les démons auxiliaires, le proxy réseau et les chemins d’accès aux identifiants respectent les mêmes hypothèses de sécurité.
Le point plus général de l’article source est que l’IA accélère les deux dimensions de la sécurité logicielle.
Du côté du développement, les agents de programmation peuvent créer des fonctionnalités, des tests, des infrastructures, des intégrations et des projets entiers beaucoup plus rapidement que les flux de travail manuels traditionnels.
Cela augmente la quantité de nouveau code produit.
Du côté défensif, des systèmes tels que Codex Security et Tulongfeng sont conçus pour analyser de grandes bases de code et découvrir des vulnérabilités à l’échelle des machines.
Cela augmente la vitesse à laquelle les vulnérabilités anciennes et nouvelles peuvent être découvertes.
Ces deux tendances se renforcent mutuellement.
Davantage de code crée une surface d’attaque plus importante.
De meilleurs outils d’automatisation de la sécurité découvrent une plus grande partie de cette surface d’attaque.
Le résultat n’est pas nécessairement un écosystème logiciel moins sûr. En revanche, la revue de sécurité doit fonctionner à une vitesse plus proche de celle du développement assisté par l’IA.
Les agents de programmation occupent une position inhabituelle dans la pile logicielle.
Ils se situent en amont des applications que les utilisateurs finiront par installer.
Ils peuvent avoir accès aux éléments suivants :
Une défaillance dans un chatbot classique peut produire une mauvaise réponse.
Une défaillance dans un agent de programmation peut parfois produire un fichier modifié, un processus lancé, un dépôt altéré, un identifiant exposé ou un chemin de compilation compromis.
C’est pourquoi la sécurité des agents de programmation ressemble de plus en plus à la sécurité des terminaux et à celle de la chaîne d’approvisionnement logicielle, et pas uniquement à la sécurité des modèles.
Les propres recommandations actuelles d’OpenAI concernant le bac à sable reflètent cette réalité. Elles conseillent d’isoler les charges de travail, de limiter l’accès sortant au réseau, de séparer les identifiants, de conserver les clés applicatives en dehors des environnements d’exécution des agents et d’utiliser des contrôles d’approbation indépendants pour les actions ayant des conséquences importantes.
Le dernier tiers de l’article source se concentre sur 360 Tulongfeng et sur la course entre défenseurs et attaquants.
L’idée centrale est valide : une vulnérabilité existe, que le fournisseur la connaisse ou non.
Si un défenseur la découvre en premier, il est possible de corriger le système avant qu’une exploitation à grande échelle ne se produise.
Si un attaquant la découvre en premier, le même bug peut devenir un incident.
C’est l’argument économique en faveur de la recherche automatisée de vulnérabilités.
Les initiatives Codex Security et Patch the Planet d’OpenAI reposent sur le même principe, même si elles proviennent d’une autre organisation.
L’objectif est de déplacer la découverte des vulnérabilités vers une étape plus précoce du cycle de vie logiciel.
360 décrit Tulongfeng comme un système de découverte de vulnérabilités par IA construit autour de deux composants :
360 affirme que le produit a été utilisé pour tester du code source, des binaires, des micrologiciels, des systèmes métier et des chaînes d’outils d’IA.
L’entreprise affirme également que Tulongfeng avait découvert plus de 10 000 vulnérabilités à la fin août ou en septembre 2026.
Ce total est un chiffre cumulé communiqué par le fournisseur.
Une annonce publiée par la communauté 360 le 25 août indiquait que le système avait découvert plus de 10 000 vulnérabilités et que près de 400 organisations s’étaient connectées et avaient terminé des tests de sécurité. Une publication ultérieure de septembre a repris ce chiffre de plus de 10 000.
L’article source affirme également que 260 résultats avaient été vérifiés par les autorités chinoises chargées des vulnérabilités et que près de 500 organisations s’étaient connectées. Ces chiffres précis n’ont pas été retrouvés dans la dernière source 360 examinée pour cette version et ne sont donc pas repris ici comme des données confirmées indépendamment.
L’article source décrit l’approche de Tulongfeng comme une forme d’amélioration récursive.
Le concept concerne moins la réécriture des poids du modèle de base que la constitution d’une mémoire opérationnelle réutilisable à partir de tâches de sécurité terminées.
Le flux de travail peut être résumé ainsi :
Cette approche ressemble à la manière dont les équipes de sécurité construisent des guides opérationnels, des bases de connaissances d’exploitation, des règles de détection et des procédures de réponse aux incidents.
La différence est qu’un système agentique peut potentiellement réutiliser cette expérience à une vitesse beaucoup plus élevée et sur un grand nombre de tâches parallèles.
L’affirmation du fournisseur est que ce fonctionnement transforme les découvertes de sécurité individuelles en capacité partagée à l’échelle de la flotte d’agents.
L’article s’achève sur une image de la chaîne d’approvisionnement qui mérite d’être conservée.
Lorsqu’un utilisateur appuie sur « Mettre à jour », le logiciel concerné peut être passé par :
Chaque étape hérite de la confiance accordée par l’étape précédente.
Les agents de programmation dotés d’IA se trouvent désormais près du début de cette chaîne.
Leurs propres contrôles de sécurité font donc partie du modèle de sécurité de chaque application qu’ils contribuent à créer et à distribuer.
L’enseignement pratique n’est pas que les développeurs doivent cesser d’utiliser les agents de programmation.
C’est que ces agents doivent être traités comme une infrastructure de développement puissante.
Ils nécessitent une gestion des versions, une isolation, le principe du moindre privilège, une séparation des secrets, une gouvernance des plugins, une surveillance de la sécurité et une mise à jour rapide, comme tout autre outil privilégié.
À partir des recommandations actuelles d’OpenAI et des divulgations publiques de vulnérabilités en 2026, les développeurs peuvent réduire leur exposition grâce à quelques pratiques concrètes.
Les correctifs de sécurité connus ont été publiés rapidement.
Pour les problèmes signalés par les chercheurs et couverts ci-dessus, les utilisateurs concernés doivent utiliser une version plus récente que les versions corrigées indiquées pour Plugin4Shell, Overpatch et Heapjack.
Ne supposez pas que « j’ai seulement posé une question à l’agent » signifie qu’aucun chemin d’exécution ne peut être déclenché.
Utilisez l’isolation lorsque vous examinez des dépôts inconnus.
Évitez d’exposer directement à l’environnement d’exécution d’un agent des identifiants cloud, de registre de paquets, de signature et de production à forte valeur.
N’autorisez que les destinations sortantes nécessaires à la tâche.
Un agent de programmation bénéficiant d’un accès sortant arbitraire et d’identifiants étendus présente un rayon d’impact beaucoup plus important.
Même un agent de confiance peut être compromis par une extension ou un canal de mise à jour non fiable.
Épinglez, auditez et mettez à jour les plugins de manière délibérée.
Pour les opérations à fort impact, les approbations doivent être appliquées par un composant de confiance séparé, plutôt que par une logique exécutée dans le même environnement que l’agent.
Consignez et examinez :
La réponse finale du modèle ne représente qu’une partie des actions effectuées par l’agent.
Codex a utilisé un mécanisme de démarrage pour synchroniser des plugins sélectionnés via Git. Des tickets GitHub publics ont montré que certaines versions antérieures pouvaient hériter de l’état de l’environnement Git propre au dépôt et effectuer des opérations de synchronisation sur le dépôt de l’utilisateur au lieu du cache de plugins prévu, en dehors du bac à sable du modèle.
L’article de BAAI/New智元 attribue à 360 Tulongfeng un nouveau chemin d’attaque lié à la synchronisation Git sélectionnée. Toutefois, aucun avis public d’OpenAI ni aucune divulgation technique détaillée de 360 n’a été trouvé pour établir indépendamment que cette allégation de septembre constitue un nouveau zero-day distinct. Elle doit donc être considérée comme un rapport attribué plutôt que comme une découverte publique entièrement vérifiée.
Il s’agit de deux échappements du bac à sable de Codex divulgués par Oren Yomtov, chercheur chez Accomplish. Le chercheur indique que les deux problèmes ont été signalés à OpenAI le 12 août et corrigés dans les huit jours.
Plugin4Shell est une vulnérabilité de chaîne d’approvisionnement liée aux plugins, divulguée par AIR Security le 17 septembre 2026. AIR affirme qu’elle affectait Claude Code, Codex, GitHub Copilot et Gemini CLI en supprimant la garantie qu’un plugin installé correspondait au commit que la marketplace devait épingler.
Oui. La Zero Day Initiative a signalé le premier jour une exploitation réussie de Codex par Compass Security, ainsi qu’une autre exploitation réussie par Ikotas Labs le troisième jour. Doyensec a également démontré une exploitation classée comme une collision, car le fournisseur connaissait déjà le bug sous-jacent.
OpenAI a publié en juillet 2026 le CLI Codex Security et le SDK TypeScript sous forme de logiciels open source. L’accès à certaines capacités de cybersécurité et à certains résultats protégés peut toutefois nécessiter un accès OpenAI approprié ou Trusted Access for Cyber.
Non. Aucun mode ne doit être considéré comme une garantie absolue. Plusieurs résultats de 2026 étaient précisément importants parce que le composant vulnérable fonctionnait en dehors du bac à sable prévu pour le modèle ou franchissait la limite de sécurité attendue.
Utilisez des versions à jour, isolez le code non fiable, limitez l’accès au réseau, conservez les identifiants persistants en dehors de l’environnement d’exécution, auditez les plugins, utilisez des approbations humaines indépendantes pour les actions ayant des conséquences importantes et consignez l’activité réelle des outils et du système de l’agent.
OpenAI utilise Codex Security et Patch the Planet pour accélérer la recherche défensive de vulnérabilités. Codex est toutefois devenu une cible de sécurité de plus en plus importante, car il se trouve à proximité du code source, des outils, des identifiants, des plugins et des flux de publication logicielle.
Les incidents publics vérifiés de 2026 comprennent les exploitations de Codex lors de Pwn2Own, les bugs d’isolation de la synchronisation initiale des plugins sélectionnés, les échappements du bac à sable Overpatch et Heapjack, ainsi que Plugin4Shell. Le « nouveau zero-day » de septembre attribué à 360 Tulongfeng doit être considéré avec davantage de prudence jusqu’à ce qu’un avis public détaillé établisse en quoi il diffère des problèmes antérieurs de synchronisation des plugins.
La leçon générale est cohérente dans tous ces cas : la limite de sécurité d’un agent de programmation doté d’IA comprend bien plus que le modèle. Le programme de mise à jour, le gestionnaire de plugins, l’intégration Git, l’environnement d’exécution des outils, les processus auxiliaires, l’accès au réseau, la gestion des identifiants et le système d’approbation font tous partie de la base informatique de confiance.
Les outils de programmation dotés d’IA constituent désormais une infrastructure logicielle en amont. Leurs propres contrôles de sécurité doivent être traités avec la même rigueur que les applications et les chaînes d’approvisionnement qu’ils contribuent à construire.
Partez d’une phrase et obtenez un site complet en quelques minutes.
