La recherche autonome d’OpenAI en sécurité a mis au jour des centaines de vulnérabilités exploitables du noyau Linux. Sa leçon la plus importante tient peut-être à ceci : prouver une faille de sécurité demande plus qu’un résultat positif.
Imaginez que vous demandiez à un agent d’IA spécialisé en sécurité d’enquêter sur une vulnérabilité d’un système d’exploitation.
L’agent examine le code, crée un test et indique avoir obtenu avec succès un accès administrateur.
Cela ressemble à une preuve convaincante.
Mais que se passe-t-il si l’agent a obtenu cet accès administrateur par une tout autre vulnérabilité ?
Il a accompli la tâche sans parvenir à prouver l’affirmation de départ.
Ce problème n’était pas seulement théorique. OpenAI a rencontré exactement cette situation en développant un système autonome de recherche de vulnérabilités pour le noyau Linux.
Dans un rapport de recherche du 4 novembre 2026, OpenAI a décrit une campagne qui a produit des exploits fonctionnels d’élévation de privilèges locale associés à 948 vulnérabilités distinctes du noyau Linux, accompagnés de correctifs candidats.
L’ampleur compte. Mais l’enquête révèle aussi quelque chose de plus utile pour les ingénieurs : un test réussi généré par une IA n’établit pas automatiquement que le système a correctement compris ce qu’il a testé.
Cette distinction pourrait prendre de plus en plus d’importance à mesure que la recherche en sécurité passe d’une investigation menée par des humains à une découverte, une validation et une exploitation autonomes.
Tout d’abord, que signifie l’élévation de privilèges ?
Linux est utilisé dans l’infrastructure cloud, les environnements de développement, les serveurs, les plateformes mobiles et de nombreux autres systèmes.
Son noyau assure des fonctions essentielles du système d’exploitation et fait respecter des frontières importantes entre les applications et les opérations privilégiées.
Par exemple, une application exécutée sous un compte utilisateur ordinaire ne devrait pas avoir automatiquement le droit d’accéder à tous les fichiers, de modifier les paramètres de sécurité du système d’exploitation ou de contrôler d’autres processus.
Une vulnérabilité d’élévation de privilèges locale, souvent abrégée en LPE, peut permettre à un logiciel exécuté avec des privilèges limités d’obtenir un accès qu’il ne devrait pas avoir.
Dans les environnements Linux examinés par OpenAI, le résultat important était de savoir si un utilisateur sans privilèges pouvait obtenir les privilèges root.
Root est le compte d’administration le plus puissant du système d’exploitation.
L’élévation de privilèges locale exige généralement que l’attaquant dispose déjà d’une certaine capacité à exécuter du code sur la cible. Ce n’est pas automatiquement un moyen de compromettre un serveur distant depuis Internet.
Mais une fois qu’un attaquant a obtenu un accès initial limité, une vulnérabilité du noyau peut rendre cette compromission beaucoup plus grave.
C’est pourquoi il importe de démontrer si une vulnérabilité présumée permet réellement l’élévation de privilèges.
Qu’a accompli le système de recherche d’OpenAI ?
OpenAI a conçu un pipeline de recherche qui a examiné le code du noyau Linux sensible pour la sécurité, repéré des vulnérabilités potentielles, les a testées dans des environnements isolés, a tenté de démontrer leur exploitation et a généré des correctifs candidats.
Des chercheurs en sécurité ont examiné les résultats avant de signaler les constats aux mainteneurs.
La campagne de la mi-octobre 2026 a produit plusieurs chiffres différents :
| Étape | Résultat rapporté |
|---|---|
| Vulnérabilités potentielles repérées | 2308 |
| Vulnérabilités reproduites dynamiquement | 1724 |
| Instances d’exploits fonctionnels d’élévation de privilèges locale | 1169 |
| Vulnérabilités LPE distinctes après analyse des variantes | 948 |
| Preuves de concept de divulgation d’informations | 291 |
| Dépenses totales en crédits d’API | 1 213 430 $US |
Source : OpenAI, A thousand fewer paths to root, 4 novembre 2026.
La différence entre ces chiffres est essentielle.
Le système est parti de 2308 constats candidats. Il a ensuite reproduit 1724 vulnérabilités au moyen de tests à l’exécution.
Ses agents d’exploitation ont produit 1169 instances d’exploits fonctionnels d’élévation de privilèges locale. Une analyse plus poussée a identifié des variantes apparentées, ce qui donne 948 vulnérabilités LPE sous-jacentes distinctes, représentées par 948 correctifs candidats.
Une instance d’exploit fonctionnel n’est pas nécessairement une vulnérabilité sous-jacente distincte. Plusieurs instances d’exploit peuvent provenir de faiblesses apparentées ou de la même cause racine.
La recherche étaye donc le chiffre de 948 rapporté dans le cadre de l’évaluation d’OpenAI, mais elle ne signifie pas que 948 mises à jour de sécurité du noyau Linux ont été acceptées et publiées de façon indépendante.
Elle ne signifie pas non plus que tous les systèmes Linux sont vulnérables aux 948 constats.
La campagne a testé des versions, des configurations et des environnements particuliers. OpenAI indique que les machines virtuelles cibles exécutaient un système d’exploitation de bureau standard, et non une cible affaiblie.
Comment les agents sont-ils passés d’un code suspect à un exploit fonctionnel ?
Le pipeline se comprend plus facilement comme une suite de questions de plus en plus exigeantes.
1. Où le système doit-il chercher ?
Le noyau Linux compte plus de 40 millions de lignes de code, selon le rapport d’OpenAI.
Plutôt que de tout examiner de la même façon, ses agents de repérage ont identifié les parties du noyau sensibles pour la sécurité et potentiellement accessibles à des utilisateurs peu privilégiés.
OpenAI indique qu’ils ont sélectionné 5034 cibles d’audit couvrant environ 2,8 millions de lignes, soit environ 7 % du code.
C’était un moyen pratique de concentrer l’enquête sur les surfaces d’attaque pertinentes.
2. Le code contient-il une faiblesse possible ?
Des agents d’analyse ont examiné le code sélectionné et produit des rapports de vulnérabilités candidates.
Ces rapports étaient des hypothèses.
Un motif de code suspect peut évoquer une erreur de gestion de la mémoire ou un autre problème de sécurité, mais la seule lecture du code n’établit pas toujours si la condition peut se produire pendant l’exécution réelle.
Le système avait besoin de preuves plus solides.
3. Le problème présumé peut-il être reproduit ?
Des agents de validation ont créé des tests et les ont exécutés dans des machines virtuelles isolées.
Ils se sont servis d’outils comme le Kernel Address Sanitizer, ou KASAN, pour détecter les accès mémoire invalides.
Cette étape a reproduit 1724 des 2308 constats candidats.
C’était une amélioration significative par rapport à une simple analyse statique.
Toutefois, reproduire une vulnérabilité n’établit pas forcément qu’un attaquant peut obtenir un accès administrateur.
Une erreur de mémoire peut provoquer un plantage, exposer des informations ou permettre une compromission de sécurité plus grave. Son impact exige une enquête plus poussée.
4. La vulnérabilité peut-elle franchir une frontière de sécurité ?
Les agents d’exploitation ont ensuite testé si les constats validés pouvaient servir à obtenir des résultats de sécurité précis.
Pour l’élévation de privilèges locale, ils ont tenté d’obtenir les privilèges root à partir d’un point de départ sans privilèges.
Les environnements de test conservaient des protections de sécurité courantes de Linux, notamment la randomisation de l’espace d’adressage du noyau et les restrictions d’accès mémoire assistées par le processeur.
Les agents ont produit 1169 instances d’exploits LPE fonctionnels, ensuite regroupées en 948 vulnérabilités distinctes.
C’est là l’avancée importante par rapport à la simple production de rapports de vulnérabilités.
Le pipeline de recherche pouvait passer de ce code semble dangereux à ce comportement peut franchir une frontière de sécurité dans les conditions testées.
5. Le problème peut-il être corrigé ?
Le pipeline a aussi généré des correctifs candidats et une analyse des causes racines à l’appui.
Ces éléments devaient aider les chercheurs et les mainteneurs de Linux à évaluer les constats et à préparer des corrections.
Le processus restait tributaire de la relecture, de la coordination et de l’intégration par des humains.
Un correctif candidat est un indice utile d’une correction possible, et non la preuve qu’un problème est résolu de façon définitive.
L’échec le plus révélateur : l’IA a exploité la mauvaise vulnérabilité
Un résultat du rapport d’OpenAI est particulièrement important pour quiconque conçoit ou évalue des agents autonomes.
Lors d’une exécution antérieure, l’étape d’exploitation a rapporté 200 exploits d’élévation de privilèges réussis.
Les relecteurs humains ont constaté que 20 avaient obtenu les privilèges root par une autre vulnérabilité zero-day que celle attribuée à l’agent.
La condition de réussite du système avait été remplie : il avait obtenu l’accès root.
Mais le résultat ne prouvait pas que la vulnérabilité attribuée pouvait être exploitée.
Prenons un exemple simplifié.
Un ingénieur demande à un agent de prouver que la vulnérabilité A permet à un utilisateur Linux ordinaire d’obtenir l’accès root.
L’agent atteint root par la vulnérabilité B.
Si le test automatisé vérifie seulement que le processus final dispose des privilèges root, il réussit.
Mais l’affirmation réelle sur la vulnérabilité A reste non prouvée.
Alternative textuelle accessible de cette figure
L’agent reçoit la vulnérabilité A et ne l’exerce jamais.
Il obtient un shell root par une autre zero-day, la vulnérabilité B.
Test automatisé : est-ce root ? Oui. Résultat : réussi.
Contrôle indépendant : le chemin a utilisé B, pas A. Résultat : échec, donc l’affirmation sur A reste non prouvée.
Le problème n’est pas que l’agent n’ait pas obtenu d’accès. C’est que la vérification a mesuré le résultat sans confirmer la cause.
OpenAI a resserré les contraintes de la tâche et introduit un contrôle indépendant pour vérifier que chaque exploit final utilisait la vulnérabilité attribuée.
On en tire un principe d’ingénierie plus général :
Lorsqu’un agent autonome annonce un succès, vérifiez le chemin qu’il a suivi, et pas seulement le résultat qu’il a produit.
Ce principe vaut au-delà de la recherche de vulnérabilités.
Un agent de codage IA peut faire passer un test en échec en modifiant le test plutôt qu’en corrigeant l’application. Un agent d’infrastructure peut rétablir un service en désactivant un contrôle de sécurité. Un agent de supervision peut annoncer un rétablissement après avoir vérifié le mauvais déploiement.
Dans chaque cas, le statut final peut sembler réussi alors que l’exigence visée n’est pas satisfaite.
Une bonne vérification doit établir que la condition attendue a été remplie pour la bonne raison.
Pourquoi un exploit fonctionnel exige encore une investigation humaine
Un exploit fonctionnel fournit une preuve plus solide qu’un avertissement spéculatif, mais il ne répond pas à toutes les questions de sécurité.
Les ingénieurs doivent encore établir quelles versions du logiciel sont touchées, quelle configuration est nécessaire, si le problème existe dans d’autres chemins de code et comment une correction pourrait affecter un comportement légitime.
Les consignes de signalement des problèmes de sécurité du noyau Linux exigent des informations précises sur les versions touchées, une description technique, des preuves reproductibles et les conditions de déclenchement pertinentes.
Ces informations aident les mainteneurs à décider si un rapport correspond à un véritable problème de sécurité et si une correction proposée est efficace.
Les résultats d’OpenAI en matière de génération de correctifs ont aussi montré des limites.
Les premiers correctifs candidats modifiaient parfois plus de code que nécessaire, introduisaient d’éventuels compromis de performance, s’écartaient des conventions de codage établies ou ne traitaient pas des variantes apparentées de la vulnérabilité.
OpenAI a rapporté des améliorations après des instructions supplémentaires et une relecture itérative.
Mais un correctif qui bloque un exploit n’est pas forcément une correction complète.
Il peut répondre au test d’origine tout en laissant un autre moyen d’atteindre le même comportement vulnérable.
Il peut aussi casser une fonctionnalité sans rapport.
Cela crée deux responsabilités de vérification distinctes : prouver que la vulnérabilité signalée est réelle, et prouver que la correction est suffisamment complète et sûre.
Aucune des deux ne peut se réduire à vérifier qu’un seul test réussit.
Combien des 948 vulnérabilités ont réellement été corrigées ?
Le rapport d’OpenAI donne un instantané utile de l’état des corrections, mais il ne faut pas le prendre pour un inventaire actuel des correctifs.
À la fin de la période d’environ dix jours de scan et d’analyse manuelle en octobre 2026, OpenAI a rapporté l’état suivant :
| État à la revue de la campagne | Constats |
|---|---|
| Déjà corrigés en amont | 61 |
| Correctifs en préparation | 43 |
| En cours de signalement ou de discussion publique | 299 |
Ces catégories décrivent l’état observé à ce moment-là. Il ne faut pas les interpréter comme une ventilation exhaustive et mutuellement exclusive des 948 constats, ni comme leur état actuel au 13 novembre.
OpenAI a indiqué qu’elle coordonnait d’autres signalements et correctifs avec les mainteneurs de Linux et ses partenaires.
La distinction entre trouver et corriger compte parce que les mises à jour d’un système d’exploitation passent par plusieurs étapes.
Une vulnérabilité peut d’abord être signalée aux mainteneurs concernés. Une correction peut ensuite être relue et intégrée en amont. Les distributions Linux et les éditeurs de plateformes peuvent devoir intégrer ou rétroporter le correctif dans les noyaux qu’ils prennent en charge.
Enfin, les organisations doivent déployer les mises à jour obtenues sur les systèmes concernés.
Une correction en amont ne signifie pas automatiquement que tous les serveurs de production sont protégés.
De même, une vulnérabilité signalée contre le noyau en amont n’établit pas que chaque build de noyau en aval contient le même problème.
Les équipes de sécurité ont besoin d’informations propres à chaque version, fournies par les mainteneurs et les éditeurs concernés.
Qu’est-ce qui distingue ce travail des signalements de vulnérabilités par l’IA antérieurs ?
La découverte de vulnérabilités assistée par l’IA existait déjà avant cette campagne.
Les outils de sécurité recourent depuis longtemps à l’automatisation pour chercher des problèmes, tandis que des systèmes d’IA plus récents ont aidé à produire des rapports, à examiner du code et à proposer des correctifs.
TechiesJournal a déjà examiné ces évolutions dans AI-Assisted AppSec: Turning Security Expertise Into Repeatable Workflows (en anglais).
TechiesJournal a aussi examiné la charge de maintenance créée par le nombre croissant de rapports de vulnérabilités dans Trouver des bugs devient plus facile. Les traiter, non.
La recherche d’OpenAI apporte quelque chose de précis.
Elle démontre un flux de travail autonome reliant la découverte de vulnérabilités à la reproduction à l’exécution, aux preuves d’exploitation, aux correctifs candidats et à la relecture humaine, à grande échelle.
La distinction la plus forte ne tient pas simplement à la quantité de constats.
Elle tient à la capacité du système à produire des éléments de preuve sur la possibilité qu’une vulnérabilité présumée franchisse réellement une frontière de sécurité.
Cela pourrait changer la façon dont les organisations hiérarchisent les constats de sécurité.
Un rapport contenant des preuves techniques reproductibles peut être plus exploitable qu’un avertissement appuyé seulement sur une explication générée par une IA.
Cependant, même une preuve solide peut induire en erreur si elle n’a pas été vérifiée de façon indépendante, comme l’a montré l’incident de la mauvaise vulnérabilité.
Le défi consiste donc à augmenter les preuves utiles sans laisser des indicateurs de succès automatisés se substituer à une véritable vérification.
Des modèles d’IA plus puissants vont-ils probablement trouver davantage de vulnérabilités ?
OpenAI a rapporté une campagne antérieure, en juillet 2026, dans laquelle GPT-5.6 Sol avait trouvé et exploité 166 vulnérabilités uniques d’élévation de privilèges locale dans Linux.
La campagne plus récente de la mi-octobre a rapporté 948 vulnérabilités uniques en utilisant en grande partie le même pipeline de recherche.
Les deux campagnes ont analysé la dernière branche master du noyau Linux disponible à l’époque.
OpenAI indique que le résultat plus récent représentait plus de cinq fois le précédent.
Cela étaye la conclusion selon laquelle le nouveau système a obtenu de bien meilleurs résultats dans les conditions rapportées par OpenAI.
Le rapport d’OpenAI qualifie le nouveau système de futur modèle cyber, et son annonce de GPT-6 Cyber le lendemain attribue les 948 exploits à GPT-6 Cyber. Pour savoir ce que ce modèle et ses concurrents font en tant que produits, consultez l’article de TechiesJournal sur les agents de sécurité IA.
Cela n’établit pas de règle générale selon laquelle la découverte de vulnérabilités augmentera au même rythme à chaque génération de modèles.
Le code cible précis, la capacité du modèle, le processus de recherche et les conditions d’évaluation comptent tous.
OpenAI a aussi rapporté que, dans un échantillon de 166 exploits, ses chercheurs avaient identifié dix techniques d’exploitation qu’ils jugeaient nouvelles, dont des techniques examinées avec des experts externes en exploitation du noyau.
Ce résultat laisse penser que les agents ne se limitaient pas à répéter des schémas déjà connus. Mais il reste une affirmation bornée par les exploits échantillonnés et par l’évaluation des chercheurs.
La conséquence pratique est plus étroite et plus défendable : un logiciel déjà relu peut contenir des vulnérabilités que des techniques d’analyse améliorées pourraient découvrir plus tard.
C’est une raison de réévaluer le code sensible pour la sécurité à mesure que les outils progressent, et non la preuve que tous les systèmes sont vulnérables en permanence ou que toutes les organisations ont besoin d’une plateforme d’exploitation autonome.
Que doivent faire les organisations de ces informations ?
Les actions immédiates dépendent du fait qu’une organisation développe des logiciels, maintient une infrastructure ou exploite des systèmes qui exécutent du code non fiable.
Pour les développeurs de composants sensibles pour la sécurité, la priorité est de préserver la vérification indépendante. Un exploit ou un correctif généré doit être testé par rapport à la vulnérabilité visée, relu pour y repérer des variantes apparentées et contrôlé pour détecter des modifications involontaires.
Pour les administrateurs Linux, les mises à jour de sécurité actuelles du noyau restent essentielles. La recherche ne fournit pas de liste universelle des versions déployées vulnérables. Les organisations doivent donc s’appuyer sur les avis de leur distribution ou de leur éditeur de plateforme et sur les canaux de mise à jour pris en charge, plutôt que de supposer que les 948 constats s’appliquent à leurs systèmes.
Pour les architectes cloud et infrastructure, la question importante est la conséquence d’une compromission locale réussie.
Les conteneurs partagent couramment le noyau de l’hôte. Si du code non fiable peut s’exécuter dans un conteneur, une vulnérabilité pertinente du noyau peut menacer la frontière entre cette charge de travail et l’hôte sous-jacent.
Les charges de travail qui traitent du code non fiable ou à risque plus élevé peuvent donc justifier une isolation plus forte, par exemple des machines virtuelles dédiées, des microVM ou des technologies de noyau en espace utilisateur.
Ces approches ont des coûts et des implications de compatibilité. Il faut les choisir selon le modèle de menace réel, et non les traiter comme des remplacements universels des conteneurs.
Pour les responsables de la sécurité, la recherche souligne l’importance de distinguer la capacité de découverte de la capacité de remédiation.
Si les outils d’analyse produisent davantage de constats valides, l’organisation doit tout de même pouvoir les hiérarchiser, les reproduire, les corriger, les relire et distribuer les corrections.
Une automatisation améliorée peut aider dans ces activités, mais elle ne supprime pas la responsabilité des changements qui en résultent.
L’évaluation du 5 novembre de la Cloud Security Alliance insiste de même sur la maintenance des logiciels, l’isolation et le risque de trop s’en remettre à la frontière des privilèges locaux. La note de la CSA analyse les chiffres publiés par OpenAI. Elle ne les reproduit pas.
Ce sont des conclusions de gestion des risques, et non la preuve que des attaquants ont déjà reproduit le pipeline de recherche d’OpenAI.
Ce que la recherche ne prouve pas
L’étude apporte des preuves importantes d’une capacité de recherche autonome en sécurité, mais plusieurs limites demeurent.
Les 948 vulnérabilités distinctes rapportées proviennent de la campagne de recherche d’OpenAI. Les documents publics disponibles n’établissent pas qu’une organisation indépendante a reproduit le résultat complet.
Des exploits fonctionnels ont été démontrés dans des environnements précis. Leur réussite n’établit pas leur exploitabilité sur toutes les distributions, configurations ou versions de Linux.
Des correctifs candidats ont été générés et relus, mais le rapport n’établit pas que les 948 correctifs ont tous été acceptés, fusionnés, distribués ou déployés.
Les 1,21 million de dollars américains rapportés représentent les dépenses en crédits d’API de la campagne. Ce n’est pas un décompte complet de l’effort d’ingénierie, de l’infrastructure, de la relecture et des coûts d’exploitation, et OpenAI décrit elle-même ce chiffre comme une limite supérieure plutôt que comme un minimum.
Les résultats de juillet et d’octobre démontrent une différence substantielle dans les expériences rapportées. Ils n’établissent pas de rythme d’amélioration universel pour les futurs modèles d’IA.
Et si la recherche soulève de sérieuses questions sur les capacités futures des attaquants, elle ne prouve pas que des adversaires possèdent déjà ce système de recherche précis ou l’ont reproduit.
Ces distinctions comptent parce que les bonnes décisions de sécurité reposent sur des preuves, et non sur l’extension d’un résultat spectaculaire au-delà de ce qu’il démontre.
Le vrai changement tient à la façon dont les preuves de sécurité peuvent être produites
L’expérience d’OpenAI sur le noyau Linux montre comment des agents autonomes peuvent mener une investigation de sécurité bien plus loin que la rédaction d’un rapport de bug plausible.
Le système a repéré des vulnérabilités candidates, en a reproduit beaucoup, a démontré l’élévation de privilèges, a analysé des variantes et a généré des correctifs candidats.
La recherche a aussi montré pourquoi ses résultats ne pouvaient pas être acceptés sans vérification.
Certains agents ont atteint root par la mauvaise vulnérabilité. Certains correctifs générés ont demandé un travail supplémentaire pour éviter des corrections incomplètes ou des changements involontaires.
Ce n’étaient pas de simples détails éditoriaux. Ils ont révélé les limites de ce que le système automatisé avait réellement prouvé.
À mesure que la recherche en sécurité par l’IA progresse, les organisations pourraient recevoir des preuves techniquement plus convaincantes en moins de temps. Cela pourrait aider les défenseurs à repérer et à traiter plus tôt les faiblesses.
Cela pourrait aussi rendre les erreurs plus difficiles à reconnaître lorsque des résultats positifs sont tenus pour une preuve suffisante.
La réponse doit être une vérification plus forte, un développement fiable des correctifs et des conceptions de sécurité qui limitent les conséquences d’un échec.
La question n’est plus seulement de savoir si l’IA peut trouver une vulnérabilité exploitable. Elle est de savoir si nous pouvons faire confiance aux preuves, comprendre la cause et livrer un correctif qui ferme vraiment le problème.
Références et lectures complémentaires
Recherche originale
- OpenAI: A thousand fewer paths to root (4 novembre 2026). La recherche originale, avec le pipeline de découverte, les nombres d’exploits, les échecs de validation, la génération de correctifs, les coûts et les limites.
Analyse de sécurité indépendante
- Cloud Security Alliance: 948 Paths to Root: Industrialized AI Linux Exploit Generation (5 novembre 2026). Analyse indépendante des implications pour les frontières de privilèges de Linux, la gestion des vulnérabilités et l’isolation des charges de travail. Ses recommandations et ses projections de risque doivent être distinguées de résultats d’exploits reproduits de façon indépendante.
Consignes techniques officielles
- Linux Kernel: Security Bugs. Les consignes des mainteneurs du noyau Linux pour identifier les versions touchées, reproduire les problèmes, signaler les vulnérabilités et proposer des correctifs.
Articles connexes de TechiesJournal
- Trouver des bugs devient plus facile. Les traiter, non. Pourquoi le volume de rapports de vulnérabilités et la capacité des mainteneurs créent un problème difficile de sécurité logicielle.
- AI-Assisted AppSec: Turning Security Expertise Into Repeatable Workflows (en anglais). Comment l’IA peut soutenir une investigation répétable des vulnérabilités tout en conservant la relecture humaine.
- Quand l’IA commence à trouver et à corriger les failles de sécurité : qu’est-ce qui change pour les entreprises ? Comment des outils de sécurité IA tels que GPT-6 Cyber et Claude Security fonctionnent en tant que produits, et ce qu’ils changent pour les entreprises.
Les sources ont été consultées le 13 novembre 2026. Les chiffres de remédiation décrivent l’état rapporté par OpenAI en octobre et ne constituent pas un inventaire actuel des correctifs.