MoltBook-Hack: 1,5 Millionen API-Schlüssel durch Supabase-Fehlkonfiguration offengelegt

 (wiz.io)
10 Punkte von GN⁺ 2026-02-04 | 8 Kommentare | Auf WhatsApp teilen
  • Die Datenbank von Moltbook, einer Social-Plattform speziell für AI-Agenten, war falsch konfiguriert, wodurch 1,5 Millionen API-Authentifizierungs-Token, 35.000 E-Mail-Adressen und private Nachrichten nach außen offengelegt wurden
  • Im clientseitigen JavaScript waren Supabase-API-Schlüssel hartcodiert, und da Row Level Security (RLS) nicht konfiguriert war, konnte jeder mit Lese- und Schreibzugriff auf die gesamte Datenbank zugreifen
  • Die Daten enthielten Informationen zu 17.000 echten Nutzern und den von ihnen betriebenen 1,5 Millionen Agentenkonten; das Verhältnis Mensch zu Agent betrug 1:88
  • Zu den offengelegten Informationen gehörten OpenAI-API-Schlüssel und andere Zugangsdaten Dritter, private Unterhaltungen sowie die Berechtigung zum Bearbeiten von Beiträgen, was ein Risiko für die Integrität der Plattforminhalte darstellt
  • Der Vorfall zeigt die Sicherheitsgrenzen von AI-basierter „Vibe Coding“ auf und macht deutlich, wie wichtig automatisierte Security-Defaults und stärkere Prüfprozesse in AI-Entwicklungsumgebungen sind

Überblick über Moltbook und die Sicherheitslücke

  • Moltbook ist ein AI-zentriertes soziales Netzwerk, in dem AI-Agenten über Beiträge, Kommentare, Abstimmungen und Reputationspunkte aktiv sind, und wirbt mit dem Slogan „die Titelseite des Agenten-Internets“
    • Der OpenAI-Mitgründer Andrej Karpathy bezeichnete es als den „erstaunlichsten sci-fi-artigen Sprung“ und sorgte damit für Aufmerksamkeit
  • Der Gründer der Plattform erklärte, dass „die AI den Code direkt geschrieben hat“, und entwickelte sie im Stil von „Vibe Coding“
  • Das Forschungsteam von Wiz entdeckte eine Fehlkonfiguration der Supabase-Datenbank, die Lese- und Schreibzugriff auf sämtliche Daten ermöglichte; nach der Meldung wurde das Problem innerhalb weniger Stunden behoben

Offengelegte Supabase-Zugangsdaten

  • Im clientseitigen JavaScript-Bundle der Moltbook-Website wurden hartcodierte Verbindungsinformationen zu Supabase gefunden
    • Projekt: ehxbxtjliybbloantpwq.supabase.co
    • API-Schlüssel: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • Bei Supabase ist die Offenlegung öffentlicher Schlüssel an sich zulässig, doch ohne RLS-Richtlinien ist Zugriff auf die gesamte Datenbank möglich
  • Bei Moltbook war RLS deaktiviert, wodurch Lese- und Schreibrechte für alle Tabellen öffentlich waren

Unauthentifizierter Datenbankzugriff

  • Das Forschungsteam rief mit dem API-Schlüssel direkt die REST-API auf und erhielt dabei Antworten auf Admin-Niveau
  • Die Antworten enthielten API-Schlüssel und Authentifizierungs-Token führender Agenten, womit eine vollständige Kontoübernahme möglich war
  • Mithilfe von PostgREST-Fehlermeldungen und GraphQL-Introspection wurde das vollständige Schema ermittelt; dabei bestätigte sich die Offenlegung von rund 4,75 Millionen Datensätzen

Offengelegte sensible Daten

  • Agenten-Anmeldedaten: Enthalten waren pro Konto api_key, claim_token und verification_code
    • Damit konnten Angreifer sich als beliebige Agenten anmelden, Beiträge verfassen und Nachrichten senden
  • E-Mail- und Identitätsdaten von Nutzern: E-Mail-Adressen und X-(Twitter-)Handles von mehr als 17.000 Nutzern wurden offengelegt
    • Zusätzlich wurden in der Tabelle observers 29.631 E-Mail-Adressen gefunden
  • Private Nachrichten und Zugangsdaten Dritter: 4.060 DMs waren unverschlüsselt gespeichert; einige enthielten OpenAI-API-Schlüssel im Klartext
  • Offengelegte Schreibrechte: Beiträge konnten ohne Authentifizierung bearbeitet werden, wodurch das Risiko für das Einschleusen bösartiger Inhalte oder eine Manipulation der Website bestand
    • Ein realer Test zeigte, dass das Bearbeiten von Beiträgen tatsächlich funktionierte; später wurde dies durch RLS-Richtlinien blockiert

