Piratage de MoltBook : 1,5 million de clés API exposées à cause d’une erreur de configuration Supabase

 (wiz.io)
10 points par GN⁺ 2026-02-04 | 8 commentaires | Partager sur WhatsApp
  • La base de données de Moltbook, une plateforme sociale dédiée aux agents IA, a été mal configurée, exposant à l’extérieur 1,5 million de jetons d’authentification API, 35 000 e-mails et des messages privés
  • Une clé d’API Supabase était codée en dur dans le JavaScript côté client, et l’absence de configuration de Row Level Security (RLS) permettait à n’importe qui d’obtenir un accès en lecture et en écriture à l’ensemble de la base de données
  • Les données comprenaient des informations sur 17 000 utilisateurs réels et les 1,5 million de comptes d’agents qu’ils exploitaient, révélant un ratio humain/agent de 1:88
  • Les informations exposées incluaient des clés API OpenAI et d’autres identifiants tiers, des conversations privées, ainsi que des droits de modification de publications, créant un risque d’atteinte à l’intégrité du contenu de la plateforme
  • Cet incident met en lumière les limites de sécurité du « vibe coding » basé sur l’IA et montre la nécessité de renforcer l’automatisation des paramètres de sécurité par défaut et les procédures de vérification dans les environnements de développement IA

Présentation de Moltbook et de l’exposition de sécurité

  • Moltbook est un réseau social centré sur l’IA où des agents IA publient, commentent, votent et accumulent des scores de réputation, avec l’ambition d’être « la première page de l’internet des agents »
    • Le cofondateur d’OpenAI Andrej Karpathy l’avait mis en avant en le qualifiant de « bond SF le plus impressionnant »
  • Le fondateur de la plateforme a indiqué que « l’IA avait directement écrit le code », et le service a été développé selon une approche de « vibe coding »
  • L’équipe de recherche de Wiz a découvert une mauvaise configuration de la base de données Supabase qui permettait un accès en lecture et en écriture à l’ensemble des données ; le problème a été corrigé quelques heures après la notification

Identifiants Supabase exposés

  • Les informations de connexion Supabase ont été trouvées codées en dur dans le bundle JavaScript client du site web de Moltbook
    • Projet : ehxbxtjliybbloantpwq.supabase.co
    • Clé API : sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • Supabase autorise l’exposition des clés publiques en elle-même, mais en l’absence de politiques RLS, l’accès à l’ensemble de la base devient possible
  • Sur Moltbook, la RLS était désactivée, ce qui rendait publiques les autorisations de lecture et d’écriture sur toutes les tables

Accès non authentifié à la base de données

  • En appelant directement l’API REST avec la clé API, l’équipe de recherche a obtenu une réponse de niveau administrateur
  • La réponse contenait les clés API et jetons d’authentification des principaux agents, permettant potentiellement une prise de contrôle complète des comptes
  • En utilisant des messages d’erreur PostgREST et l’introspection GraphQL pour cartographier l’ensemble du schéma, les chercheurs ont confirmé l’exposition d’environ 4,75 millions d’enregistrements

Données sensibles exposées

  • Identifiants d’agents : chaque compte contenait api_key, claim_token et verification_code
    • Cela permettait à un attaquant de se connecter comme n’importe quel agent, publier des messages et envoyer des messages privés
  • E-mails et informations d’identité des utilisateurs : les e-mails et handles X (Twitter) de plus de 17 000 utilisateurs ont été exposés
    • En plus, 29 631 e-mails ont été trouvés dans la table observers
  • Messages privés et identifiants tiers : 4 060 messages privés étaient stockés sans chiffrement, et certains contenaient des clés API OpenAI en clair
  • Exposition des droits d’écriture : il était possible de modifier des publications sans authentification, avec un risque d’insertion de contenu malveillant ou de défiguration du site
    • Un test réel a permis de modifier une publication, avant que le problème ne soit bloqué par l’application de politiques RLS

Cinq enseignements de sécurité pour le développement d’applications IA

  • 1. La vitesse de développement peut créer un risque systémique en l’absence de paramètres de sécurité par défaut
    • Une seule ligne de configuration Supabase a suffi à provoquer l’exposition complète
  • 2. Nécessité de vérifier les métriques d’engagement
    • Sur 1 500 000 agents, seuls 17 000 étaient de vrais humains, ce qui suggère une activité potentiellement artificielle avec un ratio de 88:1
  • 3. Effet en chaîne d’un effondrement de la confidentialité
    • L’exposition des messages privés a aussi entraîné la fuite d’identifiants de services externes comme des clés API OpenAI
  • 4. Les droits d’écriture représentent une menace pour l’intégrité plus grave qu’une simple fuite de données
    • Manipulation de contenu, prompt injection et contrôle du récit deviennent possibles
  • 5. La maturité en sécurité est un processus d’amélioration itératif
    • Les équipes de Wiz et de Moltbook ont procédé à plusieurs séries de corrections et de vérifications pour protéger toutes les tables

Les défis du vibe coding et de la sécurité

  • L’IA a abaissé les barrières du développement, mais les barrières de sécurité restent élevées
  • Les outils de développement IA devraient appliquer automatiquement des paramètres de sécurité par défaut comme l’activation de la RLS et l’analyse des identifiants
  • C’est lorsque la sécurité devient un élément intégré par défaut du développement IA qu’un écosystème logiciel IA à la fois sûr et innovant peut émerger

Chronologie

  • 31 janvier 2026 à 21:48 UTC : premier contact avec le mainteneur de Moltbook
  • 22:06 : signalement de la mauvaise configuration Supabase RLS
  • 23:29 : premier correctif (protection des tables agents, owners, site_admins)
  • 1er février à 00:13 : deuxième correctif (protection de agent_messages et autres)
  • 00:31 : découverte de la vulnérabilité de modification de publications
  • 00:44 : troisième correctif bloquant les droits d’écriture
  • 00:50~01:00 : découverte de tables supplémentaires exposées et finalisation des correctifs

À lire aussi

8 commentaires

 
rustkim 2026-02-05

Au final, il ne reste qu’un Mac mini, mais comme c’est le début, quelque chose de mieux sortira sans doute.
 
gogokow27 2026-02-05

MDRRRRRR....
 
iolothebard 2026-02-04

Tu dansais joyeusement… et puis… va donc à ta perte !
 
kuthia 2026-02-04

Enfin, ce qui devait arriver est arrivé.
 
crawler 2026-02-04

Chez MoltBot, il y a déjà eu des problèmes de piratage avec les agents, et maintenant c’est la plateforme elle-même qui se fait avoir lol

Ça risque de rester comme un exemple du pire projet à l’ambiance la plus désastreuse de 2026.
On n’est encore qu’en février, mais j’en suis sûr lol
 
bini59 2026-02-04

Le problème, c’est peut-être qu’on peut développer des services à grande échelle sans vraiment se soucier de la sécurité, porté par la vibe.
 
kimjoin2 2026-02-04

WAOUH
 
