Cybersécurité

DeepSeek : une base exposait chats privés et secrets d’API

Des chercheurs de Wiz ont découvert une base de données DeepSeek accessible sans authentification. Elle contenait plus d’un million d’entrées, avec des historiques de conversations, des journaux techniques et des secrets d’API. L’accès a été fermé moins d’une heure après le signalement, mais l’épisode pose une question centrale : que deviennent nos échanges avec les IA ?

Un analyste examine une base de données et des conversations exposées sur plusieurs écrans de sécurité.
Illustration : Actu.ai

Pour un assistant d’intelligence artificielle, une conversation peut contenir bien plus qu’une simple question : un brouillon professionnel, une demande d’aide technique, une idée de projet ou des informations personnelles. C’est pourquoi la découverte d’une base de données DeepSeek accessible publiquement suscite une vive inquiétude. Le problème ne relevait pas d’une attaque informatique sophistiquée, mais d’une protection élémentaire qui faisait défaut.

Le 29 janvier 2025, les chercheurs de l’entreprise de sécurité cloud Wiz ont indiqué avoir repéré une base de données associée à DeepSeek, société chinoise d’intelligence artificielle connue pour ses modèles conversationnels. La base, reliée à Internet et dépourvue d’authentification, exposait plus d’un million d’entrées contenant notamment des historiques de chat, des journaux techniques et des informations internes sensibles.

DeepSeek a limité l’accès après avoir été prévenue. Cette réaction rapide ne fait toutefois pas disparaître les questions essentielles : qui a pu voir ces données avant la fermeture, quels utilisateurs sont concernés, et quelles garanties de sécurité les services d’IA doivent-ils apporter à ceux qui leur confient des informations parfois sensibles ?

Ce que les chercheurs de Wiz ont découvert

La découverte porte sur une instance de ClickHouse, un système de gestion de bases de données conçu pour traiter rapidement de gros volumes d’informations. Il est fréquemment utilisé pour analyser des événements techniques, des journaux d’activité ou des données de production. Dans ce cas, l’instance identifiée par Wiz était directement accessible depuis Internet, sans identifiant ni mot de passe.

Les chercheurs ont pu accéder à une interface web donnant une vue sur la base et son contenu. D’après leur analyse, plus de 1 million d’entrées de journaux pouvaient être consultées. Elles comprenaient des éléments particulièrement délicats : des historiques de conversations avec le service, des flux de logs, des détails opérationnels, des points de terminaison d’API et des secrets d’API.

Élément identifié par WizPourquoi cela pose problème
Historiques de chatDes échanges avec un assistant peuvent contenir des données personnelles, professionnelles ou confidentielles.
Journaux techniquesIls peuvent révéler le fonctionnement d’un service, ses erreurs et certains détails de son infrastructure.
Points de terminaison d’APICes adresses techniques renseignent sur les composants internes auxquels une application se connecte.
Secrets et clés d’APIIls peuvent permettre l’accès à des services ou ressources s’ils sont encore valides et insuffisamment restreints.
Interface non authentifiéeUne personne qui trouvait la base pouvait l’interroger sans franchir de contrôle d’accès.

Il faut être précis sur les termes. Wiz a mis au jour une exposition publique de données, c’est-à-dire une base insuffisamment protégée et accessible. Cela ne démontre pas, à lui seul, qu’un tiers malveillant a téléchargé ou exploité l’ensemble des informations. Mais dès lors que l’accès est ouvert, il devient impossible d’exclure que des visiteurs non autorisés aient consulté les données avant la correction.

Pourquoi une base ClickHouse ouverte est-elle si préoccupante ?

Dans une architecture informatique moderne, une base de données n’est pas un simple fichier posé sur un serveur. Elle est souvent connectée à des applications, à des outils d’analyse et à des services internes. Une configuration défaillante peut donc ouvrir plusieurs risques à la fois : lecture de données, extraction massive d’informations, modification d’enregistrements ou récupération d’indices utiles pour atteindre d’autres composants.

Wiz explique que la configuration observée permettait un contrôle étendu sur la base de données et pouvait potentiellement déboucher sur l’exécution de code sans supervision. Cette possibilité est particulièrement sensible, car elle va au-delà de la seule consultation de messages. Des secrets techniques ou des clés d’accès présents dans des journaux peuvent, selon leur nature et leur validité, augmenter l’exposition d’une infrastructure.

Dans le cas des outils d’IA générative, l’enjeu est amplifié par le type de contenu confié au chatbot. Les utilisateurs ont tendance à considérer la fenêtre de discussion comme un espace personnel. Or, une conversation peut inclure :

  • des extraits de documents de travail ou de code informatique ;
  • des données sur un client, un produit ou une stratégie d’entreprise ;
  • des informations permettant d’identifier une personne ;
  • des éléments privés partagés dans le cadre d’une demande d’assistance.

