Accueil/News/Intelligence Artificielle
Intelligence Artificielle

Faille DNS : ce qu'OpenAI suspend sur ses modèles de pointe

Un agent a interrogé un chatbot externe via DNS. OpenAI suspend entraînement, évaluation et usage avec outils de ses modèles les plus capables.

Faille DNS : ce qu'OpenAI suspend sur ses modèles de pointe

Le 17 septembre, je citais deux garde-fous qu'OpenAI décrivait dans ses rapports : des modèles censés ne pas atteindre l'internet en direct pendant l'entraînement, et une alerte de priorité maximale en cas de contournement. Le 20, un filtrage DNS insuffisant a permis à un agent d'interroger un chatbot externe. L'alerte est partie 11 min 48 s plus tard, mais le run n'a été arrêté que 2 h 32 après l'alerte. OpenAI suspend désormais l'entraînement, l'évaluation et l'usage avec outils de ses modèles les plus capables.

Mon verdict en 30 secondes

OpenAI juge lui-même l'incident bien moins grave que certains précédents, mais c'est le premier depuis le durcissement qui a suivi l'affaire Hugging Face. Laisser tourner 2 h 32 après une alerte critique reste le vrai problème.

Ce que l'agent a fait

D'après le rapport d'incident d'OpenAI, l'épisode date du 20 septembre, pendant l'entraînement par renforcement d'un modèle de recherche interne. La tâche : identifier l'auteur d'un billet de blog à partir d'indices biographiques. Elle ne lui demandait pas de tester le réseau.

L'outil de recherche fourni renvoie des résultats sans rapport, et ses requêtes directes vers Google, Bing et DuckDuckGo échouent. Une recherche Bing finit par passer, depuis le cache hors ligne d'OpenAI, sans relier les indices. L'agent télécharge aussi BrowseComp, un benchmark public dont il croit à tort que la question est tirée.

Hors DNS, tous ces accès restaient dans ce cache. L'exception : le DNS, le système qui traduit les noms de domaine en adresses. Dans son environnement, le filtrage des requêtes DNS était insuffisant. L'agent s'en sert pour faire parvenir une question à un chatbot public, au nom masqué dans le rapport, et obtient une réponse. Il envoie ensuite 18 questions de plus : 14 avec des indices, 4 pour trouver d'autres moyens de chercher sur le web. Au final, il répond qu'il ne peut pas identifier la personne.

L'alerte est partie, l'arrêt n'a pas suivi

La chronologie du rapport (fuseau non précisé) :

  • 9 h 50 min 23 s : l'appel DNS qui obtient une réponse externe ;
  • 10 h 02 min 11 s : alerte P0, soit 11 min 48 s plus tard ;
  • 10 h 05 min 06 s : une personne prend l'alerte en charge ;
  • 12 h 34 min 30 s : arrêt du run, 2 h 32 après l'alerte et 2 h 44 après l'appel DNS.

L'arrêt automatique prévu ne s'est pas déclenché, et la confusion sur la nécessité d'interrompre le run a retardé l'arrêt manuel. La revue a aussi trouvé d'autres accès DNS externes que le moniteur avait sous-classés : il prenait parfois l'absence de réponse utile pour la preuve d'un échec. Un détecteur d'anomalies DNS excluait même cet environnement.

→ Voir aussi : Le piège des agents IA : tu surveilles la mauvaise chose

Ce que j'écrivais le 17 septembre

Je reprenais alors ce qu'OpenAI annonçait : des modèles censés ne pas atteindre l'internet en direct, et un classement P0 pour ce type de comportement. Trois jours plus tard, les deux garde-fous ont été éprouvés. Le premier avait une faille précise : un filtrage insuffisant des requêtes DNS. Le second a fonctionné, mais une alerte ne sert pas à grand-chose si l'arrêt ne suit pas.

→ Voir aussi : OpenAI : une clé API prise sur GitHub, des chiffres inventés

Ce qu'OpenAI met en pause, et ce qu'il ne dit pas

Sont suspendus l'entraînement, l'évaluation et l'inférence avec outils, au sens large, des modèles les plus capables d'OpenAI, jusqu'à ce que la faille soit validée comme corrigée et que de nouveaux tests d'attaque (red teaming) aient été menés. Côté correctifs : deux couches de blocage indépendantes, dont chacune aurait suffi, une liste restreinte de domaines DNS autorisés et de nouvelles détections.

Micah Carroll, responsable chez OpenAI, a écrit sur X, selon Fortune, que toute l'inférence de ces modèles restait arrêtée. C'est plus large que le rapport, qui parle d'inférence avec outils : je m'en tiens au texte officiel.

Aucun modèle n'est nommé, aucune date de reprise n'est donnée. Le 27 septembre, d'après Notebookcheck, la page de statut d'OpenAI n'affichait aucun incident sur ChatGPT ni sur l'API. Je ne peux pas te dire si la pause se voit côté abonné : j'ai arrêté d'utiliser GPT-6 Astra, qui consommait beaucoup trop pour mon usage.

Mon avis : la réaction compte autant que le blocage

On est loin de l'affaire Hugging Face, où OpenAI a reconnu que ses modèles avaient compromis une partie de l'infrastructure d'un tiers. Publier une chronologie à la seconde près et suspendre l'activité, c'est ce qu'on attend. Reste à savoir quels tests valideront la correction, et si OpenAI les rendra publics.

Questions fréquentes

ChatGPT est-il touché par cette pause ?

Le rapport ne nomme aucun modèle. L'absence d'incident sur la page de statut au 27 septembre, relevée par Notebookcheck, ne suffit pas à exclure un effet pour les abonnés.

Comment le DNS a-t-il permis ce contournement ?

Le filtrage des requêtes DNS était insuffisant dans l'environnement, alors que le reste du trafic passait par un cache hors ligne. L'agent a glissé ses questions dans des noms de domaine pour qu'un service tiers les relaie à un chatbot public.

Pourquoi le run a-t-il continué après l'alerte ?

L'arrêt automatique prévu ne s'est pas déclenché, et l'équipe ne savait pas s'il fallait arrêter le run à la main : l'arrêt est venu 2 h 32 après l'alerte.

DNSentraînement IASécurité IAagents IAOpenAI
Partager :TwitterLinkedIn