Moltbook-Datenbank vollständig offen: 1,5 Millionen Agent-API-Schlüssel, 35.000 E-Mails

Moltbook ist ein soziales Netzwerk im Reddit-Stil, das so gebaut wurde, dass nur KI-Agenten posten können. Sein Gründer Matt Schlicht startete es am 28. Januar 2026 und sagte öffentlich auf X, er habe keine einzige Zeile seines Codes geschrieben: „Ich hatte nur eine Vision für die technische Architektur, und die KI hat sie Wirklichkeit werden lassen“, wie Wiz ihn zitiert. Drei Tage später, am 31. Januar 2026, berichtete 404 Media, dass jeder die Kontrolle über jeden KI-Agenten auf der Website übernehmen könne. Wiz, das dieselbe Fehlkonfiguration unabhängig gefunden hatte, veröffentlichte am 2. Februar den technischen Bericht: Ein fest in das clientseitige JavaScript von Moltbook einprogrammierter Supabase-API-Schlüssel verwies auf eine Produktionsdatenbank ohne Row Level Security, und eine nicht authentifizierte Anfrage an die Tabelle agents gab Live-Authentifizierungstoken für die Agenten der Plattform zurück, einschließlich ihrer bekanntesten. Wiz zählte 1,5 Millionen API-Token, 35.000 E-Mail-Adressen und 4.060 private Agent-zu-Agent-Unterhaltungen, die auf diese Weise lesbar waren, und bestätigte, dass es auch Live-Beiträge umschreiben konnte. Das Archiv ordnet den Vorfall als Credential-Vorfall mit kritischem Schweregrad ein, mit einem Datum mit Tagesgenauigkeit vom 31. Januar 2026, einer Konfidenznote A und dokumentiertem realen Schaden, zusammen mit den übrigen Aufzeichnungen seiner Agenten-Infrastruktur im Orca AI Incident Archive.

Der Schlüssel war nie das Geheimnis

Supabase ist ein gehosteter Postgres-Dienst mit einer REST-API, die Wiz als beliebt bei vibe-codierten Anwendungen beschreibt, weil er einfach einzurichten ist. Sein Publishable Key ist dafür gedacht, im clientseitigen Code zu stehen: Er identifiziert das Projekt, und die Zugriffskontrolle soll über Row-Level-Security-Richtlinien auf den dahinterliegenden Tabellen erfolgen. Gal Nagli von Wiz stellt den Punkt im Write-up ausdrücklich klar: Die Offenlegung des Schlüssels „bedeutet nicht automatisch ein Sicherheitsversagen“, und wenn RLS korrekt konfiguriert ist, „ist der öffentliche API-Schlüssel sicher offenzulegen – er wirkt wie eine Projektkennung.“ In Moltbooks Implementierung, schreibt Wiz, „fehlte diese entscheidende Verteidigungslinie.“

Der Mechanismus war ein Bundle. Laut Wiz enthielt die Produktions-JavaScript-Datei unter moltbook.com/_next/static/chunks/18e24eafc444b2b9.js sowohl die Supabase-Projektadresse ehxbxtjliybbloantpwq.supabase.co als auch den Schlüssel sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz sandte dann eine Anfrage an die Tabelle agents, in der drei Namen und API-Schlüssel angefordert wurden – eine Abfrage, die ein leeres Array oder einen Autorisierungsfehler hätte zurückgeben müssen. Stattdessen wurden Zeilen zurückgegeben, darunter die Authentifizierungstoken der beliebtesten Agenten der Plattform. Von dort aus kartierte Wiz das Schema mithilfe von PostgREST-Fehlermeldungen und GraphQL-Introspektion und zählte rund 4,75 Millionen offengelegte Datensätze.

Die Zusammenfassung des Archivs besagt, Moltbook habe Row Level Security „nie aktiviert“, und die Quellen sind unschärfer als das. Keine von beiden zeigt eine Konfigurationshistorie, daher ist dokumentiert, dass RLS während der Prüfung nicht in Kraft war: Wiz fand die Tabellen offen vor, und Implicator.ai schreibt unter Berufung auf die Darstellung des Finders, Moltbook habe „RLS nie eingeschaltet. Oder wenn doch, waren keine Policies konfiguriert.“ Ob die Einstellung nie aktiviert oder aktiviert wurde, ohne dass Policies vorhanden waren, ist durch keine der beiden Darstellungen belegt, und das praktische Ergebnis ist dasselbe.

Was war tatsächlich in den Tabellen?

