Moltbook-databasen helt öppen: 1,5 miljoner agent-API-nycklar, 35 000 e-postadresser

Moltbook är ett socialt nätverk i Reddit-stil byggt så att endast AI-agenter kan publicera. Dess grundare, Matt Schlicht, lanserade det den 28 januari 2026 och sade offentligt på X att han inte hade skrivit en enda rad av dess kod: "Jag hade bara en vision för den tekniska arkitekturen, och AI förverkligade den", som Wiz citerar honom. Tre dagar senare, den 31 januari 2026, rapporterade 404 Media att vem som helst kunde ta kontroll över vilken AI-agent som helst på webbplatsen. Wiz, som oberoende hade hittat samma felkonfiguration, publicerade den tekniska redogörelsen den 2 februari: en Supabase API-nyckel hårdkodad i Moltbooks klientside-JavaScript pekade på en produktionsdatabas utan Row Level Security, och en oautentiserad begäran till agenttabellen returnerade aktiva autentiseringstoken för plattformens agenter, inklusive de mest kända av dem. Wiz räknade 1,5 miljoner API-token, 35 000 e-postadresser och 4 060 privata agent-till-agent-konversationer som gick att läsa på det sättet, och bekräftade att det också kunde skriva om liveinlägg. Arkivet registrerar händelsen som en autentiseringsincident med kritisk allvarlighetsgrad med dagsprecision den 31 januari 2026, en tillförlitlighetsgrad på A och dokumenterad verklig skada, tillsammans med resten av sina register över agentinfrastruktur i Orca AI Incident Archive.

Nyckeln var aldrig hemligheten

Supabase är en hostad Postgres-tjänst med ett REST-API som Wiz beskriver som populär bland vibe-kodade applikationer eftersom den är enkel att sätta upp. Dess publicerbara nyckel är utformad för att ligga i klientkod: den identifierar projektet, och åtkomstkontrollen ska komma från Row Level Security-principer på tabellerna bakom den. Wizs Gal Nagli säger detta uttryckligen i rapporten: att exponera nyckeln "indikerar inte automatiskt ett säkerhetsfel", och när RLS är korrekt konfigurerat "är den publika API-nyckeln säker att exponera – den fungerar som en projektidentifierare". I Moltbooks implementation, skriver Wiz, "saknades denna kritiska försvarslinje".

Mekanismen var ett paket. Enligt Wiz innehöll produktions-JavaScript-filen på moltbook.com/_next/static/chunks/18e24eafc444b2b9.js både Supabase-projektadressen, ehxbxtjliybbloantpwq.supabase.co, och nyckeln, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz skickade sedan en begäran till agents-tabellen som efterfrågade tre namn och API-nycklar, en fråga som borde ha returnerat en tom array eller ett auktoriseringsfel. Den returnerade i stället rader, inklusive autentiseringstoken för plattformens mest populära agenter. Därifrån kartlade Wiz schemat med hjälp av PostgREST-felmeddelanden och GraphQL-introspektion och räknade ungefär 4,75 miljoner exponerade poster.

Arkivets sammanfattning säger att Moltbook "aldrig aktiverade" Row Level Security, och källorna är lösare än så. Ingen av dem visar en konfigurationshistorik, så det som är dokumenterat är att RLS inte var i kraft under granskningen: Wiz fann att tabellerna var öppna, och Implicator.ai, som återger upptäckarens redogörelse, skriver att Moltbook "aldrig slog på RLS. Eller om de gjorde det, konfigurerades inga policyer." Huruvida inställningen aldrig aktiverades eller aktiverades utan att några policyer fanns på plats fastställs inte av någon av redogörelserna, och det praktiska resultatet är detsamma.

Vad fanns det egentligen i tabellerna

Wiz namnger tabellerna och deras innehåll. Tabellen agents innehöll per rad den api_key som autentiserade agenten, en claim_token som användes för att göra anspråk på ägarskapet av den, en verification_code som utfärdades vid registreringen samt agentens karma- och följarantal. Det är ett komplett paket för kontokapning snarare än en dataläcka: med en av dessa nycklar kan en begäran publicera inlägg, skicka meddelanden och i övrigt agera som den agenten, och Wiz noterar att detta omfattade konton med hög karma och välkända personagentkonton.

Tabellen owners innehöll personuppgifter för över 17 000 användare, inklusive e-postadresser samt X-handtaget och visningsnamnet bakom varje agent. En tabell som Wiz senare hittade via GraphQL-slutpunkten, observers, innehöll ytterligare 29 631 e-postadresser som tillhörde registreringar för tidig åtkomst till Moltbooks planerade produkt "Build Apps for AI Agents". Tabellen agent_messages innehöll 4 060 privata direktmeddelandekonversationer mellan agenter, lagrade utan kryptering eller åtkomstkontroller, och Wiz rapporterar att vissa innehöll tredjepartsuppgifter i klartext, inklusive OpenAI API-nycklar som agenter hade delat med varandra.

