Banco de dados do Moltbook totalmente aberto: 1,5 milhão de chaves de API de agentes, 35.000 e-mails

Moltbook é uma rede social no estilo Reddit criada para que apenas agentes de IA possam publicar. Seu fundador, Matt Schlicht, a lançou em 28 de janeiro de 2026 e disse publicamente no X que não havia escrito uma única linha de seu código: "Eu só tinha uma visão para a arquitetura técnica, e a IA a tornou realidade", como a Wiz o cita. Três dias depois, em 31 de janeiro de 2026, a 404 Media relatou que qualquer pessoa poderia assumir o controle de qualquer agente de IA no site. A Wiz, que havia encontrado a mesma configuração incorreta de forma independente, publicou o relato técnico em 2 de fevereiro: uma chave de API do Supabase codificada diretamente no JavaScript do lado do cliente do Moltbook apontava para um banco de dados de produção sem Row Level Security, e uma requisição não autenticada à tabela agents retornava tokens de autenticação ativos dos agentes da plataforma, incluindo os mais conhecidos. A Wiz contabilizou 1,5 milhão de tokens de API, 35.000 endereços de e-mail e 4.060 conversas privadas entre agentes que podiam ser lidas dessa forma, e confirmou que também poderia reescrever postagens ao vivo. O arquivo registra o episódio como um incidente de credenciais de severidade crítica, com data de precisão de dia de 31 de janeiro de 2026, grau de confiança A e dano real registrado, junto com o restante de seus registros de infraestrutura de agentes no Orca AI Incident Archive.

A chave nunca foi o segredo

O Supabase é um serviço hospedado de Postgres com uma API REST que a Wiz descreve como popular entre aplicações criadas por vibe coding porque é fácil de configurar. Sua chave publicável foi projetada para ficar no código do lado do cliente: ela identifica o projeto, e o controle de acesso deve vir das políticas de Row Level Security nas tabelas por trás dela. Gal Nagli, da Wiz, afirma o ponto explicitamente no relatório: expor a chave "não indica automaticamente uma falha de segurança" e, quando o RLS está configurado corretamente, "a chave pública da API pode ser exposta com segurança — ela funciona como um identificador de projeto". Na implementação do Moltbook, escreve a Wiz, "essa linha de defesa crítica estava ausente".

O mecanismo era um pacote. Segundo a Wiz, o arquivo JavaScript de produção em moltbook.com/_next/static/chunks/18e24eafc444b2b9.js continha tanto o endereço do projeto Supabase, ehxbxtjliybbloantpwq.supabase.co, quanto a chave, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. A Wiz então enviou uma solicitação à tabela agents pedindo três nomes e chaves de API, uma consulta que deveria ter retornado um array vazio ou um erro de autorização. Em vez disso, retornou linhas, incluindo os tokens de autenticação dos agentes mais populares da plataforma. A partir daí, a Wiz mapeou o esquema usando mensagens de erro do PostgREST e introspecção GraphQL, e contou aproximadamente 4,75 milhões de registros expostos.

O resumo do arquivo diz que o Moltbook "nunca habilitou" o Row Level Security, e as fontes são mais vagas que isso. Nenhuma das duas mostra um histórico de configuração, então o que está documentado é que o RLS não estava em vigor durante a revisão: a Wiz encontrou as tabelas abertas, e a Implicator.ai, reproduzindo o relato de quem fez a descoberta, escreve que o Moltbook "nunca ativou o RLS. Ou, se ativou, nenhuma política foi configurada." Se a configuração nunca foi habilitada ou foi habilitada sem políticas implementadas não é estabelecido por nenhum dos relatos, e o resultado prático é o mesmo.

O que havia realmente nas tabelas

A Wiz nomeia as tabelas e seus conteúdos. A tabela agents continha, por linha, a api_key que autenticava o agente, um claim_token usado para reivindicar a propriedade dele, um verification_code emitido no registro, e as contagens de karma e de seguidores do agente. Trata-se de um kit completo de tomada de conta, e não de um vazamento de dados: com uma dessas chaves, uma requisição pode publicar, enviar mensagens e, de outras formas, agir como esse agente, e a Wiz observa que isso incluía contas com karma alto e agentes persona conhecidos.

A tabela owners continha informações pessoais de mais de 17.000 usuários, incluindo endereços de e-mail, além do identificador no X e do nome de exibição por trás de cada agente. Uma tabela que a Wiz encontrou depois por meio do endpoint GraphQL, observers, continha outros 29.631 endereços de e-mail pertencentes a inscrições de acesso antecipado ao produto planejado da Moltbook, "Build Apps for AI Agents". A tabela agent_messages continha 4.060 conversas privadas de mensagens diretas entre agentes, armazenadas sem criptografia nem controles de acesso, e a Wiz relata que algumas continham credenciais de terceiros em texto simples, incluindo chaves de API da OpenAI que os agentes compartilharam entre si.

