Database Moltbook completamente aperto: 1,5 milioni di chiavi API degli agenti, 35.000 email

Moltbook è un social network in stile Reddit creato in modo che solo gli agenti AI possano pubblicare. Il suo fondatore, Matt Schlicht, l'ha lanciato il 28 gennaio 2026 e ha dichiarato pubblicamente su X che non aveva scritto una sola riga del suo codice: "Avevo solo una visione dell'architettura tecnica, e l'AI l'ha resa realtà", come lo cita Wiz. Tre giorni dopo, il 31 gennaio 2026, 404 Media ha riportato che chiunque poteva assumere il controllo di qualsiasi agente AI sul sito. Wiz, che aveva trovato indipendentemente la stessa errata configurazione, ha pubblicato il resoconto tecnico il 2 febbraio: una chiave API Supabase incorporata direttamente nel JavaScript lato client di Moltbook puntava a un database di produzione senza Row Level Security, e una richiesta non autenticata alla tabella agents restituiva token di autenticazione attivi per gli agenti della piattaforma, inclusi quelli più noti. Wiz ha contato 1,5 milioni di token API, 35.000 indirizzi email e 4.060 conversazioni private tra agenti leggibili in quel modo, e ha confermato che poteva anche riscrivere post pubblicati. L'archivio classifica l'episodio come un incidente di credenziali di gravità critica con data precisa al giorno 31 gennaio 2026, un grado di affidabilità A e danni reali registrati, insieme al resto dei suoi record di infrastruttura per agenti nell'Orca AI Incident Archive.

La chiave non è mai stata il segreto

Supabase è un servizio Postgres ospitato con un'API REST che Wiz descrive come popolare tra le applicazioni vibe-coded perché è facile da configurare. La sua chiave pubblicabile è pensata per risiedere nel codice lato client: identifica il progetto e il controllo degli accessi dovrebbe derivare dai criteri di Row Level Security sulle tabelle sottostanti. Gal Nagli di Wiz afferma esplicitamente il concetto nel report: esporre la chiave "non indica automaticamente una falla di sicurezza" e, quando RLS è configurato correttamente, "la chiave API pubblica può essere esposta in sicurezza: funge da identificatore di progetto". Nell'implementazione di Moltbook, scrive Wiz, "mancava questa linea di difesa critica".

Il meccanismo era un bundle. Secondo Wiz, il file JavaScript di produzione su moltbook.com/_next/static/chunks/18e24eafc444b2b9.js conteneva sia l'indirizzo del progetto Supabase, ehxbxtjliybbloantpwq.supabase.co, sia la chiave, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz ha quindi inviato una richiesta alla tabella agents chiedendo tre nomi e chiavi API, una query che avrebbe dovuto restituire un array vuoto o un errore di autorizzazione. Ha invece restituito delle righe, inclusi i token di autenticazione degli agenti più popolari della piattaforma. Da lì Wiz ha mappato lo schema usando i messaggi di errore di PostgREST e l'introspezione GraphQL, e ha contato circa 4,75 milioni di record esposti.

Il riepilogo dell'archivio afferma che Moltbook «non ha mai abilitato» Row Level Security, e le fonti sono meno precise di così. Nessuna delle due mostra una cronologia della configurazione, quindi ciò che è documentato è che RLS non era in vigore durante la revisione: Wiz ha trovato le tabelle aperte, e Implicator.ai, riportando il resoconto di chi ha effettuato la scoperta, scrive che Moltbook «non ha mai attivato RLS. O, se lo ha fatto, non erano configurate policy». Che l'impostazione non sia mai stata abilitata o sia stata abilitata senza policy in essere non è stabilito da nessuna delle due versioni, e il risultato pratico è lo stesso.

Che cosa c'era davvero nelle tabelle

Wiz nomina le tabelle e i loro contenuti. La tabella agents conteneva, per ogni riga, l'api_key che autenticava l'agente, un claim_token usato per rivendicarne la proprietà, un verification_code rilasciato alla registrazione, e i conteggi di karma e follower dell'agente. Si tratta di un kit completo per il takeover dell'account più che di una fuga di dati: con una di quelle chiavi, una richiesta può pubblicare, inviare messaggi e agire in altro modo come quell'agente, e Wiz osserva che ciò includeva account con karma elevato e agenti-persona ben noti.

La tabella owners conteneva informazioni personali per oltre 17.000 utenti, inclusi indirizzi email insieme all'handle X e al nome visualizzato associati a ciascun agente. Una tabella che Wiz ha trovato in seguito tramite l'endpoint GraphQL, observers, conteneva altri 29.631 indirizzi email appartenenti alle iscrizioni all'accesso anticipato per il prodotto previsto di Moltbook "Build Apps for AI Agents". La tabella agent_messages conteneva 4.060 conversazioni private in messaggi diretti tra agenti, memorizzate senza cifratura né controlli di accesso, e Wiz riferisce che alcune contenevano credenziali di terze parti in testo in chiaro, incluse chiavi API OpenAI che gli agenti si erano scambiati tra loro.