Förhållandet mellan agenter och människor är den del som underminerade plattformens offentliga berättelse. Wiz rapporterar 1,5 miljoner registrerade agenter mot ungefär 17 000 mänskliga ägare, cirka 88 agenter per person, och tillskriver gapet avsaknaden av hastighetsbegränsning eller identitetsverifiering: vem som helst kunde registrera agenter i en loop, och en människa kunde publicera som en "agent" med en enkel POST-begäran. Wiz slutsats är rakt på sak – "det revolutionerande AI-sociala nätverket bestod till stor del av människor som drev flottor av botar."

Antalet e-postadresser går inte ihop rent och Wiz förklarar inte varför. Deras rubriksiffra är 35 000 e-postadresser; deras egna antal på tabellnivå är över 17 000 e-postadresser till ägare och 29 631 e-postadresser till observatörer, vilka summerar till ungefär 46 600. Båda siffrorna är Wiz egna, och den här artikeln fastställde inte hur 35 000 togs fram – om det var genom deduplicering mellan de två tabellerna eller från en ögonblicksbild tagen innan observatörstabellen hittades.

Skrivhalvan av exponeringen

Att läsa datan var inte hela upptäckten. Wiz rapporterar att även efter den första omgången åtgärder, som blockerade läsåtkomst till de känsliga tabellerna, förblev skrivåtkomst till de publika tabellerna öppen. Det testade detta genom att skicka en PATCH-förfrågan till ett liveinlägg och ersätta dess titel och brödtext med strängen "@galnagli - responsible disclosure test", och bekräftade sedan att redigeringen var synlig på webbplatsen. Efter att skrivbegränsningen infördes kunde Wiz inte längre återställa sitt eget testinlägg; Moltbook-teamet raderade innehållet några timmar senare, skriver Wiz, och tackade forskarna för rapporten.

Wiz uttalade oro gäller inte skadegörelse för dess egen skull. En oautentiserad skrivväg in i inlägg innebär att vem som helst skulle kunna injicera prompt-injektionsnyttolaster i innehåll som andra agenter läser, och Wiz lyfter integriteten hos plattformens inlägg, röster och karma under exponeringsfönstret som en öppen fråga snarare än en uppmätt sådan. Ingen källa som lästs för den här artikeln kvantifierar hur mycket innehåll som ändrades eller av vem.

Tre timmar och tolv minuter, fyra separata åtgärder

Wizs tidslinje för avslöjandet börjar kl. 21:48 UTC den 31 januari 2026, med en första kontakt med Moltbooks underhållsansvarige via X-direktmeddelande, och slutar kl. 01:00 UTC den 1 februari, då den sista av de exponerade tabellerna säkrades. Efter den första kontakten registrerar den sju ytterligare steg: rapporten kl. 22:06, en första rättning kl. 23:29 som omfattar tabellerna agents, owners och site_admins, en andra kl. 00:13 som omfattar agent_messages, notifications, votes och follows, upptäckten av skrivvägen kl. 00:31, den tredje rättningen som stänger den kl. 00:44, upptäckten av tabellerna observers, identity_verifications och developer_apps kl. 00:50, och den slutliga rättningen kl. 01:00.

Den tidslinjen är det starkaste argumentet mot den enklaste versionen av den här berättelsen. Implicator.ai beskriver åtgärden i två SQL-satser – det skriver att "åtgärden krävde två SQL-satser. De fanns inte," och arkivets sammanfattning har samma "två rader SQL"-inramning. Kärnreparationen för läs-exponeringen var förmodligen så liten: aktivera RLS och lägg till policyer på tabellerna. Men Wiz egna register visar fyra åtgärder under tre timmar, en andra och separat skrivåtkomstlucka som läsåtgärden inte stängde, och ytterligare tre tabeller – inklusive de 29 631 observatörsadresserna – som dök upp först efter de två första omgångarna. Wiz avslutande lärdom är att det "arbetade med teamet genom flera omgångar av åtgärdande, där varje iteration synliggjorde ytterligare exponerade ytor." Tvåradsversionen beskriver konfigurationsändringen, inte åtgärdandet.

Två upptäckter, och en skillnad i dokumentationen

Upptäckten brukar tillskrivas Jamieson O'Reilly, som grundade det australiska säkerhetsföretaget Dvuln och som demonstrerade övertagandet för 404 Media; Implicator.ai rapporterar att 404 Media verifierade förmågan genom att uppdatera O'Reillys eget Moltbook-konto med hans tillstånd. Wizs inlägg är skrivet av Gal Nagli och har en notering i slutet som ger O'Reilly erkännande: "Säkerhetsforskaren Jameson O'Reilly upptäckte också den underliggande Supabase-felkonfigurationen, vilket har rapporterats av 404 Media." Noteringen fortsätter med att säga att Wizs inlägg delar en oberoende upptäckt av samma problem.

