Base de données Moltbook entièrement ouverte : 1,5 million de clés API d'agents, 35 000 e-mails

Moltbook est un réseau social de type Reddit conçu pour que seuls des agents IA puissent publier. Son fondateur, Matt Schlicht, l'a lancé le 28 janvier 2026 et a déclaré publiquement sur X qu'il n'avait pas écrit une seule ligne de son code : « Je n'avais qu'une vision de l'architecture technique, et l'IA l'a concrétisée », comme le cite Wiz. Trois jours plus tard, le 31 janvier 2026, 404 Media a rapporté que n'importe qui pouvait prendre le contrôle de n'importe quel agent IA du site. Wiz, qui avait découvert indépendamment la même mauvaise configuration, a publié le compte rendu technique le 2 février : une clé API Supabase codée en dur dans le JavaScript côté client de Moltbook pointait vers une base de données de production sans sécurité au niveau des lignes (Row Level Security), et une requête non authentifiée à la table agents renvoyait des jetons d'authentification actifs pour les agents de la plateforme, y compris les plus connus. Wiz a compté 1,5 million de jetons API, 35 000 adresses e-mail et 4 060 conversations privées entre agents lisibles de cette manière, et a confirmé qu'il pouvait également réécrire des publications en direct. L'archive classe l'épisode comme un incident d'identifiants de gravité critique avec une date précise au jour près du 31 janvier 2026, une note de confiance de A et des dommages réels enregistrés, aux côtés du reste de ses dossiers d'infrastructure d'agents dans l'Orca AI Incident Archive.

La clé n'a jamais été le secret

Supabase est un service Postgres hébergé avec une API REST que Wiz décrit comme populaire auprès des applications vibe-coded parce qu’il est facile à configurer. Sa clé publiable est conçue pour être placée dans le code côté client : elle identifie le projet, et le contrôle d’accès est censé provenir des politiques Row Level Security sur les tables qui se trouvent derrière. Gal Nagli, de Wiz, énonce explicitement ce point dans l’analyse : exposer la clé « n’indique pas automatiquement une défaillance de sécurité », et lorsque RLS est correctement configuré, « la clé API publique peut être exposée sans danger - elle agit comme un identifiant de projet ». Dans l’implémentation de Moltbook, écrit Wiz, « cette ligne de défense critique était absente ».

Le mécanisme reposait sur un bundle. Selon Wiz, le fichier JavaScript de production à l'adresse moltbook.com/_next/static/chunks/18e24eafc444b2b9.js contenait à la fois l'adresse du projet Supabase, ehxbxtjliybbloantpwq.supabase.co, et la clé, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz a ensuite envoyé une requête à la table agents demandant trois noms et clés API, une requête qui aurait dû renvoyer un tableau vide ou une erreur d'autorisation. Elle a plutôt renvoyé des lignes, dont les jetons d'authentification des agents les plus populaires de la plateforme. À partir de là, Wiz a cartographié le schéma à l'aide des messages d'erreur PostgREST et de l'introspection GraphQL, et a compté environ 4,75 millions d'enregistrements exposés.

Le résumé de l’archive indique que Moltbook « n’a jamais activé » la sécurité au niveau des lignes, et les sources sont plus floues que cela. Aucune des deux ne présente d’historique de configuration, si bien que ce qui est documenté, c’est que RLS n’était pas en vigueur pendant l’examen : Wiz a trouvé les tables ouvertes, et Implicator.ai, rapportant le témoignage de la personne ayant fait la découverte, écrit que Moltbook « n’a jamais activé RLS. Ou, si tel a été le cas, aucune politique n’était configurée. » Que le paramètre n’ait jamais été activé ou qu’il ait été activé sans aucune politique en place n’est établi par aucun des deux comptes rendus, et le résultat pratique est le même.

Qu'y avait-il réellement dans les tables ?

Wiz nomme les tables et leur contenu. La table agents contenait, pour chaque ligne, l'api_key qui authentifiait l'agent, un claim_token servant à revendiquer sa propriété, un verification_code émis lors de l'inscription, ainsi que le karma et le nombre d'abonnés de l'agent. Il s'agit d'une véritable panoplie complète de prise de contrôle de compte plutôt que d'une fuite de données : avec l'une de ces clés, une requête peut publier, envoyer des messages et agir de toute autre manière en tant que cet agent, et Wiz note que cela incluait des comptes à fort karma et des agents personnages bien connus.

La table owners contenait des informations personnelles pour plus de 17 000 utilisateurs, notamment des adresses e-mail ainsi que l’identifiant X et le nom d’affichage associés à chaque agent. Une table que Wiz a trouvée plus tard via le point de terminaison GraphQL, observers, contenait 29 631 autres adresses e-mail appartenant aux inscriptions en accès anticipé au produit « Build Apps for AI Agents » prévu par Moltbook. La table agent_messages contenait 4 060 conversations privées par messages directs entre agents, stockées sans chiffrement ni contrôles d’accès, et Wiz rapporte que certaines contenaient des identifiants tiers en texte clair, notamment des clés API OpenAI que les agents s’étaient partagées entre eux.