Il rapporto tra agenti e persone è l'elemento che ha minato la narrazione pubblica della piattaforma. Wiz riporta 1,5 milioni di agenti registrati rispetto a circa 17.000 proprietari umani, circa 88 agenti per persona, e attribuisce il divario all'assenza di limiti di frequenza o di verifica dell'identità: chiunque poteva registrare agenti in loop, e un umano poteva pubblicare come "agente" con una semplice richiesta POST. La conclusione di Wiz è netta: "il rivoluzionario social network basato sull'IA era in gran parte composto da umani che gestivano flotte di bot."

Il conteggio delle email non quadra in modo pulito e Wiz non spiega perché. La sua cifra principale è 35.000 indirizzi email; i suoi conteggi a livello di tabella sono oltre 17.000 email dei proprietari e 29.631 email degli osservatori, che sommano a circa 46.600. Entrambi i numeri sono di Wiz, e questo articolo non ha stabilito come sia stato ricavato il 35.000, se tramite deduplicazione tra le due tabelle o da un'istantanea scattata prima che fosse trovata la tabella degli osservatori.

La metà di scrittura dell'esposizione

La lettura dei dati non costituiva l'intera scoperta. Wiz riferisce che, anche dopo che il primo ciclo di correzioni aveva bloccato l'accesso in lettura alle tabelle sensibili, l'accesso in scrittura alle tabelle pubbliche è rimasto aperto. Lo ha verificato inviando una richiesta PATCH a un post pubblicato e sostituendone il titolo e il corpo con la stringa "@galnagli - responsible disclosure test", poi ha confermato che la modifica era visibile sul sito. Dopo l'introduzione della restrizione in scrittura, a Wiz non è più stato possibile ripristinare il proprio post di test; il team di Moltbook ha eliminato il contenuto poche ore dopo, scrive Wiz, e ha ringraziato i ricercatori per la segnalazione.

La preoccupazione dichiarata di Wiz non è il deturpamento fine a se stesso. Un percorso di scrittura non autenticato verso i post significa che chiunque potrebbe iniettare payload di prompt injection nei contenuti che altri agenti leggono, e Wiz solleva l'integrità dei post, dei voti e del karma della piattaforma durante la finestra di esposizione come una questione aperta anziché come un dato misurato. Nessuna fonte consultata per questo articolo quantifica quanto contenuto sia stato alterato o da chi.

Tre ore e dodici minuti, quattro riparazioni separate

La cronologia della divulgazione di Wiz inizia alle 21:48 UTC del 31 gennaio 2026, con un primo contatto con il manutentore di Moltbook tramite messaggio diretto su X, e termina alle 01:00 UTC del 1° febbraio, quando l'ultima delle tabelle esposte è stata messa in sicurezza. Dopo quel primo contatto registra altri sette passaggi: la segnalazione alle 22:06, una prima correzione alle 23:29 che riguarda le tabelle agents, owners e site_admins, una seconda alle 00:13 che riguarda agent_messages, notifications, votes e follows, la scoperta del percorso di scrittura alle 00:31, la terza correzione che lo chiude alle 00:44, la scoperta delle tabelle observers, identity_verifications e developer_apps alle 00:50, e la correzione finale alle 01:00.

Quella cronologia è l'argomento più forte contro la versione più semplice di questa storia. Implicator.ai descrive la correzione in due istruzioni SQL — scrive che «la correzione richiedeva due istruzioni SQL. Non esistevano», e il riepilogo dell'archivio riporta la stessa impostazione delle «due righe di SQL». La riparazione principale per l'esposizione in lettura probabilmente è stata davvero così piccola: abilitare RLS e aggiungere policy sulle tabelle. Ma il resoconto di Wiz mostra quattro correzioni nell'arco di tre ore, una seconda e distinta lacuna di accesso in scrittura che la correzione della lettura non ha colmato, e altre tre tabelle — compresi i 29,631 indirizzi degli osservatori — emerse solo dopo i primi due cicli. La lezione conclusiva di Wiz è che ha «lavorato con il team attraverso più cicli di correzione, con ogni iterazione che faceva emergere ulteriori superfici esposte». La versione delle due righe descrive la modifica di configurazione, non la correzione.

Due scoperte, e una differenza nel registro

La scoperta è generalmente attribuita a Jamieson O'Reilly, che ha fondato l'azienda di sicurezza australiana Dvuln e che ha dimostrato la presa di controllo a 404 Media; Implicator.ai riferisce che 404 Media ha verificato la capacità aggiornando l'account Moltbook di O'Reilly con il suo permesso. Il post di Wiz è di Gal Nagli e contiene una nota alla fine che attribuisce il merito a O'Reilly: "Anche il ricercatore di sicurezza Jameson O'Reilly ha scoperto la misconfigurazione Supabase sottostante, che è stata segnalata da 404 Media." La nota prosegue dicendo che il post di Wiz condivide una scoperta indipendente dello stesso problema.

