Hack do MoltBook: erro de configuração no Supabase expôs 1,5 milhão de chaves de API

 (wiz.io)
10 pontos por GN⁺ 2026-02-04 | 8 comentários | Compartilhar no WhatsApp
  • O banco de dados do Moltbook, plataforma social voltada exclusivamente para agentes de IA, foi configurado incorretamente, expondo externamente 1,5 milhão de tokens de autenticação de API, 35 mil e-mails e mensagens privadas
  • A chave de API do Supabase estava hardcoded no JavaScript do lado do cliente e, sem configuração de Row Level Security (RLS), qualquer pessoa podia ter acesso de leitura e escrita a todo o banco de dados
  • Os dados incluíam informações de 17 mil usuários reais e de 1,5 milhão de contas de agentes operadas por eles, confirmando uma proporção humano versus agente de 1:88
  • Entre as informações expostas estavam chaves de API da OpenAI e outras credenciais de terceiros, conversas privadas e até permissões para editar postagens, criando risco de comprometimento da integridade do conteúdo da plataforma
  • O incidente expõe os limites de segurança do “vibe coding” baseado em IA e mostra a necessidade de automatizar padrões de segurança e reforçar procedimentos de validação em ambientes de desenvolvimento com IA

Visão geral do Moltbook e da exposição de segurança

  • O Moltbook é uma rede social centrada em IA em que agentes de IA atuam por meio de publicações, comentários, votos e pontuação de reputação, apresentando-se como “a primeira página da internet dos agentes”
    • O cofundador da OpenAI, Andrej Karpathy, chamou o projeto de “o salto mais surpreendente de ficção científica”, o que atraiu atenção
  • O fundador da plataforma afirmou que “a IA escreveu o código diretamente”, e o desenvolvimento foi feito no estilo de “vibe coding”
  • A equipe de pesquisa da Wiz descobriu uma configuração incorreta no banco de dados Supabase, que permitia acesso de leitura e escrita a todos os dados; após a notificação, o problema foi corrigido em poucas horas

Credenciais do Supabase expostas

  • As informações de conexão com o Supabase foram encontradas hardcoded no bundle de JavaScript do cliente do site do Moltbook
    • Projeto: ehxbxtjliybbloantpwq.supabase.co
    • Chave de API: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • O Supabase permite a exposição de chaves públicas em si, mas sem políticas de RLS é possível acessar todo o banco de dados
  • No Moltbook, o RLS estava desativado, deixando públicas as permissões de leitura e escrita em todas as tabelas

Acesso não autenticado ao banco de dados

  • Ao chamar diretamente a API REST com a chave de API, a equipe de pesquisa recebeu uma resposta em nível de administrador
  • A resposta incluía chaves de API e tokens de autenticação dos principais agentes, o que permitia comprometimento completo das contas
  • Usando mensagens de erro do PostgREST e introspecção GraphQL, foi possível mapear todo o schema e confirmar a exposição de cerca de 4,75 milhões de registros

Dados sensíveis expostos

  • Credenciais dos agentes: incluíam api_key, claim_token e verification_code de cada conta
    • Com isso, um atacante podia fazer login como qualquer agente, publicar posts e enviar mensagens
  • E-mails e informações de identidade dos usuários: foram expostos e-mails de mais de 17 mil usuários e identificadores no X (Twitter)
    • Além disso, foram encontrados 29.631 e-mails na tabela observers
  • Mensagens privadas e credenciais de terceiros: 4.060 DMs estavam armazenadas sem criptografia, e algumas continham chaves de API da OpenAI em texto puro
  • Exposição de permissão de escrita: era possível editar postagens sem autenticação, criando risco de inserção de conteúdo malicioso e adulteração do site
    • Um teste real conseguiu editar uma postagem, e isso só foi bloqueado depois da aplicação de políticas de RLS

5 lições de segurança para o desenvolvimento de apps de IA

  • 1. Velocidade alta de desenvolvimento pode causar risco sistêmico quando faltam padrões de segurança
    • Uma única linha na configuração do Supabase causou toda a exposição
  • 2. É necessário verificar as métricas de engajamento
    • Entre 1.500.000 agentes, havia apenas 17 mil humanos reais, sugerindo uma possível atividade inflada na proporção de 88:1
  • 3. Efeito em cascata do colapso de privacidade
    • A exposição de DMs levou ao vazamento de credenciais de serviços externos, como chaves de API da OpenAI
  • 4. Permissão de escrita é uma ameaça à integridade mais grave do que simples vazamento de dados
    • Há riscos como manipulação de conteúdo, prompt injection e controle narrativo
  • 5. Maturidade de segurança é um processo de melhoria iterativa
    • As equipes da Wiz e do Moltbook protegeram todas as tabelas após várias rodadas de correção e verificação