A proporção entre agentes e pessoas é a parte que minou a narrativa pública da plataforma. A Wiz relata 1,5 milhão de agentes registrados contra cerca de 17.000 proprietários humanos, aproximadamente 88 agentes por pessoa, e atribui a diferença à ausência de limitação de taxa ou verificação de identidade: qualquer um podia registrar agentes em loop, e uma pessoa podia publicar como "agente" com uma solicitação POST básica. A conclusão da Wiz é direta — "a revolucionária rede social de IA era, em grande parte, humanos operando frotas de bots."

A contagem de e-mails não fecha de forma limpa e a Wiz não explica por quê. Seu número principal é 35.000 endereços de e-mail; suas próprias contagens no nível das tabelas são mais de 17.000 e-mails de proprietários e 29.631 e-mails de observadores, que somam aproximadamente 46.600. Ambos os números são da Wiz, e esta matéria não estabeleceu como os 35.000 foram obtidos — se por deduplicação entre as duas tabelas ou a partir de um instantâneo tirado antes de a tabela de observadores ser encontrada.

A metade de escrita da exposição

Ler os dados não foi a descoberta inteira. A Wiz relata que, mesmo depois de a primeira rodada de correções bloquear o acesso de leitura às tabelas sensíveis, o acesso de escrita às tabelas públicas permaneceu aberto. A Wiz testou isso enviando uma solicitação PATCH a uma postagem ativa e substituindo seu título e corpo pela string "@galnagli - responsible disclosure test", depois confirmou que a edição estava visível no site. Depois que a restrição de escrita entrou em vigor, a Wiz não conseguiu mais reverter sua própria postagem de teste; a equipe do Moltbook excluiu o conteúdo algumas horas depois, escreve a Wiz, e agradeceu aos pesquisadores pelo relatório.

A preocupação declarada da Wiz não é a desfiguração por si só. Um caminho de escrita não autenticado para posts significa que qualquer pessoa poderia injetar cargas de injeção de prompt em conteúdo que outros agentes leem, e a Wiz levanta a integridade dos posts, votos e karma da plataforma durante a janela de exposição como uma questão em aberto, e não como algo medido. Nenhuma fonte consultada para esta matéria quantifica quanto conteúdo foi alterado ou por quem.

Três horas e doze minutos, quatro correções separadas

A cronologia de divulgação da Wiz começa às 21:48 UTC de 31 de janeiro de 2026, com um contato inicial ao mantenedor do Moltbook por mensagem direta no X, e termina às 01:00 UTC de 1 de fevereiro, quando a última das tabelas expostas foi protegida. Após esse primeiro contato, ela registra mais sete etapas: o relatório às 22:06; uma primeira correção às 23:29, abrangendo as tabelas agents, owners e site_admins; uma segunda às 00:13, abrangendo agent_messages, notifications, votes e follows; a descoberta do caminho de escrita às 00:31; a terceira correção, encerrando-o às 00:44; a descoberta das tabelas observers, identity_verifications e developer_apps às 00:50; e a correção final às 01:00.

Essa linha do tempo é o argumento mais forte contra a versão mais simples desta história. A Implicator.ai descreve a correção em duas instruções SQL — ela escreve que "a correção exigiu duas instruções SQL. Elas não existiam", e o resumo do arquivo traz o mesmo enquadramento de "duas linhas de SQL". O reparo central para a exposição de leitura provavelmente foi mesmo pequeno: habilitar RLS e adicionar políticas às tabelas. Mas o próprio registro da Wiz mostra quatro correções ao longo de três horas, uma segunda lacuna separada de acesso de escrita que a correção de leitura não fechou, e mais três tabelas — incluindo os 29.631 endereços de observadores — que só apareceram depois das duas primeiras rodadas. A lição final da Wiz é que ela "trabalhou com a equipe em várias rodadas de remediação, com cada iteração revelando superfícies adicionais expostas". A versão de duas linhas descreve a mudança de configuração, não a remediação.

Duas descobertas, e uma diferença no registro

A descoberta costuma ser atribuída a Jamieson O'Reilly, que fundou a empresa australiana de segurança Dvuln e que demonstrou a tomada de controle ao 404 Media; o Implicator.ai relata que o 404 Media verificou a capacidade atualizando a própria conta de O'Reilly no Moltbook com a permissão dele. A publicação da Wiz é de Gal Nagli e traz uma nota no final creditando O'Reilly: "O pesquisador de segurança Jameson O'Reilly também descobriu a configuração incorreta subjacente do Supabase, que foi reportada pelo 404 Media." A nota continua dizendo que a publicação da Wiz compartilha uma descoberta independente do mesmo problema.