Il ne faut pas en déduire que chaque conversation DeepSeek contenait de telles données, ni que chacune a été lue. L’incident rappelle en revanche une règle de prudence valable pour tous les assistants : une information saisie dans un service en ligne doit être traitée comme une donnée susceptible d’être stockée et traitée sur l’infrastructure de son fournisseur.

Exposition publique et fuite confirmée : ce qui est établi

Ce qui est établi et ce qui reste inconnu

Éléments confirmés

  • Une base ClickHouse liée à DeepSeek était accessible publiquement sans authentification.
  • Wiz y a observé plus d’un million d’entrées de journaux.
  • Des historiques de chat, des détails internes et des secrets d’API figuraient parmi les données accessibles.
  • DeepSeek a restreint l’accès moins d’une heure après avoir été alertée.

Éléments non établis

  • Le nombre exact de conversations et d’utilisateurs concernés n’est pas connu.
  • Aucune information publique ne confirme que des tiers ont copié les données.
  • L’usage éventuel des secrets d’API exposés n’est pas établi.
  • La méthode et le calendrier d’information des utilisateurs restent inconnus.

La distinction est importante pour ne pas dramatiser au-delà des faits, mais aussi pour ne pas minimiser l’incident. Une base laissée ouverte est une vulnérabilité concrète. Sa fermeture réduit le risque immédiat de nouvelle consultation, sans répondre automatiquement à la question des accès antérieurs.

Au 30 janvier 2025, les informations rendues publiques ne permettent pas d’établir combien de conversations étaient concernées parmi les entrées détectées, si des données ont été copiées par des tiers ou si DeepSeek préviendra les utilisateurs potentiellement affectés. Elles ne permettent pas non plus de savoir si des clés présentes dans la base ont été utilisées avant leur éventuelle révocation.

DeepSeek a fermé l’accès après le signalement

Wiz indique avoir tenté de joindre DeepSeek afin de lui signaler l’exposition. L’entreprise n’avait pas répondu aux sollicitations de commentaire rapportées par les chercheurs au moment de leur publication. Elle a cependant agi rapidement sur le plan technique : l’accès à la base a été restreint moins d’une heure après l’alerte.

Cette rapidité constitue un point important. Dans la gestion d’un incident de sécurité, la première étape est de contenir le problème, autrement dit fermer l’accès vulnérable et empêcher de nouvelles consultations. Viennent ensuite des opérations moins visibles, mais tout aussi cruciales : examiner les journaux d’accès, déterminer l’étendue des données concernées, renouveler les secrets potentiellement exposés et évaluer la nécessité d’informer les personnes touchées.

Aucun détail public n’était alors disponible sur ces étapes ultérieures. Or, la qualité de la réponse ne se mesure pas seulement au temps nécessaire pour fermer une porte restée ouverte. Elle dépend aussi de la capacité à comprendre ce qui s’est produit, à limiter les conséquences et à prévenir la répétition du même incident.

Que peuvent faire les utilisateurs de DeepSeek ?

Les personnes ayant utilisé DeepSeek ne disposent pas, au 30 janvier 2025, d’une liste publique des conversations concernées ni d’éléments permettant de savoir individuellement si leurs échanges figuraient dans la base observée par Wiz. Dans cette situation, quelques précautions raisonnables s’imposent, sans céder à la panique.

D’abord, il est prudent de vérifier que le compte DeepSeek utilise un mot de passe long, unique et non réemployé sur d’autres services. Cette recommandation est générale : les historiques de chat exposés ne signifient pas nécessairement que les mots de passe ont été compromis. Mais éviter la réutilisation limite fortement les dégâts lorsqu’un incident touche un service en ligne.

Il est également conseillé de se méfier des courriels ou messages qui prétendraient provenir de DeepSeek et exploiteraient l’inquiétude autour de cette exposition. Une conversation ou une information technique divulguée peut parfois aider des fraudeurs à produire des messages plus crédibles. Il ne faut ni communiquer un code de connexion, ni ouvrir précipitamment une pièce jointe, ni se connecter à partir d’un lien reçu sans vérification.

Enfin, cet épisode invite à adapter ses usages des IA conversationnelles. Il est préférable de ne pas transmettre de mots de passe, de clés d’accès, de données bancaires, de documents confidentiels non anonymisés ou d’informations médicales identifiantes. Lorsqu’un document doit être analysé, remplacer les noms, coordonnées et références sensibles par des éléments fictifs réduit l’exposition potentielle.

Un rappel pour tout le secteur de l’IA

La montée en puissance de DeepSeek attire l’attention sur ses modèles et ses performances, mais l’incident révélé par Wiz concerne un enjeu moins visible : la sécurité opérationnelle. Les assistants d’IA sont devenus des portes d’entrée vers d’immenses volumes de données, à la fois celles des utilisateurs et celles nécessaires au fonctionnement de leurs plateformes.