Wiz benennt die Tabellen und ihre Inhalte. Die Tabelle agents enthielt pro Zeile den api_key, der den Agenten authentifizierte, ein claim_token, mit dem der Besitz an ihm beansprucht werden konnte, einen bei der Registrierung ausgegebenen verification_code sowie die Karma- und Follower-Zahlen des Agenten. Das ist eher ein komplettes Konto-Übernahme-Kit als ein Datenleck: Mit einem dieser Schlüssel kann eine Anfrage posten, Nachrichten senden und sich anderweitig als dieser Agent verhalten, und Wiz merkt an, dass dies Konten mit hohem Karma und bekannte Persona-Agenten einschloss.

Die Tabelle owners enthielt personenbezogene Daten von mehr als 17.000 Nutzern, darunter E-Mail-Adressen sowie den X-Handle und den Anzeigenamen hinter jedem Agenten. Eine Tabelle, die Wiz später über den GraphQL-Endpunkt fand – observers –, enthielt 29.631 weitere E-Mail-Adressen von Early-Access-Anmeldungen für Moltbooks geplantes Produkt „Build Apps for AI Agents“. Die Tabelle agent_messages enthielt 4.060 private Direktnachrichten-Unterhaltungen zwischen Agenten, gespeichert ohne Verschlüsselung oder Zugriffskontrollen, und Wiz berichtet, dass einige davon Zugangsdaten Dritter im Klartext enthielten, darunter OpenAI-API-Schlüssel, die Agenten miteinander geteilt hatten.

Das Verhältnis zwischen Agenten und Menschen ist der Punkt, der die öffentliche Darstellung der Plattform untergrub. Wiz berichtet von 1,5 Millionen registrierten Agenten gegenüber rund 17.000 menschlichen Eigentümern, etwa 88 Agenten pro Person, und führt die Diskrepanz auf das Fehlen von Ratenbegrenzung oder Identitätsprüfung zurück: Jeder konnte Agenten in einer Schleife registrieren, und ein Mensch konnte sich mit einer einfachen POST-Anfrage als „Agent“ ausgeben. Wiz' Fazit ist unverblümt – „das revolutionäre soziale KI-Netzwerk bestand weitgehend aus Menschen, die Bot-Flotten betrieben.“

Die E-Mail-Anzahl geht nicht sauber auf, und Wiz erklärt nicht, warum. Die Schlagzeile nennt 35.000 E-Mail-Adressen; die eigenen Zählungen auf Tabellenebene ergeben über 17.000 Eigentümer-E-Mails und 29.631 Beobachter-E-Mails, was zusammen etwa 46.600 ergibt. Beide Zahlen stammen von Wiz, und dieser Artikel hat nicht geklärt, wie die 35.000 zustande kamen – ob durch Deduplizierung über die beiden Tabellen hinweg oder aus einem Snapshot, der erstellt wurde, bevor die Beobachtertabelle gefunden wurde.

Die Schreibhälfte der Exposition

Das Lesen der Daten war nicht der gesamte Befund. Wiz berichtet, dass selbst nach der ersten Runde von Korrekturen, die den Lesezugriff auf die sensiblen Tabellen blockierten, der Schreibzugriff auf die öffentlichen Tabellen weiterhin offen blieb. Es testete dies, indem es eine PATCH-Anfrage an einen Live-Beitrag sendete und dessen Titel und Text durch die Zeichenfolge „@galnagli - responsible disclosure test“ ersetzte und dann bestätigte, dass die Änderung auf der Website sichtbar war. Nachdem die Schreibbeschränkung eingeführt worden war, konnte Wiz seinen eigenen Testbeitrag nicht mehr zurücksetzen; das Moltbook-Team löschte den Inhalt einige Stunden später, schreibt Wiz, und dankte den Forschern für den Bericht.

Wiz’ erklärte Sorge gilt nicht der Verunstaltung um ihrer selbst willen. Ein unauthentifizierter Schreibpfad in Posts bedeutet, dass jeder Prompt-Injection-Payloads in Inhalte einschleusen könnte, die andere Agenten lesen, und Wiz wirft die Integrität der Posts, Votes und Karma der Plattform während des Expositionszeitraums als offene Frage auf, nicht als gemessene. Keine für diesen Beitrag gelesene Quelle quantifiziert, wie viele Inhalte verändert wurden oder von wem.

Drei Stunden und zwölf Minuten, vier separate Korrekturen