Le rapport entre les agents et les personnes est ce qui sapait le récit public de la plateforme. Wiz rapporte 1,5 million d’agents enregistrés pour environ 17 000 propriétaires humains, soit environ 88 agents par personne, et attribue cet écart à l’absence de limitation de débit ou de vérification d’identité : n’importe qui pouvait enregistrer des agents en boucle, et un humain pouvait publier en tant qu’« agent » avec une simple requête POST. La conclusion de Wiz est sans détour : « le réseau social IA révolutionnaire était en grande partie des humains pilotant des flottes de bots. »

Le décompte des e-mails ne tombe pas juste et Wiz n’explique pas pourquoi. Son chiffre phare est de 35 000 adresses e-mail ; ses propres décomptes au niveau des tables sont de plus de 17 000 e-mails de propriétaires et 29 631 e-mails d’observateurs, soit un total d’environ 46 600. Les deux chiffres sont ceux de Wiz, et cet article n’a pas établi comment les 35 000 ont été obtenus — que ce soit par déduplication entre les deux tables ou à partir d’un instantané pris avant que la table des observateurs ne soit trouvée.

La moitié écriture de l’exposition

La lecture des données ne constituait pas toute la découverte. Wiz rapporte que, même après la première série de correctifs ayant bloqué l’accès en lecture aux tables sensibles, l’accès en écriture aux tables publiques est resté ouvert. Il a testé cela en envoyant une requête PATCH à une publication en ligne et en remplaçant son titre et son corps par la chaîne « @galnagli - responsible disclosure test », puis a confirmé que la modification était visible sur le site. Après l’instauration de la restriction d’écriture, Wiz ne pouvait plus annuler sa propre publication de test ; l’équipe Moltbook a supprimé le contenu quelques heures plus tard, écrit Wiz, et a remercié les chercheurs pour le rapport.

La préoccupation exprimée par Wiz n’est pas la défiguration pour elle-même. Un chemin d’écriture non authentifié vers les publications signifie que n’importe qui pourrait injecter des charges utiles d’injection de prompt dans du contenu que d’autres agents lisent, et Wiz présente l’intégrité des publications, des votes et du karma de la plateforme pendant la fenêtre d’exposition comme une question ouverte plutôt que comme une question mesurée. Aucune source consultée pour cet article ne quantifie la quantité de contenu modifiée ni par qui.

Trois heures et douze minutes, quatre corrections distinctes

La chronologie de divulgation de Wiz commence à 21 h 48 UTC le 31 janvier 2026, avec un premier contact avec le mainteneur de Moltbook par message direct sur X, et se termine à 01 h 00 UTC le 1er février, lorsque la dernière des tables exposées a été sécurisée. Après ce premier contact, elle consigne sept autres étapes : le rapport à 22 h 06, un premier correctif à 23 h 29 couvrant les tables agents, owners et site_admins, un deuxième à 00 h 13 couvrant agent_messages, notifications, votes et follows, la découverte du chemin d’écriture à 00 h 31, le troisième correctif le fermant à 00 h 44, la découverte des tables observers, identity_verifications et developer_apps à 00 h 50, et le correctif final à 01 h 00.

Cette chronologie est l'argument le plus fort contre la version la plus simple de cette histoire. Implicator.ai décrit le correctif en deux instructions SQL — il écrit que « le correctif nécessitait deux instructions SQL. Elles n'existaient pas », et le résumé de l'archive reprend le même cadrage en « deux lignes de SQL ». La réparation centrale de l'exposition en lecture était probablement aussi minime : activer RLS et ajouter des politiques sur les tables. Mais le propre compte rendu de Wiz montre quatre correctifs sur trois heures, une seconde faille d'accès en écriture distincte que le correctif de lecture n'a pas comblée, et trois autres tables — dont les 29 631 adresses d'observateurs — qui n'ont émergé qu'après les deux premières séries. La leçon finale de Wiz est qu'il « a travaillé avec l'équipe à travers plusieurs cycles de remédiation, chaque itération faisant apparaître des surfaces exposées supplémentaires ». La version en deux lignes décrit le changement de configuration, pas la remédiation.

Deux découvertes, et une différence dans le dossier

La découverte est généralement attribuée à Jamieson O'Reilly, qui a fondé la société de sécurité australienne Dvuln et qui a démontré la prise de contrôle à 404 Media ; Implicator.ai rapporte que 404 Media a vérifié la capacité en mettant à jour le compte Moltbook d'O'Reilly lui-même avec son autorisation. Le billet de Wiz est de Gal Nagli et comporte une note à la fin créditant O'Reilly : « Le chercheur en sécurité Jameson O'Reilly a également découvert la mauvaise configuration Supabase sous-jacente, qui a été signalée par 404 Media. » La note ajoute que le billet de Wiz fait état d'une découverte indépendante du même problème.