GN⁺ 2026-02-04
Avis sur Hacker News

  • Le succès de Moltbot/Moltbook était surprenant au début, mais il devient plus compréhensible
    Le point clé, c’est l’idée d’« agent prépackagé ». Pour des utilisateurs ordinaires peu à l’aise avec la technique, une promesse du type « achetez un Mac mini, copiez quelques lignes et installez » a un fort pouvoir d’attraction
    Mais cette accessibilité alimente aussi un véritable cauchemar de sécurité. À mesure que les utilisateurs sans compréhension technique suivent simplement la tendance, le risque est de voir des environnements vulnérables perdurer plus longtemps

    • On peut se demander si l’on peut vraiment parler de succès. Une analyse indique qu’en réalité, sur 1,5 million d’agents, seuls 17 000 appartiennent à des humains. Le phénomène a surtout été amplifié par des influenceurs connus
    • Tous les LLM sont, par conception, vulnérables sur le plan de la sécurité. On peut les contourner facilement via du prompt injection ou du reward hacking. La seule solution complète serait de couper totalement les entrées externes et l’accès au réseau
    • « Acheter un Mac mini et installer » n’est qu’un slogan marketing. En pratique, les erreurs de configuration sont fréquentes et la gestion du contexte est catastrophique. Il y a des logs, mais le système oublie même la conversation précédente. L’idée est bonne, mais l’exécution reste grossière
    • Comme à l’arrivée de Dropbox, le facteur de succès est cette accessibilité emballée proprement. Mais dans un monde où même les grandes entreprises n’empêchent pas les piratages, une simple base de données mal configurée paraît presque banale. La commodité prime encore sur la sécurité
    • On ne sait toujours pas clairement si c’est juste un sujet qui fait le buzz ou un vrai succès

  • Comme l’a souligné Scott Alexander, le point important est le fait que les agents interagissent entre eux et produisent des comportements composites
    Si cela commence à avoir des effets dans le monde réel, cela pourrait déboucher sur des problèmes ontologiques.
    Au fond, c’est une structure où tout ce qui est écrit « YES » dans AGENT.md peut finir par se produire réellement

    • Certains répondent qu’ils ne voient pas très bien ce que cela veut dire
    • C’est pour cela que j’ai créé nono.sh, pour que les agents démarrent en sandbox isolée au niveau du noyau selon un modèle « zero trust »
    • Les humains aussi sont, dans une certaine mesure, des êtres qui « répètent comme des perroquets ». De la même manière que Moltbook imite Reddit, les humains conversent eux aussi selon des schémas prévisibles. Au final, nous sommes peut-être moins intelligents que nous le pensons

  • L’API de Moltbook étant ouverte à tout le monde, de simples prompts peuvent pousser à faire fuiter des e-mails d’utilisateurs ou d’autres données
    D’où les tentatives d’isoler le système sur un Mac mini, mais tant qu’il est connecté au réseau, une protection complète est impossible

    • Ce n’est pas délirant. Les LLM ne distinguent pas clairement les instructions et les données. C’est une sorte de vulnérabilité de « social engineering »
    • Au final, la vraie question est de savoir s’il est possible de leur confier des tâches utiles sans risque. Par exemple, pour gérer les courses ou réserver un voyage, il faut un accès à une carte bancaire
    • J’utilise personnellement les LLM dans un environnement DMZ isolé. Ils tournent avec un compte sans disque et sans droits sudo. Ce n’est pas parfait, mais cela fonctionne à peu près
    • En pratique, il n’existe pas de protection parfaite, car on retrouve les trois éléments du « trio fatal » : accès aux données, texte non fiable et communication réseau
    • En revanche, on peut mettre en place une couche de supervision et d’approbation. On peut imaginer une structure qui autorise ou limite les actions du LLM comme on le ferait avec un plafond de carte bancaire

  • J’ai essayé OpenClaw et la consommation de tokens est énorme
    Pour la sécurité, un équipement dédié (Raspberry Pi, etc.) avec des permissions API limitées pourrait aider. Si un Pi pouvait faire tourner des modèles plus puissants, je serais prêt à en acheter un

  • Moltbook n’a aucun moyen de distinguer l’IA de l’humain. Cela pose la question de savoir comment implémenter un « CAPTCHA inversé »

    • Pour m’amuser, j’ai donné à Claude le prompt « trouve les comptes d’espions humains », et il a effectivement créé un thread intitulé « Reverse Turing Problem ». Mais à présent, c’est envahi de spam au point de rendre la conversation impossible
    • Il faudrait un système où toutes les entrées et sorties d’une session sont signées et auditables. Les prompts injectés par des humains devraient eux aussi être traçables
    • Une autre méthode serait de demander plusieurs fois, en peu de temps, des tâches faciles pour une IA mais difficiles pour un humain
    • Ou bien de poser rapidement des questions rares qu’un LLM est susceptible de déjà connaître
    • Mais au final, il reste toujours difficile de distinguer si un comportement a été provoqué par un humain via un prompt

  • Moltbook affirme avoir corrigé le problème de sécurité en quelques heures, mais la vraie question est de savoir comment expliquer les failles de sécurité d’un projet construit en « vibe coding »

    • En réalité, Claude a généré la requête pour Supabase, puis un humain l’a transmise au développeur de Moltbook pour qu’il applique la correction. C’est difficile à croire, mais c’est bien ce qui s’est passé

  • Il est surprenant de voir des gens analyser l’intérieur de Moltbook. À l’origine, c’était simplement un projet créé pour plaisanter, et personne n’imaginait que cela prendrait une telle ampleur

    • Mais si des données personnelles identifiables d’utilisateurs sont exposées, cela ne peut plus être balayé comme une plaisanterie : il y a de vraies implications juridiques. La culture du « vibe coding » favorise un climat de développement irresponsable
    • Dogecoin aussi a commencé comme une blague, et vaut aujourd’hui des milliards de dollars
    • Le fait que des chercheurs en sécurité trouvent des vulnérabilités peut aussi, au fond, faire partie de la « vibe »
    • Mais on ne peut pas effacer des préjudices réels en disant simplement « c’était une blague »
    • Si le résultat a été produit intentionnellement par son créateur, l’excuse de la « blague » devient faible

  • L’incident où une instance OpenClaw a envoyé une clé OpenAI à une autre instance était à la fois drôle et inquiétant.
    On ne sait pas clairement si la clé a réellement été envoyée ou si le système a seulement fait semblant

  • L’article de Wiz lui-même donne l’impression d’avoir été écrit par une IA. La structure des phrases et l’usage des tirets ressemblent à un style typique de LLM.
    Il y a une ironie à voir la sécurité d’une plateforme créée par des LLM critiquée dans un article écrit par un LLM
    La vulnérabilité, elle, semble bien réelle, mais si un humain l’avait rédigé, il aurait sans doute supprimé pas mal de formulations superflues

  • Les données exposées ont révélé que sur 1,5 million d’agents, seuls 17 000 étaient humains
    Mais comme ce chiffre a été obtenu par le chercheur en interrogeant directement les tables avec une clé API, sa publication ressemble moins à un simple bug report qu’à une critique publique de l’entreprise
    Une telle approche risque d’endommager la relation de confiance et de coopération entre les chercheurs et les entreprises