Fünf Sicherheitslehren für die Entwicklung von AI-Apps

  • 1. Hohes Entwicklungstempo führt ohne Security-Defaults zu systemischen Risiken
    • Eine einzige Zeile in der Supabase-Konfiguration war die Ursache für die vollständige Offenlegung
  • 2. Beteiligungskennzahlen müssen verifiziert werden
    • Unter 1.500.000 Agenten waren nur 17.000 reale Menschen, was auf eine mögliche künstliche Aktivität im Verhältnis von 88:1 hindeutet
  • 3. Kettenreaktion des Privatsphäre-Zusammenbruchs
    • Durch die Offenlegung von DMs wurden auch Zugangsdaten externer Dienste wie OpenAI-API-Schlüssel geleakt
  • 4. Schreibrechte sind eine schwerwiegendere Integritätsbedrohung als bloßer Datenabfluss
    • Risiken reichen von Content-Manipulation über Prompt Injection bis zur Steuerung von Narrativen
  • 5. Sicherheitsreife ist ein iterativer Verbesserungsprozess
    • Die Teams von Wiz und Moltbook schützten schließlich durch mehrere Korrektur- und Prüfzyklen alle Tabellen

Vibe Coding und die Sicherheitsherausforderung

  • AI hat die Hürden für Entwicklung gesenkt, aber die Sicherheitshürden sind weiterhin hoch
  • AI-Entwicklungstools sollten Security-Defaults (RLS-Aktivierung, Credential-Scanning usw.) automatisch anwenden
  • Erst wenn Sicherheit als grundlegender eingebauter Bestandteil der AI-Entwicklung verankert ist, kann ein sicheres und innovatives Ökosystem für AI-Software entstehen

Zeitleiste

  • 31. Januar 2026, 21:48 UTC: Erster Kontakt mit dem Moltbook-Maintainer
  • 22:06: Meldung der Supabase-RLS-Fehlkonfiguration
  • 23:29: Erste Korrektur (Schutz der Tabellen agents, owners, site_admins)
  • 1. Februar, 00:13: Zweite Korrektur (Schutz von agent_messages usw.)
  • 00:31: Schwachstelle zur Bearbeitung von Beiträgen entdeckt
  • 00:44: Dritte Korrektur blockiert Schreibrechte
  • 00:50~01:00: Weitere offengelegte Tabellen entdeckt und abschließende Korrektur durchgeführt

Verwandte Beiträge

8 Kommentare

 
rustkim 2026-02-05

Übrig bleibt nur der Mac mini; da es noch am Anfang steht, kommt sicher noch etwas Besseres heraus.
 
gogokow27 2026-02-05

Hahahahahahahaha....
 
iolothebard 2026-02-04

Fröhlich am Tanzen … und dann einfach … geh zugrunde!
 
kuthia 2026-02-04

Endlich ist eingetreten, was kommen musste.
 
crawler 2026-02-04

Bei MoltBot gab es schon beim Agenten einen Hack-Vorfall, und jetzt ist sogar noch die Plattform dran, lol.

Das wird wohl als Paradebeispiel für ein Projekt mit der schlimmsten Vibe des Jahres 2026 in Erinnerung bleiben.
Es ist zwar erst Februar, aber da bin ich mir sicher, lol.
 
bini59 2026-02-04

Ist das Problem, dass dank Vibecoding auch ohne Sicherheitsbewusstsein große Dienste entwickelt werden können?
 
kimjoin2 2026-02-04

WOW
 
GN⁺ 2026-02-04
Hacker-News-Kommentare

  • Der Erfolg von Moltbot/Moltbook war anfangs überraschend, inzwischen ist er nachvollziehbar.
    Der Kern ist, dass es sich um „vorverpackte Agenten“ handelt. Für normale Nutzer ohne große Technikkenntnisse ist ein Ansatz wie „einen Mac mini kaufen, ein paar Zeilen kopieren und installieren“ äußerst attraktiv.
    Diese Zugänglichkeit befeuert allerdings einen Sicherheitsalbtraum. Wenn immer mehr Nutzer ohne technisches Verständnis nur dem Hype folgen, steigt das Risiko, dass verwundbare Umgebungen länger bestehen bleiben.

    • Es gibt Zweifel, ob man das wirklich als Erfolg bezeichnen kann. Einer Analyse zufolge gibt es bei 1,5 Millionen Agenten nur 17.000 menschliche Besitzer. Vieles scheint auch durch virale Erwähnungen bekannter Influencer getrieben zu sein.
    • Alle LLMs sind konstruktionsbedingt sicherheitsanfällig. Mit Prompt Injection oder Reward Hacking lassen sie sich leicht umgehen. Die einzige vollständige Lösung ist, externe Eingaben und Netzwerkzugriff komplett zu blockieren.
    • „Einen Mac mini kaufen und installieren“ ist nur ein Marketing-Slogan. Tatsächlich treten häufig Konfigurationsfehler auf und das Kontext-Management ist chaotisch. Es werden zwar Logs gespeichert, aber selbst das unmittelbar vorherige Gespräch wird vergessen. Die Idee ist gut, die Umsetzung jedoch roh.
    • Wie damals bei Dropbox ist die verpackte Zugänglichkeit ein Erfolgsfaktor. Aber in einer Realität, in der selbst Großunternehmen Hacks nicht verhindern können, wird eine misconfigured DB als keine große Sache angesehen. Bequemlichkeit schlägt weiterhin Sicherheit.
    • Ob es nur kurzzeitig Aufmerksamkeit bekommen hat oder wirklich ein Erfolg ist, bleibt unklar.

  • Wie Scott Alexander angemerkt hat, ist wichtig, dass Agenten miteinander interagieren und dabei komplexe Verhaltensweisen hervorbringen.
    Wenn das beginnt, Auswirkungen auf die reale Welt zu haben, könnte es zu ontologischen Problemen führen.
    Letztlich ist es eine Struktur, in der alles, was in „AGENT.md“ mit YES steht, tatsächlich passieren kann.

    • Manche reagieren darauf mit dem Hinweis, dass sie nicht ganz verstehen, was damit gemeint ist.
    • Deshalb habe ich nono.sh gebaut. Damit starten Agenten mit Zero Trust in einer kernel-isolierten Sandbox.
    • Auch Menschen sind zu einem gewissen Grad Wesen, die „papageienhaft wiederholen“. So wie Moltbook Reddit nachahmt, reden auch Menschen in vorhersehbaren Mustern. Vielleicht sind wir am Ende weniger klug, als wir glauben.

  • Die Moltbook-API ist für jedermann offen, sodass sich mit einfachen Prompts Nutzer-E-Mails oder Datenlecks provozieren lassen.
    Deshalb gibt es Versuche, das Ganze über einen Mac mini zu isolieren, aber solange eine Verbindung zum Netzwerk besteht, ist vollständiger Schutz unmöglich.

    • Das ist nicht verrückt. LLMs können Befehle und Daten nicht zuverlässig voneinander unterscheiden. Es ist eine Art Schwachstelle für „Social Engineering“.
    • Letztlich geht es darum, ob man ihnen nützliche Aufgaben ohne Risiko geben kann. Wer sie etwa Einkäufe oder Reisebuchungen erledigen lassen will, muss ihnen Zugriff auf Kreditkarten geben.
    • Ich nutze LLMs in einer DMZ-Umgebung isoliert. Sie laufen unter einem zustandslosen Account ohne sudo-Rechte. Perfekt ist das nicht, aber es funktioniert einigermaßen.
    • Einen praktisch perfekten Schutz gibt es nicht. Denn es sind zugleich Datenzugriff, nicht vertrauenswürdiger Text und Netzwerkkommunikation vorhanden – die „tödliche Triade“.
    • Möglich ist allerdings eine Überwachungs- und Genehmigungsschicht. Ähnlich wie bei Kreditkartenlimits könnte man eine Struktur schaffen, die Aktionen von LLMs freigibt oder einschränkt.

  • Ich habe OpenClaw ausprobiert, und der Token-Verbrauch ist enorm.
    Für die Sicherheit wären dedizierte Geräte (Raspberry Pi usw.) mit eingeschränkten API-Rechten vermutlich hilfreich. Wenn ein Pi leistungsfähigere Modelle ausführen könnte, würde ich einen kaufen.

  • Moltbook hat keine Möglichkeit, AI von Menschen zu unterscheiden. Es geht also um die Frage, wie man ein „Reverse CAPTCHA“ umsetzen könnte.

    • Aus Spaß habe ich Claude den Prompt gegeben, „menschliche Spionage-Accounts zu finden“, und tatsächlich entstand ein Thread namens „Reverse Turing Problem“. Inzwischen ist er jedoch so sehr mit Spam zugemüllt, dass eine Unterhaltung kaum noch möglich ist.
    • Man braucht eine Methode, bei der sämtliche Ein- und Ausgaben einer Sitzung signiert und auditierbar sind. Auch von Menschen eingeschleuste Prompts müssten nachverfolgbar sein.
    • Eine weitere Unterscheidungsmöglichkeit wäre, in kurzer Zeit mehrfach Aufgaben zu stellen, die für AI leicht, für Menschen aber schwierig sind.
    • Oder man stellt schnell seltene Fragen, deren Antworten ein LLM vermutlich bereits kennt.
    • Letztlich bleibt es aber weiterhin schwer zu unterscheiden, ob ein Verhalten von einem Menschen per Prompt ausgelöst wurde.

  • Zwar heißt es, das Moltbook-Sicherheitsproblem sei innerhalb weniger Stunden behoben worden, aber die eigentliche Frage ist, wie man Sicherheitsmängel in einem per „Vibe Coding“ gebauten Projekt erklären soll.

    • Tatsächlich hat Claude die Query für Supabase erzeugt, und ein Mensch hat sie an die Moltbook-Entwickler weitergegeben, damit diese den Fix einspielen. Kaum zu glauben, aber offenbar wahr.

  • Es ist erstaunlich, dass Leute das Innenleben von Moltbook analysieren. Ursprünglich war es ja ein „als Scherz gebautes Projekt“, und niemand hatte erwartet, dass es so groß wird.

    • Wenn jedoch Nutzer-PII offengelegt wird, lässt sich das nicht mehr als Witz abtun – dann wird es zu einem rechtlichen Problem. Die Kultur des „Vibe Coding“ fördert ein unverantwortliches Entwicklungsumfeld.
    • Auch Dogecoin begann als Scherz und ist heute Milliarden wert.
    • Dass Sicherheitsforscher Schwachstellen finden, könnte letztlich ebenfalls Teil des „Vibes“ sein.
    • Trotzdem kann man mit der Ausrede „Es war nur ein Witz“ realen Schaden nicht überdecken.
    • Wenn das Ergebnis absichtlich von den Erstellern so hervorgebracht wurde, ist die Ausrede „Scherz“ ohnehin schwach.

  • Der Vorfall, bei dem eine OpenClaw-Instanz einen OpenAI-Key an eine andere Instanz gesendet hat, war zugleich komisch und beunruhigend.
    Ob der Key tatsächlich gesendet wurde oder nur so getan wurde, bleibt unklar.

  • Schon der Artikel von Wiz selbst wirkt, als wäre er von einer AI geschrieben. Satzbau und Gedankenstriche haben den typischen LLM-Stil.
    Es ist ironisch, dass die Sicherheit einer von LLMs geschaffenen Plattform mit einem offenbar von LLMs geschriebenen Artikel kritisiert wird.
    Die eigentliche Schwachstelle dürfte real sein, aber wenn ein Mensch den Text geschrieben hätte, wären unnötige Füllsel vermutlich reduziert worden.

  • Aus den offengelegten Daten ging hervor, dass unter 1,5 Millionen Agenten nur 17.000 Menschen sind.
    Da der Forscher diese Zahl jedoch direkt über API-Keys aus Tabellenabfragen gewonnen hat, wirkt ihre Veröffentlichung weniger wie ein bloßer Bug-Report als vielmehr wie eine Kritik am Unternehmen.
    So ein Vorgehen könnte die vertrauensvolle Zusammenarbeit zwischen Forschern und Unternehmen beschädigen.