Baza danych Moltbook całkowicie otwarta: 1,5 mln kluczy API agentów, 35 000 adresów e-mail

Moltbook to sieć społecznościowa w stylu Reddita, zbudowana tak, aby publikować mogli wyłącznie agenci AI. Jej założyciel, Matt Schlicht, uruchomił ją 28 stycznia 2026 r. i publicznie oświadczył na X, że nie napisał ani jednej linijki jej kodu: „Miałem po prostu wizję architektury technicznej, a AI urzeczywistniła ją” – jak cytuje go Wiz. Trzy dni później, 31 stycznia 2026 r., 404 Media poinformowało, że każdy mógł przejąć kontrolę nad dowolnym agentem AI w serwisie. Wiz, które niezależnie odkryło tę samą błędną konfigurację, opublikowało 2 lutego techniczny opis: klucz API Supabase zaszyty na stałe w kodzie JavaScript po stronie klienta Moltbook wskazywał na produkcyjną bazę danych bez Row Level Security, a nieuwierzytelnione żądanie do tabeli agents zwracało aktywne tokeny uwierzytelniające agentów platformy, w tym tych najbardziej znanych. Wiz naliczyło 1,5 mln tokenów API, 35 000 adresów e-mail i 4060 prywatnych rozmów między agentami, które można było w ten sposób odczytać, i potwierdziło, że mogło również przepisywać opublikowane wpisy. Archiwum klasyfikuje ten epizod jako incydent poświadczeń o krytycznej wadze, z datą z dokładnością do dnia 31 stycznia 2026 r., oceną pewności A i odnotowaniem rzeczywistych szkód, obok pozostałych swoich rekordów dotyczących infrastruktury agentów w Orca AI Incident Archive.

Klucz nigdy nie był tajemnicą

Supabase to hostowana usługa Postgres z interfejsem API REST, którą Wiz opisuje jako popularną wśród aplikacji tworzonych w duchu „vibe codingu”, ponieważ łatwo ją skonfigurować. Jego klucz publiczny jest zaprojektowany tak, by znajdować się w kodzie po stronie klienta: identyfikuje on projekt, a kontrola dostępu ma wynikać z polityk Row Level Security na tabelach stojących za nim. Gal Nagli z Wiz ujmuje tę kwestię wprost w swoim tekście: ujawnienie klucza „nie oznacza automatycznie naruszenia bezpieczeństwa”, a gdy RLS jest skonfigurowany prawidłowo, „publiczny klucz API można bezpiecznie ujawnić – działa on jak identyfikator projektu”. W implementacji Moltbook, pisze Wiz, „brakowało tej kluczowej linii obrony”.

Mechanizm opierał się na jednym pakiecie. Według Wiz produkcyjny plik JavaScript pod adresem moltbook.com/_next/static/chunks/18e24eafc444b2b9.js zawierał zarówno adres projektu Supabase, ehxbxtjliybbloantpwq.supabase.co, jak i klucz, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Następnie Wiz wysłał żądanie do tabeli agents z prośbą o trzy nazwy i klucze API — zapytanie, które powinno zwrócić pustą tablicę lub błąd autoryzacji. Zamiast tego zwróciło wiersze, w tym tokeny uwierzytelniające najpopularniejszych agentów platformy. Na tej podstawie Wiz zmapował schemat, korzystając z komunikatów błędów PostgREST i introspekcji GraphQL, i doliczył się około 4,75 miliona ujawnionych rekordów.

Podsumowanie archiwum podaje, że Moltbook „nigdy nie włączył" Row Level Security, a źródła są mniej precyzyjne niż to stwierdzenie. Żadne z nich nie przedstawia historii konfiguracji, więc udokumentowane jest jedynie to, że RLS nie obowiązywał w czasie przeglądu: Wiz stwierdził, że tabele były otwarte, a Implicator.ai, relacjonując relację znalazcy, pisze, że Moltbook „nigdy nie włączył RLS. A jeśli nawet, to nie skonfigurowano żadnych polityk". Czy ustawienie nigdy nie zostało włączone, czy zostało włączone bez żadnych polityk, nie wynika z żadnej z tych relacji, a praktyczny skutek jest ten sam.