Wiz' Offenlegungs-Zeitachse beginnt am 31. Januar 2026 um 21:48 UTC mit einer ersten Kontaktaufnahme zum Moltbook-Maintainer per X-Direktnachricht und endet am 1. Februar um 01:00 UTC, als die letzte der offengelegten Tabellen gesichert wurde. Nach diesem ersten Kontakt verzeichnet sie sieben weitere Schritte: die Meldung um 22:06, einen ersten Fix um 23:29, der die Tabellen agents, owners und site_admins abdeckt, einen zweiten um 00:13, der agent_messages, notifications, votes und follows abdeckt, die Entdeckung des Schreibpfads um 00:31, den dritten Fix, der ihn um 00:44 schließt, die Entdeckung der Tabellen observers, identity_verifications und developer_apps um 00:50 und den letzten Fix um 01:00.

Diese Zeitlinie ist das stärkste Argument gegen die einfachste Version dieser Geschichte. Implicator.ai beschreibt die Behebung in zwei SQL-Anweisungen – es schreibt, dass „die Behebung zwei SQL-Anweisungen erforderte. Sie existierten nicht“, und die Zusammenfassung des Archivs verwendet dieselbe Formulierung von „zwei Zeilen SQL“. Die Kernreparatur für die Leseexposition war wahrscheinlich so klein: RLS aktivieren und Richtlinien für die Tabellen hinzufügen. Doch Wiz’ eigene Aufzeichnung zeigt vier Behebungen über drei Stunden, eine zweite und separate Schreibzugriffslücke, die die Lese-Behebung nicht schloss, und drei weitere Tabellen – einschließlich der 29,631 Observer-Adressen –, die erst nach den ersten beiden Runden auftauchten. Die abschließende Lehre von Wiz ist, dass es „mit dem Team mehrere Runden der Behebung durchlief, wobei jede Iteration zusätzliche exponierte Oberflächen hervorbrachte“. Die Zwei-Zeilen-Version beschreibt die Konfigurationsänderung, nicht die Behebung.

Zwei Entdeckungen und ein Unterschied in der Aktenlage

Die Entdeckung wird üblicherweise Jamieson O'Reilly zugeschrieben, der die australische Sicherheitsfirma Dvuln gründete und die Übernahme gegenüber 404 Media demonstrierte; Implicator.ai berichtet, dass 404 Media die Fähigkeit verifizierte, indem mit seiner Erlaubnis O'Reillys eigenes Moltbook-Konto aktualisiert wurde. Wizs Beitrag stammt von Gal Nagli und enthält am Ende einen Hinweis, der O'Reilly nennt: „Der Sicherheitsforscher Jameson O'Reilly entdeckte außerdem die zugrunde liegende Supabase-Fehlkonfiguration, über die 404 Media berichtet hat.“ Der Hinweis fährt fort, dass Wizs Beitrag eine unabhängige Entdeckung desselben Problems darstelle.

Die Zusammenfassung des Archivs beschreibt beide als Wiz-Forscher. Der eigene Beitrag von Wiz tut das nicht: Er nennt Nagli als Autor und beschreibt O'Reilly als unabhängigen Forscher, über dessen Fund 404 Media berichtete, und Implicator.ai ordnet O'Reilly Dvuln zu. Auch die Schreibweise ist in den Quellen uneinheitlich – Wiz schreibt „Jameson“, während die eigene Website von Dvuln ihren Gründer als „Jamieson“ führt – und dieser Artikel hat die Schreibweise verwendet, die diese Website nutzt. Unbestritten ist, dass es innerhalb weniger Tage zwei unabhängige Entdeckungen derselben Fehlkonfiguration gab.

Die Darstellung der Reaktion unterscheidet sich je nach Quelle, und der Unterschied ist es wert, berichtet statt aufgelöst zu werden. Nach O'Reillys Darstellung, die von Implicator.ai weitergegeben wurde, wandte er sich direkt an Schlicht und bot an, bei der Behebung der Schwachstelle zu helfen; die Antwort lautete: „Ich werde einfach alles der KI geben. Also schick mir, was du hast.“ Dieser Darstellung zufolge verging dann ein ganzer Tag ohne Rückmeldung, und Schlicht antwortete nicht auf die Anfrage von 404 Media nach einer Stellungnahme. Wiz, das den Maintainer separat kontaktierte, hält fest, dass seine Meldung um 22:06 UTC eingereicht wurde und die letzte von vier Behebungen um 01:00 UTC erfolgte, drei Stunden und zwölf Minuten nach dem ersten Kontakt. Die beiden Zeitlinien laufen über unterschiedliche Kanäle, und keine der Quellen sagt, ob die eine die andere ausgelöst hat; beide können zutreffend sein.

Was die Aktenlage belegt – und was nicht

Die gesicherten Fakten sind die Konfiguration, die Datenklassen, die zwei unabhängigen Entdeckungen, die Abfolge der Behebungen und das Verhältnis von Menschen zu Agenten auf der Plattform. Alles in dieser Liste stammt aus Wiz’ technischer Darstellung aus erster Hand oder aus Berichten, die auf der Schilderung des Finders basieren, und beide stimmen beim Mechanismus überein.

Was nicht geklärt ist, beginnt mit dem vorherigen Zugriff. Wiz erklärt, dass alle Daten, auf die während seiner Recherche und Überprüfung der Behebung zugegriffen wurde, gelöscht wurden, und das sagt nichts über alle anderen aus. Implicator.ai benennt die Lücke klar: Niemand kann sagen, ob jemand die Datenbank vor O'Reilly gefunden hat oder wie viele der Beiträge, die während der viralen Woche der Plattform kursierten, echte Agenten-Ausgabe waren und wie viele von einem gestohlenen Schlüssel stammten. Keine für diesen Artikel gelesene Quelle berichtet über einen bestätigten Missbrauch irgendeiner offengelegten Zugangsdaten, und keine berichtet über eine Zahl tatsächlich übernommener Konten. Das real_harm-Flag des Archivs ist true, weil personenbezogene Daten und aktive Drittanbieter-Zugangsdaten für jeden tatsächlich lesbar waren, nicht weil ein konkreter Missbrauch erfasst wurde.

Die Zahlen der Agenten weichen ebenfalls voneinander ab, und die Abweichung folgt dem Wachstum der Plattform statt den Fakten der Offenlegung. Implicator.ai beschreibt in einem am 1. Februar aus Sicht des Finders verfassten Beitrag „über 32.000“ registrierte Agenten – in einem Artikel, der auch sagt, die Seite habe in ihrer ersten Woche 37.000 überschritten – und 1,49 Millionen offengelegte Datensätze. Wiz zählte bei einer Prüfung am 2. Februar 1,5 Millionen Agenten und rund 4,75 Millionen Datensätze. Die Zusammenfassung des Archivs verzeichnet, dass die Plattform schließlich 1,7 Millionen registrierte Agenten und fast 7 Millionen Kommentare ansammelte; dieser Artikel hat keine der beiden Endsummen unabhängig bestätigt. Die einzige Zahl, die alle Darstellungen stützen, ist die Form des Ganzen: weit mehr Agenten als Menschen und kein Mechanismus, der den Unterschied erkennen könnte.

Was sich geändert hat und was die Einstellung nicht behoben hat

Was sich geändert hat, ist eng begrenzt und dokumentiert: RLS-Richtlinien für die sensiblen Tabellen, eine Schreibbeschränkung für die öffentlichen Tabellen, die Löschung des Testbeitrags der Forscher und – laut Wiz – eine Plattform, die bis 01:00 UTC am 1. Februar vollständig gepatcht war. Nichts in den für diesen Artikel gelesenen Quellen beschreibt, dass Moltbook eine Ratenbegrenzung, eine Verifizierung der Agentenidentität oder eine Prüfung der während des Zeitfensters geschriebenen Inhalte hinzugefügt hat. Wiz' Empfehlungen richten sich eher an die Werkzeuge als an die Plattform – KI-Assistenten, die Supabase-Backends generieren, könnten RLS standardmäßig aktivieren, und Deployment-Plattformen könnten nach offengelegten Zugangsdaten und unsicheren Konfigurationen scannen.

Der Teil, der das SQL überdauert, ist die Prämisse, die die Datenbank sichtbar gemacht hat. Ein Netzwerk, dessen Verkaufsargument darin bestand, dass nur KI-Agenten Beiträge veröffentlichen konnten, hatte keine Möglichkeit zu überprüfen, ob ein Agent tatsächlich ein Agent war, und seine Credential-Schicht war das Einzige, was zwischen einem Menschen mit einem Skript und jeder Identität auf der Website stand. Deshalb wird der Vorfall als Meilenstein und nicht als routinemäßige Fehlkonfiguration geführt: Die Offenlegung war gewöhnlich, doch das, was sie offenlegte – eine authentifizierte Identitätsschicht für autonome Agenten –, war es nicht.