Le résumé de l’archive les présente tous deux comme des chercheurs de Wiz. La publication de Wiz elle-même ne le fait pas : elle nomme Nagli comme auteur et décrit O’Reilly comme un chercheur indépendant dont la découverte a été rapportée par 404 Media, et Implicator.ai situe O’Reilly chez Dvuln. L’orthographe n’est pas non plus fixée selon les sources – Wiz écrit « Jameson », tandis que le site de Dvuln lui-même liste son fondateur comme « Jamieson » – et cet article a utilisé l’orthographe employée par ce site. Ce qui n’est pas contesté, c’est qu’il y a eu deux découvertes indépendantes de la même erreur de configuration en quelques jours.

Le récit de la réponse diffère selon la source, et cette différence mérite d’être signalée plutôt que résolue. Selon le récit d’O’Reilly, relayé par Implicator.ai, il a approché Schlicht directement et proposé d’aider à corriger la faille ; la réponse a été : « Je vais simplement tout donner à l’IA. Alors envoyez-moi tout ce que vous avez. » Une journée entière s’est alors écoulée sans suivi, selon ce récit, et Schlicht n’a pas répondu à la demande de commentaire de 404 Media. Wiz, qui a contacté le mainteneur séparément, consigne son rapport déposé à 22 h 06 UTC et la dernière de quatre corrections à 01 h 00 UTC, trois heures et douze minutes après le premier contact. Les deux chronologies passent par des canaux différents et aucune des deux sources ne dit si l’une a déclenché l’autre ; les deux peuvent être exactes.

Ce que le dossier établit, et ce qu’il n’établit pas

Les faits établis sont la configuration, les classes de données, les deux découvertes indépendantes, la séquence de correction et le ratio humains-agents de la plateforme. Tout dans cette liste provient du rapport technique de première main de Wiz ou d'articles fondés sur le récit du découvreur, et les deux s'accordent sur le mécanisme.

Ce qui n’est pas établi commence par l’accès antérieur. Wiz déclare que toutes les données consultées pendant ses recherches et la vérification de son correctif ont été supprimées, ce qui ne dit rien sur quiconque d’autre. Implicator.ai expose clairement la lacune : personne ne peut dire si quelqu’un a trouvé la base de données avant O’Reilly, ni combien des publications qui ont circulé pendant la semaine virale de la plateforme étaient de véritables productions d’un agent et combien provenaient d’une clé volée. Aucune source consultée pour cet article ne signale un usage abusif confirmé d’un identifiant exposé, et aucune ne rapporte le nombre de comptes réellement compromis. L’indicateur real_harm de l’archive est vrai parce que des données personnelles et des identifiants tiers actifs étaient réellement lisibles par n’importe qui, et non parce qu’un usage abusif précis a été enregistré.

Les décomptes d’agents divergent également, et la divergence suit la croissance de la plateforme plutôt que les faits de l’exposition. Implicator.ai, écrivant le 1er février à partir du compte du découvreur, décrit « plus de 32 000 » agents enregistrés — dans un article qui indique aussi que le site a dépassé les 37 000 lors de sa première semaine — et 1,49 million d’enregistrements exposés. Wiz, dans son examen du 2 février, a compté 1,5 million d’agents et environ 4,75 millions d’enregistrements. Le résumé de l’archive indique que la plateforme a fini par accumuler 1,7 million d’agents enregistrés et près de 7 millions de commentaires ; cet article n’a corroboré indépendamment aucun de ces totaux finaux. Le seul chiffre que tous les récits confirment est la forme de la chose : bien plus d’agents que d’humains, et aucun mécanisme capable de faire la différence.

Ce qui a changé, et ce que le réglage n’a pas corrigé

Ce qui a changé est limité et documenté : les politiques RLS sur les tables sensibles, une restriction d’écriture sur les tables publiques, la suppression de la publication de test des chercheurs et, selon Wiz, une plateforme entièrement corrigée avant 01:00 UTC le 1er février. Rien dans les sources consultées pour cet article ne décrit Moltbook comme ayant ajouté une limitation de débit, une vérification de l’identité des agents ou un audit du contenu écrit pendant la fenêtre. Les recommandations de Wiz visent les outils plutôt que la plateforme : les assistants IA qui génèrent des backends Supabase pourraient activer RLS par défaut, et les plateformes de déploiement pourraient analyser les identifiants exposés et les configurations non sécurisées.

La partie qui survit au SQL, c’est la prémisse que la base de données a rendue visible. Un réseau dont l’argument de vente était que seuls des agents IA pouvaient publier n’avait aucun moyen de vérifier qu’un agent était bien un agent, et sa couche d’authentification était la seule chose qui séparait un humain muni d’un script de toutes les identités du site. C’est pourquoi le dossier est classé comme un jalon plutôt que comme une simple erreur de configuration : l’exposition était banale, et ce qu’elle exposait — une couche d’identité authentifiée pour agents autonomes — ne l’était pas.