Outils / Actualités / Le canal DNS caché de ChatGPT permettait à des GPT malveillants de voler silencieusement les fichiers importés
Presse

Le canal DNS caché de ChatGPT permettait à des GPT malveillants de voler silencieusement les fichiers importés

· VaultTools

Check Point Research a révélé une vulnérabilité dans le bac à sable d'exécution de code de ChatGPT qui permettait d'exfiltrer silencieusement des fichiers importés, des conversations et des dossiers médicaux via des requêtes DNS. Une faille distincte dans OpenAI Codex permettait le vol de tokens GitHub par l'injection de commandes dans des noms de branches. Les deux ont été corrigées en février 2026.

VaultTools · 8 avril 2026

Salle de serveurs à éclairage bleu, représentant l'infrastructure cloud et les canaux réseau cachés par lesquels les données peuvent être exfiltrées. Photo sur Unsplash

Table des matières

Ce qui s’est passé

Le 30 mars 2026, Check Point Research a publié les détails d’une vulnérabilité dans le bac à sable d’exécution de code de ChatGPT, permettant l’exfiltration silencieuse de données utilisateur, y compris les fichiers importés, le texte des conversations et les résumés générés par l’IA. La documentation de sécurité d’OpenAI affirmait que l’environnement d’exécution « ne peut pas générer de requêtes réseau sortantes directes ». Cette affirmation était techniquement correcte mais pratiquement incomplète : la résolution DNS restait ouverte, et cela suffisait.

Check Point a décrit la faille comme un « canal d’exfiltration caché » qu’« un seul prompt malveillant pouvait activer au sein d’une conversation ChatGPT ordinaire ». OpenAI a confirmé avoir « déjà identifié le problème sous-jacent en interne » et a déployé le correctif le 20 février 2026.

Séparément, Phantom Labs de BeyondTrust a divulgué une vulnérabilité d’injection de commandes dans OpenAI Codex, signalée le 16 décembre 2025 et corrigée le 5 février 2026.

Comment le canal DNS fonctionnait

L’environnement Data Analysis de ChatGPT exécute le code utilisateur dans un conteneur Linux isolé. Les connexions HTTP et TCP standard vers des hôtes externes sont bloquées. Cependant, le conteneur continuait d’effectuer des résolutions DNS dans le cadre de son fonctionnement normal.

Les chercheurs de Check Point ont exploité cette brèche en encodant les données volées en fragments compatibles DNS, les plaçant en sous-domaines dans des requêtes dirigées vers un domaine contrôlé par l’attaquant. Du côté de l’attaquant, les requêtes DNS entrantes étaient enregistrées et les fragments réassemblés pour reconstituer la charge utile originale.

Le canal était bidirectionnel. Des instructions pouvaient être renvoyées via les réponses DNS, ce qui signifiait qu’« un processus s’exécutant à l’intérieur du conteneur pouvait alors lire ces réponses, réassembler la charge utile et poursuivre l’échange ». Cela permettait non seulement le vol de données, mais aussi un accès shell distant complet à l’intérieur du conteneur, le tout invisible pour l’utilisateur et contournant entièrement les filtres de sécurité de ChatGPT.

Preuve de concept : des dossiers médicaux exfiltrés en temps réel

Check Point a créé un GPT personnalisé déguisé en analyseur de santé. Un utilisateur test a importé un PDF contenant des résultats de laboratoire avec des informations personnelles identifiantes. ChatGPT a traité le document et assuré à l’utilisateur que le fichier « n’était stocké que dans un emplacement interne sécurisé ». Pendant ce temps, le GPT malveillant avait déjà transmis « les données identifiantes du patient ainsi que l’évaluation du modèle » à un serveur distant.

L’attaque ne nécessitait aucune compétence technique de la part de la victime. Deux méthodes de diffusion ont été démontrées. Dans la première, l’utilisateur était incité à coller un prompt présenté comme une « astuce de productivité » contenant une logique d’exfiltration cachée. Dans la seconde, un GPT personnalisé piégé intégrait le code d’exfiltration dans ses instructions système, s’activant automatiquement pendant une conversation normale.

Les chercheurs ont souligné quatre propriétés rendant la faille dangereuse : l’invisibilité (aucun avertissement ni dialogue d’approbation), la facilité de distribution (via l’ingénierie sociale ou les fiches du GPT Store), l’exposition de données sensibles (dossiers médicaux, documents financiers, historiques de conversation) et la persistance (chaque message suivant dans la session était compromis une fois le prompt malveillant injecté).

Une seconde faille : le vol de tokens GitHub via Codex

Phantom Labs de BeyondTrust a identifié séparément une vulnérabilité d’injection de commandes dans OpenAI Codex. La faille provenait d’une désinfection insuffisante des entrées lors du traitement des noms de branches GitHub pendant l’exécution de tâches dans le cloud. Un attaquant pouvait créer un nom de branche malveillant injectant des commandes arbitraires dans le conteneur de l’agent Codex, récupérant le GitHub User Access Token et obtenant un accès en lecture et écriture sur l’intégralité de la base de code de la victime.

La vulnérabilité affectait le site web ChatGPT, le CLI Codex, le SDK Codex et l’extension IDE Codex. Elle a été signalée le 16 décembre 2025 et corrigée le 5 février 2026. OpenAI a déclaré qu’il n’existait aucune preuve que l’une ou l’autre des failles ait été exploitée activement.

Ce que cela signifie pour le traitement de fichiers

Les deux vulnérabilités partagent une cause commune : des fichiers et du code ont été importés dans un environnement cloud où l’utilisateur n’avait aucune visibilité sur ce qui se passait après la soumission. Le bac à sable de ChatGPT était conçu pour être isolé, et la documentation d’OpenAI le confirmait. Le canal DNS a prouvé le contraire.

Chaque fichier importé vers un service d’IA cloud transite par une infrastructure que l’utilisateur ne peut ni inspecter ni auditer. La faille d’exfiltration DNS est une démonstration concrète de la manière dont des documents sensibles (dossiers médicaux, contrats, relevés financiers) peuvent quitter un environnement « sécurisé » par des canaux jamais anticipés dans le modèle de menace.

Le traitement côté client élimine totalement cette surface d’attaque. Lorsqu’un fichier est traité en WebAssembly dans le navigateur, il n’y a pas de conteneur dont s’échapper, pas de résolveur DNS à détourner, et aucun serveur distant ne reçoit jamais le fichier. La logique de traitement s’exécute dans un bac à sable contrôlé par le navigateur lui-même, sans aucun accès réseau. Le fichier reste sur l’appareil parce qu’il n’a jamais été envoyé nulle part.

Pour les utilisateurs qui manipulent des documents sensibles, la question n’est pas de savoir si les fournisseurs cloud trouveront et corrigeront chaque canal secondaire. C’est de savoir si le fichier avait besoin de quitter l’appareil.

Sources

← Retour aux actualités