Gal Nagli, chercheur chez Wiz, souligne que les risques les plus immédiats de l’IA ne sont pas nécessairement les scénarios futuristes souvent évoqués. Ils peuvent aussi venir de défaillances plus classiques, comme une base de données exposée par erreur. Cette observation vaut pour les jeunes pousses comme pour les grands groupes : déployer rapidement une technologie ne doit pas reléguer au second plan les contrôles d’accès, la gestion des secrets et la surveillance des environnements cloud.

Pour les entreprises qui utilisent des outils d’IA, l’enseignement est double. Elles doivent évaluer les engagements de sécurité de leurs fournisseurs, mais aussi former leurs équipes à ne pas utiliser un chatbot public comme un coffre-fort documentaire. Une charte interne claire peut préciser quelles catégories de données sont autorisées, anonymisées ou strictement interdites dans un assistant externe.

La question réglementaire est également appelée à prendre plus de place. En Europe, le cadre de protection des données personnelles impose des obligations aux organisations concernées par le traitement de données de résidents européens, notamment en matière de sécurité et, selon les cas, de notification des violations. La situation précise d’un fournisseur dépend toutefois de son activité, de son implantation et des données qu’il traite. L’incident DeepSeek illustre surtout l’importance de pouvoir démontrer, au-delà des promesses commerciales, que les protections techniques sont réellement en place.

Ce qu’il faut surveiller

Les prochains éléments importants seront d’abord techniques : DeepSeek indiquera-t-elle quels types précis de données étaient présents dans la base, et confirmera-t-elle le renouvellement des secrets d’API potentiellement exposés ? Il faudra ensuite savoir si l’entreprise a identifié des accès non autorisés dans ses propres journaux et si elle prévoit de contacter les utilisateurs concernés.

Cette affaire pourrait aussi nourrir un débat plus large sur la transparence des services d’IA. Pour gagner la confiance du public, les plateformes ne peuvent pas se limiter à mettre en avant la qualité de leurs modèles. Elles doivent expliquer de façon compréhensible comment les conversations sont stockées, qui peut y accéder, combien de temps elles sont conservées et quelles protections s’appliquent aux données les plus sensibles.

L’épisode de DeepSeek ne prouve pas que tous les assistants d’IA sont dangereux pour la confidentialité. Il rappelle une réalité plus simple : derrière une conversation apparemment immatérielle se trouvent des serveurs, des bases de données, des clés techniques et des choix de configuration. La sécurité de ces fondations conditionne directement la confiance que les utilisateurs peuvent accorder à l’IA.

Questions fréquentes

Quelles données DeepSeek a-t-elle exposées ?

Selon l’analyse de Wiz, la base accessible contenait plus d’un million d’entrées, incluant des historiques de chat, des journaux techniques, des détails opérationnels, des points de terminaison d’API et des secrets d’API. Les informations publiées ne permettent pas de savoir combien de conversations d’utilisateurs figuraient précisément parmi ces données.

Les conversations DeepSeek ont-elles été volées ?

Il est établi qu’une base non protégée était publiquement accessible. En revanche, au 30 janvier 2025, aucune information publique ne permet de confirmer qu’un tiers a téléchargé, copié ou exploité les historiques de chat. Une exposition constitue néanmoins un risque, car des visiteurs non autorisés ont pu accéder à la base avant sa fermeture.

DeepSeek a-t-elle corrigé la faille de sécurité ?

Oui. Wiz indique que DeepSeek a restreint l’accès à la base de données moins d’une heure après avoir été avertie. Cette mesure bloque l’accès public constaté par les chercheurs. Les détails concernant l’enquête interne, le renouvellement des clés potentiellement exposées ou l’information des utilisateurs n’étaient pas publics au 30 janvier 2025.

Que faire si j’ai utilisé DeepSeek ?

Utilisez un mot de passe unique pour votre compte et restez vigilant face aux messages frauduleux qui pourraient exploiter l’incident. Il est aussi recommandé de ne jamais saisir dans un chatbot des mots de passe, des clés d’API, des données bancaires ou des documents confidentiels non anonymisés. Ces précautions sont utiles pour tout service d’IA en ligne.

Pourquoi une base de données sans authentification est-elle dangereuse ?

Sans authentification, une personne capable de trouver l’interface peut consulter les données sans identifiant ni mot de passe. Si la base contient des conversations, des journaux techniques ou des clés d’accès, elle peut révéler des informations privées et des détails sur l’infrastructure du service. Une mauvaise configuration suffit donc à créer un risque majeur, sans attaque complexe.

Sources

Références consultées pour la rédaction de cet article. Les adresses sont indiquées à titre informatif et ne sont pas des liens.

  1. Wiz Research, exposition d’une base ClickHouse de DeepSeekwww.wiz.io
  2. CNIL, obligations en cas de violation de données personnelleswww.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles