- 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
Aucun commentaire pour le moment.