Vibe coding e os desafios de segurança

  • A IA reduziu a barreira de entrada para o desenvolvimento, mas a barreira de segurança continua alta
  • Ferramentas de desenvolvimento com IA precisam aplicar automaticamente padrões de segurança por padrão (como ativação de RLS e varredura de credenciais)
  • Quando a segurança se tornar um elemento nativo e embutido no desenvolvimento com IA, será possível construir um ecossistema de software de IA seguro e inovador

Linha do tempo

  • 31 de janeiro de 2026 21:48 UTC: primeiro contato com o mantenedor do Moltbook
  • 22:06: reportada a má configuração de RLS no Supabase
  • 23:29: 1ª correção (proteção das tabelas agents, owners e site_admins)
  • 1º de fevereiro 00:13: 2ª correção (proteção de agent_messages e outras)
  • 00:31: descoberta da vulnerabilidade de edição de postagens
  • 00:44: 3ª correção bloqueia permissões de escrita
  • 00:50~01:00: descoberta de tabelas adicionais expostas e conclusão da correção final

Leituras relacionadas

8 comentários

 
iolothebard 2026-02-04

Enquanto dançava alegremente… simplesmente… vá à falência!
 
rustkim 2026-02-05

O que sobra é o Mac mini; como ainda está no começo, provavelmente vai sair algo melhor, né?
 
gogokow27 2026-02-05

kkkkkkkkkkkkk....
 
kuthia 2026-02-04

Finalmente, o inevitável chegou.
 
crawler 2026-02-04

No MoltBot já estourou problema de hack até com os agentes, e agora até a plataforma foi pro espaço kkk

Acho que vai ficar como um caso clássico de projeto com a pior vibe de 2026.
Ainda estamos em fevereiro, mas dá pra ter certeza kkk
 
bini59 2026-02-04

O problema seria que serviços em larga escala conseguem ser desenvolvidos sem nem se preocupar com segurança, só no vibe coding?
 
kimjoin2 2026-02-04

UAU
 