Co właściwie znajdowało się w tabelach

Wiz wymienia nazwy tabel i ich zawartość. Tabela agents zawierała w każdym wierszu api_key uwierzytelniający agenta, claim_token używany do zgłoszenia roszczenia własności do niego, verification_code wydany przy rejestracji oraz liczbę punktów karmy i obserwujących agenta. To kompletny zestaw do przejęcia konta, a nie wyciek danych: mając jeden z tych kluczy, żądanie może publikować, wysyłać wiadomości i w inny sposób działać jako ten agent, a Wiz zauważa, że obejmowało to konta o wysokiej karmie i znane agenty-persony.

Tabela owners zawierała dane osobowe ponad 17 000 użytkowników, w tym adresy e-mail oraz nazwę użytkownika na X i nazwę wyświetlaną stojące za każdym agentem. Tabela observers, którą Wiz odkrył później przez endpoint GraphQL, zawierała kolejne 29 631 adresów e-mail należących do osób zapisanych na wczesny dostęp do planowanego przez Moltbook produktu „Build Apps for AI Agents”. Tabela agent_messages zawierała 4060 prywatnych rozmów w wiadomościach bezpośrednich między agentami, przechowywanych bez szyfrowania i kontroli dostępu, a Wiz donosi, że niektóre zawierały poświadczenia stron trzecich w jawnym tekście, w tym klucze API OpenAI, którymi agenci dzielili się ze sobą.

Stosunek liczby agentów do liczby ludzi to element, który podkopał publiczną narrację platformy. Wiz podaje, że zarejestrowano 1,5 mln agentów wobec około 17 000 ludzkich właścicieli, czyli około 88 agentów na osobę, i przypisuje tę lukę brakowi limitowania liczby żądań lub weryfikacji tożsamości: każdy mógł rejestrować agentów w pętli, a człowiek mógł publikować jako „agent” za pomocą podstawowego żądania POST. Wniosek Wiz jest dosadny – „rewolucyjna sieć społecznościowa AI w dużej mierze była ludźmi obsługującymi floty botów”.

Liczba adresów e-mail nie sumuje się jednoznacznie i Wiz nie wyjaśnia dlaczego. Podana w nagłówku liczba to 35 000 adresów e-mail; własne liczby Wiz na poziomie tabel to ponad 17 000 adresów e-mail właścicieli i 29 631 adresów e-mail obserwatorów, które sumują się do około 46 600. Obie liczby pochodzą od Wiz, a ten tekst nie ustalił, w jaki sposób uzyskano 35 000 – czy przez deduplikację w obu tabelach, czy z migawki wykonanej przed odnalezieniem tabeli obserwatorów.

Zapisowa połowa ekspozycji

Odczyt danych nie był całym odkryciem. Wiz informuje, że nawet po tym, jak pierwsza runda poprawek zablokowała dostęp do odczytu wrażliwych tabel, dostęp do zapisu w tabelach publicznych pozostał otwarty. Firma sprawdziła to, wysyłając żądanie PATCH do aktywnego wpisu i zastępując jego tytuł oraz treść ciągiem „@galnagli - responsible disclosure test”, a następnie potwierdziła, że zmiana jest widoczna w serwisie. Po wprowadzeniu ograniczenia zapisu Wiz nie mógł już cofnąć własnego wpisu testowego; zespół Moltbooka usunął tę treść kilka godzin później — pisze Wiz — i podziękował badaczom za zgłoszenie.

Deklarowana przez Wiz troska nie dotyczy wandalizmu dla samego wandalizmu. Nieuwierzytelniona ścieżka zapisu do postów oznacza, że każdy mógłby wstrzykiwać ładunki prompt injection do treści czytanych przez innych agentów, a Wiz podnosi kwestię integralności postów, głosów i karmy platformy w oknie ekspozycji jako pytanie otwarte, a nie zmierzoną wartość. Żadne źródło czytane na potrzeby tego tekstu nie określa ilościowo, ile treści zmieniono ani przez kogo.

Trzy godziny i dwanaście minut, cztery osobne poprawki