O resumo do arquivo descreve ambos como pesquisadores da Wiz. A própria publicação da Wiz não: ela nomeia Nagli como autor e descreve O'Reilly como um pesquisador independente cuja descoberta foi noticiada pelo 404 Media, e o Implicator.ai situa O'Reilly na Dvuln. A grafia também é inconsistente entre as fontes — a Wiz escreve "Jameson", enquanto o próprio site da Dvuln lista seu fundador como "Jamieson" — e este artigo usou a grafia adotada por esse site. O que não está em disputa é que houve duas descobertas independentes da mesma configuração incorreta em questão de dias.

O relato da resposta varia conforme a fonte, e a diferença vale a pena ser relatada em vez de resolvida. Segundo o relato de O'Reilly, repassado pelo Implicator.ai, ele procurou Schlicht diretamente e se ofereceu para ajudar a corrigir a falha; a resposta foi: "Vou simplesmente entregar tudo à IA. Então me mande o que você tiver." Segundo esse relato, passou-se um dia inteiro sem retorno, e Schlicht não respondeu ao pedido de comentário do 404 Media. A Wiz, que contatou o mantenedor separadamente, registra seu relatório enviado às 22:06 UTC e a última de quatro correções às 01:00 UTC, três horas e doze minutos após o primeiro contato. As duas cronologias correm em canais diferentes e nenhuma das fontes diz se uma provocou a outra; ambas podem estar corretas.

O que o registro estabelece, e o que não estabelece

Os fatos estabelecidos são a configuração, as classes de dados, as duas descobertas independentes, a sequência de correção e a proporção entre humanos e agentes na plataforma. Tudo nessa lista vem do documento técnico próprio da Wiz ou de reportagens baseadas no relato de quem fez a descoberta, e ambos concordam quanto ao mecanismo.

O que não está estabelecido começa pelo acesso prévio. A Wiz afirma que todos os dados acessados durante sua pesquisa e verificação da correção foram excluídos, e isso não diz nada sobre mais ninguém. A Implicator.ai expõe a lacuna com clareza: ninguém pode dizer se alguém encontrou o banco de dados antes de O'Reilly, nem quantas das postagens que circularam durante a semana de viralização da plataforma eram resultado genuíno do agente e quantas vieram de uma chave roubada. Nenhuma fonte consultada para este artigo relata um uso indevido confirmado de qualquer credencial exposta, e nenhuma relata uma contagem de contas efetivamente comprometidas. O sinalizador real_harm do arquivo é verdadeiro porque dados pessoais e credenciais ativas de terceiros eram realmente legíveis por qualquer pessoa, não porque um uso indevido específico tenha sido registrado.

As contagens de agentes também divergem, e a divergência acompanha o crescimento da plataforma, e não os factos da exposição. O Implicator.ai, escrevendo a 1 de fevereiro a partir da conta do autor da descoberta, descreve "mais de 32 000" agentes registados — num artigo que também afirma que o site ultrapassou os 37 000 na primeira semana — e 1,49 milhões de registos expostos. A Wiz, numa análise de 2 de fevereiro, contou 1,5 milhões de agentes e cerca de 4,75 milhões de registos. O resumo do arquivo regista que a plataforma acabou por acumular 1,7 milhões de agentes registados e quase 7 milhões de comentários; este artigo não corroborou de forma independente nenhum desses totais finais. O único número em que todos os relatos concordam é a forma da coisa: muitos mais agentes do que humanos, e nenhum mecanismo capaz de distinguir uns dos outros.

O que mudou, e o que a configuração não corrigiu

O que mudou é restrito e documentado: políticas de RLS nas tabelas sensíveis, uma restrição de escrita nas tabelas públicas, a exclusão do post de teste dos pesquisadores e, segundo a Wiz, uma plataforma que foi totalmente corrigida até 01:00 UTC de 1º de fevereiro. Nada nas fontes consultadas para este artigo descreve o Moltbook adicionando limitação de taxa, verificação de identidade de agentes ou uma auditoria do conteúdo escrito durante o período. As recomendações da Wiz são voltadas às ferramentas, e não à plataforma — assistentes de IA que geram back-ends Supabase poderiam habilitar RLS por padrão, e plataformas de implantação poderiam verificar credenciais expostas e configurações inseguras.

A parte que sobrevive ao SQL é a premissa que o banco de dados tornou visível. Uma rede cujo argumento de venda era que apenas agentes de IA podiam publicar não tinha como verificar que um agente era um agente, e sua camada de credenciais era a única coisa entre um humano com um script e todas as identidades do site. É por isso que o registro é arquivado como um marco, e não como uma configuração incorreta rotineira: a exposição era comum, e o que ela expunha — uma camada de identidade autenticada para agentes autônomos — não era.