Arkivets sammanfattning beskriver båda som Wiz-forskare. Wiz eget inlägg gör det inte: det anger Nagli som författare och beskriver O'Reilly som en oberoende forskare vars fynd 404 Media rapporterade, och Implicator.ai placerar O'Reilly på Dvuln. Stavningen är också osäker mellan källor – Wiz skriver "Jameson", medan Dvulns egen webbplats listar dess grundare som "Jamieson" – och den här artikeln har använt stavningen som den webbplatsen använder. Det som inte är omtvistat är att det fanns två oberoende upptäckter av samma felkonfiguration inom loppet av några dagar.

Redogörelsen för svaret skiljer sig mellan källorna, och skillnaden är värd att rapportera snarare än att lösa. Enligt O'Reillys redogörelse, som vidarebefordrats av Implicator.ai, kontaktade han Schlicht direkt och erbjöd sig att hjälpa till att lappa sårbarheten; svaret var: "Jag tänker bara ge allt till AI. Så skicka mig vad du än har." Enligt den skildringen gick det sedan ett helt dygn utan uppföljning, och Schlicht svarade inte på 404 Medias begäran om en kommentar. Wiz, som kontaktade underhållaren separat, uppger att deras rapport lämnades in kl. 22:06 UTC och att den sista av fyra rättelser gjordes kl. 01:00 UTC, tre timmar och tolv minuter efter den första kontakten. De två tidslinjerna löper i olika kanaler och ingen av källorna säger om den ena föranledde den andra; båda kan vara korrekta.

Vad handlingarna fastställer, och vad de inte fastställer

De fastställda fakta är konfigurationen, dataklasserna, de två oberoende upptäckterna, åtgärdssekvensen och plattformens förhållande mellan människor och agenter. Allt i den listan kommer från Wizs tekniska förstahandsredogörelse eller från rapportering som bygger på upptäckarens redogörelse, och de två stämmer överens om mekanismen.

Det som inte är fastställt börjar med tidigare åtkomst. Wiz uppger att all data som lästes under deras research och verifiering av åtgärden har raderats, och det säger ingenting om någon annan. Implicator.ai beskriver luckan rakt på sak: ingen kan avgöra om någon hittade databasen före O'Reilly, eller hur många av inläggen som cirkulerade under plattformens virala vecka som var äkta agentutdata och hur många som kom från en stulen nyckel. Ingen källa som lästs för den här artikeln rapporterar ett bekräftat missbruk av någon exponerad autentiseringsuppgift, och ingen rapporterar en siffra på konton som faktiskt har övertagits. Arkivets real_harm-flagga är sann eftersom personuppgifter och aktiva tredjepartsuppgifter verkligen var läsbara för vem som helst, inte för att ett specifikt missbruk registrerades.

Antalet agenter stämmer inte heller överens, och bristen på samstämmighet följer plattformens tillväxt snarare än fakta om exponeringen. Implicator.ai skrev den 1 februari utifrån upptäckarens redogörelse och beskriver "över 32 000" registrerade agenter – i en artikel som också säger att sajten passerade 37 000 under sin första vecka – och 1,49 miljoner exponerade poster. Wiz, som granskade den 2 februari, räknade 1,5 miljoner agenter och ungefär 4,75 miljoner poster. Arkivets sammanfattning anger att plattformen till slut samlade 1,7 miljoner registrerade agenter och nästan 7 miljoner kommentarer; den här artikeln bekräftade inte självständigt någon av de slutliga summorna. Det enda antal som alla redogörelser stöder är bilden av det hela: långt fler agenter än människor, och ingen mekanism som kunde skilja dem åt.

Vad förändrades, och vad inställningen inte åtgärdade

Det som ändrades är begränsat och dokumenterat: RLS-principer på de känsliga tabellerna, en skrivbegränsning på de offentliga, raderingen av forskarnas testinlägg och, enligt Wiz, en plattform som var fullt patchad senast 01:00 UTC den 1 februari. Inget i källorna som lästs för den här artikeln beskriver att Moltbook lade till hastighetsbegränsning, verifiering av agentidentitet eller en granskning av innehåll som skrevs under fönstret. Wizs rekommendationer riktar sig mot verktygen snarare än plattformen – AI-assistenter som genererar Supabase-backends skulle kunna aktivera RLS som standard, och distributionsplattformar skulle kunna skanna efter exponerade autentiseringsuppgifter och osäkra konfigurationer.

Det som överlever SQL är den premiss som databasen synliggjorde. Ett nätverk vars försäljningsargument var att endast AI-agenter kunde publicera hade inget sätt att verifiera att en agent var en agent, och dess autentiseringslager var det enda som stod mellan en människa med ett skript och varje identitet på sajten. Det är därför posten registreras som ett vägledande fall snarare än som en rutinmässig felkonfiguration: exponeringen var ordinär, och det den exponerade – ett autentiserat identitetslager för autonoma agenter – var det inte.