Oś czasu ujawnienia przez Wiz zaczyna się 31 stycznia 2026 o 21:48 UTC pierwszym kontaktem z opiekunem Moltbook przez wiadomość bezpośrednią na X, a kończy 1 lutego o 01:00 UTC, gdy ostatnia z ujawnionych tabel została zabezpieczona. Po tym pierwszym kontakcie odnotowuje siedem kolejnych kroków: zgłoszenie o 22:06, pierwszą poprawkę o 23:29 obejmującą tabele agents, owners i site_admins, drugą o 00:13 obejmującą agent_messages, notifications, votes i follows, wykrycie ścieżki zapisu o 00:31, trzecią poprawkę zamykającą ją o 00:44, wykrycie tabel observers, identity_verifications i developer_apps o 00:50 oraz ostateczną poprawkę o 01:00.

Ta oś czasu jest najsilniejszym argumentem przeciwko najprostszej wersji tej historii. Implicator.ai opisuje poprawkę za pomocą dwóch instrukcji SQL – pisze, że „poprawka wymagała dwóch instrukcji SQL. Nie istniały”, a podsumowanie archiwum zawiera tę samą ramę „dwóch linii SQL”. Kluczowa naprawa ekspozycji na odczyt prawdopodobnie była właśnie tak mała: włączyć RLS i dodać polityki do tabel. Jednak własny zapis Wiz pokazuje cztery poprawki w ciągu trzech godzin, drugą i odrębną lukę w dostępie do zapisu, której poprawka odczytu nie zamknęła, oraz trzy kolejne tabele – w tym 29 631 adresów obserwatorów – które ujawniły się dopiero po pierwszych dwóch rundach. Końcowa lekcja Wiz jest taka, że „pracował z zespołem przez wiele rund remediacji, przy czym każda iteracja ujawniała dodatkowe eksponowane powierzchnie”. Wersja dwuliniowa opisuje zmianę konfiguracji, a nie remediację.

Dwa odkrycia i różnica w zapisie

Odkrycie to zwykle przypisuje się Jamiesonowi O'Reilly'emu, który założył australijską firmę bezpieczeństwa Dvuln i zademonstrował to przejęcie 404 Media; Implicator.ai donosi, że 404 Media zweryfikowało tę możliwość, aktualizując własne konto O'Reilly'ego na Moltbooku za jego zgodą. Wpis Wiz jest autorstwa Gala Nagliego i zawiera na końcu notkę przypisującą zasługę O'Reilly'emu: „Badacz bezpieczeństwa Jameson O'Reilly również odkrył leżącą u podstaw nieprawidłową konfigurację Supabase, o której poinformowało 404 Media”. Notka dodaje, że wpis Wiz opisuje niezależne odkrycie tego samego problemu.

Podsumowanie archiwum opisuje obu jako badaczy Wiz. Sam wpis Wiz już nie: wymienia Nagli jako autora i opisuje O'Reilly'ego jako niezależnego badacza, którego odkrycie relacjonowało 404 Media, a Implicator.ai umieszcza O'Reilly'ego w Dvuln. Pisownia również nie jest ustalona wśród źródeł – Wiz pisze „Jameson”, podczas gdy strona Dvuln wymienia swojego założyciela jako „Jamieson” – a ten tekst użył pisowni stosowanej przez tę stronę. Bezsporne jest to, że w ciągu kilku dni doszło do dwóch niezależnych odkryć tej samej błędnej konfiguracji.

Relacja dotycząca odpowiedzi różni się w zależności od źródła, a tę różnicę warto odnotować, a nie rozstrzygać. Według relacji O'Reilly'ego, przekazanej przez Implicator.ai, zwrócił się on bezpośrednio do Schlichta i zaproponował pomoc w załataniu luki; odpowiedź brzmiała: „Po prostu oddam wszystko AI. Więc prześlij mi wszystko, co masz”. Według tej relacji minął potem cały dzień bez dalszego kontaktu, a Schlicht nie odpowiedział na prośbę 404 Media o komentarz. Wiz, kontaktując się z opiekunem osobno, odnotowuje swoje zgłoszenie złożone o 22:06 UTC oraz ostatnią z czterech poprawek o 01:00 UTC, trzy godziny i dwanaście minut po pierwszym kontakcie. Oba harmonogramy przebiegają na różnych kanałach i żadne źródło nie mówi, czy jeden wywołał drugi; oba mogą być prawdziwe.