Il riepilogo dell'archivio li descrive entrambi come ricercatori Wiz. Il post di Wiz non lo fa: indica Nagli come autore e descrive O'Reilly come un ricercatore indipendente la cui scoperta è stata riportata da 404 Media, e Implicator.ai colloca O'Reilly presso Dvuln. Anche l'ortografia è incerta tra le fonti - Wiz scrive "Jameson", mentre il sito di Dvuln elenca il suo fondatore come "Jamieson" - e questo articolo ha usato l'ortografia adottata da quel sito. Ciò che non è in discussione è che ci sono state due scoperte indipendenti della stessa configurazione errata nel giro di pochi giorni.

Il resoconto della risposta varia a seconda della fonte, e la differenza merita di essere riportata anziché risolta. Secondo il resoconto di O'Reilly, riportato da Implicator.ai, egli si rivolse direttamente a Schlicht e si offrì di aiutare a correggere la falla; la risposta fu: «Darò semplicemente tutto all'IA. Quindi mandami qualunque cosa tu abbia.» Secondo quel resoconto, trascorse poi un giorno intero senza seguito, e Schlicht non rispose alla richiesta di commento di 404 Media. Wiz, contattando il manutentore separatamente, registra il proprio report presentato alle 22:06 UTC e l'ultima di quattro correzioni alle 01:00 UTC, tre ore e dodici minuti dopo il primo contatto. Le due cronologie scorrono su canali diversi e nessuna delle due fonti dice se una abbia sollecitato l'altra; entrambe possono essere accurate.

Cosa stabilisce il verbale, e cosa non stabilisce

I fatti accertati sono la configurazione, le classi di dati, le due scoperte indipendenti, la sequenza di correzione e il rapporto tra esseri umani e agenti della piattaforma. Tutto in quell'elenco proviene dal resoconto tecnico di prima mano di Wiz o da articoli basati sul racconto dello scopritore, e i due concordano sul meccanismo.

Ciò che non è stabilito parte dall'accesso precedente. Wiz afferma che tutti i dati consultati durante la sua ricerca e la verifica della correzione sono stati cancellati, e ciò non dice nulla su nessun altro. Implicator.ai mette in chiaro la lacuna: nessuno può sapere se qualcuno abbia trovato il database prima di O'Reilly, né quanti dei post circolati durante la settimana virale della piattaforma fossero autentici output dell'agente e quanti provenissero da una chiave rubata. Nessuna fonte consultata per questo articolo riporta un uso improprio confermato di credenziali esposte, e nessuna riporta un conteggio degli account effettivamente compromessi. Il flag real_harm dell'archivio è true perché dati personali e credenziali di terze parti attive erano realmente leggibili da chiunque, non perché sia stato registrato un uso improprio specifico.

Anche i conteggi degli agenti non concordano, e il disaccordo segue la crescita della piattaforma anziché i fatti dell’esposizione. Implicator.ai, scrivendo il 1° febbraio dall’account dello scopritore, descrive «oltre 32.000» agenti registrati – in un articolo che afferma anche che il sito ha superato i 37.000 nella prima settimana – e 1,49 milioni di record esposti. Wiz, in una revisione del 2 febbraio, ha contato 1,5 milioni di agenti e circa 4,75 milioni di record. Il riepilogo dell’archivio riporta che la piattaforma ha finito per accumulare 1,7 milioni di agenti registrati e quasi 7 milioni di commenti; questo articolo non ha corroborato in modo indipendente nessuno dei due totali finali. L’unico dato che tutti i resoconti supportano è la forma della cosa: molti più agenti che umani, e nessun meccanismo in grado di distinguere gli uni dagli altri.

Cosa è cambiato e cosa l'impostazione non ha risolto

Ciò che è cambiato è limitato e documentato: le policy RLS sulle tabelle sensibili, una restrizione di scrittura su quelle pubbliche, l'eliminazione del post di prova dei ricercatori e, secondo Wiz, una piattaforma su cui tutte le patch erano state applicate entro le 01:00 UTC del 1° febbraio. Nessuna delle fonti consultate per questo articolo descrive Moltbook che introduce limitazioni della frequenza, verifica dell'identità degli agenti o un audit dei contenuti scritti durante la finestra temporale. Le raccomandazioni di Wiz sono rivolte agli strumenti piuttosto che alla piattaforma: gli assistenti AI che generano backend Supabase potrebbero abilitare RLS per impostazione predefinita, e le piattaforme di deployment potrebbero scansionare alla ricerca di credenziali esposte e configurazioni non sicure.

La parte che sopravvive all'SQL è la premessa che il database ha reso visibile. Una rete il cui punto di forza era che solo gli agenti AI potessero pubblicare non aveva modo di verificare che un agente fosse un agente, e il suo livello di credenziali era l'unica cosa che separava un umano con uno script da ogni identità sul sito. Ecco perché il record è archiviato come una pietra miliare anziché come una banale configurazione errata: l'esposizione era ordinaria, e ciò che esponeva - uno strato di identità autenticata per agenti autonomi - non lo era.