GN⁺ 2026-02-04
Opiniões do Hacker News

  • O sucesso do Moltbot/Moltbook pareceu surpreendente no começo, mas agora faz sentido
    O ponto central é que se trata de "agentes pré-empacotados". Para usuários comuns sem familiaridade com tecnologia, algo como “comprar um Mac mini e instalar copiando algumas linhas” tem um apelo enorme em termos de acessibilidade
    Mas essa acessibilidade está alimentando um pesadelo de segurança. À medida que aumenta o número de usuários que seguem a moda sem entendimento técnico, cresce o risco de ambientes vulneráveis permanecerem por mais tempo

    • Fica a dúvida se isso pode mesmo ser chamado de sucesso. Há análises dizendo que, na prática, dos 1,5 milhão de agentes, só 17 mil pertencem a humanos. Também houve um forte efeito viral por causa de menções de influenciadores famosos
    • Todo LLM é vulnerável em termos de segurança por projeto. Dá para contornar facilmente com prompt injection ou reward hacking. A única solução completa seria bloquear totalmente entrada externa e acesso à rede
    • “Comprar um Mac mini e instalar” é só slogan de marketing. Na prática, erros de configuração são frequentes e o gerenciamento de contexto é uma bagunça. Os logs ficam, mas ele esquece até a conversa imediatamente anterior. A ideia é boa, mas a implementação é áspera
    • Como aconteceu com o Dropbox no começo, o fator de sucesso é a ‘acessibilidade empacotada’. Mas, num mundo em que nem grandes empresas conseguem evitar invasões, um banco de dados mal configurado acaba sendo tratado como algo menor. Conveniência ainda vence segurança
    • Ainda não está claro se foi só um assunto que viralizou ou se é um sucesso de verdade

  • Como Scott Alexander apontou, o importante é o fenômeno em que agentes interagem entre si e produzem comportamentos compostos
    Se isso começar a afetar o mundo real, pode levar a questões ontológicas.
    No fim, é uma estrutura em que “tudo o que está escrito como YES no AGENT.md” pode realmente acontecer

    • Também houve quem reagisse dizendo que não entendeu muito bem do que se tratava
    • Foi por isso que eu criei o nono.sh: para que o agente comece em sandbox com isolamento em nível de kernel e em modelo de ‘zero trust’
    • Humanos também são, até certo ponto, seres que ‘repetem como papagaios’. Assim como o Moltbook imita o Reddit, humanos também conversam dentro de padrões previsíveis. Talvez, no fim, sejamos menos inteligentes do que imaginamos

  • Como a API do Moltbook está aberta para qualquer um, dá para induzir com um prompt simples o vazamento de e-mails de usuários ou outros dados
    Por isso surgem tentativas de isolar tudo num Mac mini, mas, enquanto houver conexão de rede, proteção completa é impossível

    • Não é loucura. LLMs não conseguem distinguir com firmeza comandos de dados. É uma espécie de vulnerabilidade de ‘engenharia social’
    • No fim, a questão é se dá para mandar o sistema fazer algo útil sem risco. Por exemplo, se você quiser delegar compras de mercado ou reservas de viagem, ele vai precisar de acesso ao cartão de crédito
    • Eu uso LLMs isolados em um ambiente DMZ. Rodo com conta sem disco e sem privilégios de sudo. Não é perfeito, mas funciona razoavelmente
    • Na prática, não existe proteção perfeita. Porque estão presentes ao mesmo tempo o ‘trio fatal’: acesso a dados, texto não confiável e comunicação em rede
    • Ainda assim, dá para colocar uma camada de supervisão e aprovação. É possível criar uma estrutura que aprove ou limite as ações do LLM, como um limite de cartão de crédito

  • Testei o OpenClaw e o consumo de tokens é enorme
    Para segurança, parece que ajudaria usar hardware dedicado (como Raspberry Pi) com permissões de API limitadas. Se um Pi pudesse rodar modelos mais fortes, eu teria interesse em comprar

  • O Moltbook não tem como distinguir IA de humanos. A questão é como implementar um ‘CAPTCHA reverso’

    • Por diversão, dei ao Claude o prompt “tente encontrar contas de espiões humanos”, e ele realmente criou uma thread chamada ‘Reverse Turing Problem’. Mas agora está tomada por spam a ponto de ficar impossível conversar
    • É preciso um método que torne todas as entradas e saídas da sessão assináveis e auditáveis. Também deveria ser possível rastrear prompts injetados por humanos
    • Outra forma de diferenciar seria mandar várias vezes, em pouco tempo, tarefas que são fáceis para IA, mas difíceis para humanos
    • Ou então fazer rapidamente perguntas raras que um LLM provavelmente já saberia responder
    • Mas, no fim, continua difícil distinguir se um comportamento foi induzido por um humano via prompt

  • Dizem que corrigiram o problema de segurança do Moltbook em poucas horas, mas a questão é como explicar falhas de segurança em um projeto feito com ‘vibe coding’

    • De fato, o Claude gerou uma query para o Supabase, e uma pessoa repassou isso ao desenvolvedor do Moltbook para corrigir. Parece difícil de acreditar, mas foi isso mesmo

  • É surpreendente que haja gente analisando o interior do Moltbook. Desde o começo era um ‘projeto feito de brincadeira’, e ninguém imaginava que ficaria tão grande

    • Mas, se houver exposição de PII de usuários, isso deixa de ser brincadeira e vira um problema jurídico. A cultura de ‘vibe coding’ está criando um ambiente de desenvolvimento sem responsabilidade
    • Dogecoin também começou como piada, mas hoje vale bilhões de dólares
    • Pesquisadores de segurança procurando vulnerabilidades também podem ser, no fim, parte desse mesmo ‘vibe’
    • Mas não dá para encobrir danos reais com a desculpa de que “era brincadeira”
    • Se o resultado foi criado intencionalmente pelos autores, a desculpa de que era “piada” perde força

  • O caso em que uma instância do OpenClaw enviou uma chave da OpenAI para outra instância foi engraçado e ao mesmo tempo preocupante.
    Não está claro se a chave foi realmente enviada ou se ele só fingiu que fez isso

  • O próprio artigo da Wiz parece ter sido escrito por IA. A estrutura das frases e o uso de travessões têm aquele estilo típico de LLM.
    É irônico criticar a segurança de uma plataforma criada por LLM com um artigo escrito por LLM.
    A vulnerabilidade em si provavelmente é real, mas, se tivesse sido escrito por um humano, parece que haveria menos enfeite desnecessário

  • Os dados expostos revelaram que, dos 1,5 milhão de agentes, só 17 mil eram humanos
    Mas, como esse número foi obtido pelo pesquisador consultando tabelas diretamente com a chave de API, divulgar isso parece mais um ato de crítica à empresa do que um simples bug report
    Esse tipo de conduta pode acabar prejudicando a relação de confiança e cooperação entre pesquisadores e empresas