Co ustala dokumentacja, a czego nie ustala

Ustalone fakty to konfiguracja, klasy danych, dwa niezależne odkrycia, sekwencja poprawek oraz stosunek liczby ludzi do agentów na platformie. Wszystko z tej listy pochodzi z technicznego opisu sporządzonego przez samego Wiza lub z doniesień opartych na relacji znalazcy, a oba źródła są zgodne co do mechanizmu.

To, czego nie ustalono, zaczyna się od wcześniejszego dostępu. Wiz twierdzi, że wszystkie dane, do których uzyskano dostęp podczas jego badań i weryfikacji poprawki, zostały usunięte, a to nic nie mówi o nikim innym. Implicator.ai ujmuje tę lukę wprost: nikt nie potrafi powiedzieć, czy ktoś znalazł bazę danych przed O'Reillym ani ile z postów, które krążyły w wiralowym tygodniu platformy, było autentycznym wynikiem działania agenta, a ile pochodziło ze skradzionego klucza. Żadne źródło czytane na potrzeby tego tekstu nie donosi o potwierdzonym niewłaściwym użyciu jakichkolwiek ujawnionych danych uwierzytelniających ani nie podaje liczby kont faktycznie przejętych. Flaga real_harm archiwum ma wartość true, ponieważ dane osobowe i aktywne dane uwierzytelniające podmiotów trzecich były rzeczywiście czytelne dla każdego, a nie dlatego, że odnotowano konkretne niewłaściwe użycie.

Liczby agentów również się nie zgadzają, a rozbieżność idzie w ślad za wzrostem platformy, a nie za faktami dotyczącymi ekspozycji. Implicator.ai, pisząc 1 lutego z konta odkrywcy, opisuje „ponad 32 000” zarejestrowanych agentów – w artykule, który mówi też, że witryna przekroczyła 37 000 w pierwszym tygodniu – oraz 1,49 mln ujawnionych rekordów. Wiz, dokonując przeglądu 2 lutego, naliczył 1,5 mln agentów i około 4,75 mln rekordów. Podsumowanie archiwum odnotowuje, że platforma ostatecznie zgromadziła 1,7 mln zarejestrowanych agentów i prawie 7 mln komentarzy; ten artykuł nie potwierdził niezależnie żadnej z tych końcowych sum. Jedyna liczba, co do której zgadzają się wszystkie relacje, to kształt zjawiska: znacznie więcej agentów niż ludzi i brak mechanizmu, który mógłby odróżnić jednych od drugich.

Co się zmieniło i czego to ustawienie nie naprawiło

Zakres zmian jest wąski i udokumentowany: polityki RLS na wrażliwych tabelach, ograniczenie zapisu na tabelach publicznych, usunięcie testowego wpisu badaczy oraz – według Wiz – platforma, która została w pełni załatana do 01:00 UTC 1 lutego. Żadne ze źródeł czytanych na potrzeby tego tekstu nie opisuje, że Moltbook dodał ograniczanie częstotliwości żądań, weryfikację tożsamości agentów ani audyt treści napisanych w tym oknie czasowym. Rekomendacje Wiz dotyczą narzędzi, a nie samej platformy – asystenci AI generujący backendy Supabase mogliby domyślnie włączać RLS, a platformy wdrożeniowe mogłyby skanować w poszukiwaniu ujawnionych poświadczeń i niebezpiecznych konfiguracji.

To, co przetrwa SQL, to założenie, które baza danych uwidoczniła. Sieć, której atutem było to, że publikować mogą wyłącznie agenci AI, nie miała sposobu zweryfikować, że agent jest agentem, a jej warstwa poświadczeń była jedyną rzeczą stojącą między człowiekiem ze skryptem a każdą tożsamością w serwisie. Dlatego ten zapis jest klasyfikowany jako wydarzenie przełomowe, a nie jako rutynowa błędna konfiguracja: samo ujawnienie było zwyczajne, ale to, co ujawniło — uwierzytelniona warstwa tożsamości dla autonomicznych agentów — już nie.