Pular para o conteúdo

Exposição de banco de dados da Moltbook revela milhões de chaves de API

No início de fevereiro de 2026, pesquisadores de segurança da empresa Wiz revelaram uma série de vulnerabilidades críticas no Moltbook, uma plataforma que se apresentava como a primeira rede social exclusiva para agentes de inteligência artificial. A descoberta expôs não apenas falhas técnicas significativas, mas também levantou questões fundamentais sobre a natureza real dessas “redes de agentes” e os riscos associados ao desenvolvimento acelerado de aplicações com assistência de inteligência artificial.

O Moltbook havia conquistado atenção significativa na comunidade de tecnologia ao se posicionar como a “primeira página da internet dos agentes”. A plataforma funcionava de maneira similar ao Reddit, permitindo que agentes de IA publicassem conteúdo, comentassem em postagens de outros agentes, votassem e construíssem reputação através de um sistema de pontos chamado karma. A proposta era ambiciosa: criar um espaço onde inteligências artificiais pudessem interagir entre si de forma autônoma, discutindo tópicos variados e até mesmo desenvolvendo formas de comunicação privada entre agentes.

A plataforma ganhou visibilidade internacional quando Andrej Karpathy, um dos membros fundadores da OpenAI e figura proeminente no campo de aprendizado profundo, descreveu o Moltbook como “genuinamente a coisa mais incrível adjacente a ficção científica que vi recentemente”. Karpathy destacou como os agentes pareciam estar se auto-organizando em um site similar ao Reddit, discutindo diversos tópicos e até mesmo explorando formas de comunicação privada. Esse endosso de uma figura tão respeitada contribuiu para que a plataforma atraísse ainda mais atenção e usuários.

O fundador do Moltbook havia declarado publicamente que desenvolveu toda a plataforma utilizando uma abordagem conhecida como “vibe coding”, na qual o desenvolvedor descreve sua visão e permite que ferramentas de inteligência artificial gerem o código necessário. Em suas próprias palavras: “Não escrevi uma única linha de código para o Moltbook. Apenas tive uma visão para a arquitetura técnica, e a IA tornou isso realidade.” Essa metodologia representa uma mudança de paradigma no desenvolvimento de software, permitindo que pessoas com ideias inovadoras mas conhecimento técnico limitado consigam criar produtos funcionais em tempo recorde.

No entanto, a pesquisa conduzida pela equipe da Wiz revelou que essa velocidade de desenvolvimento veio acompanhada de lacunas significativas de segurança. Os pesquisadores, liderados por Gal Nagli, identificaram um banco de dados Supabase mal configurado que permitia acesso completo de leitura e escrita a todos os dados da plataforma sem qualquer autenticação. O Supabase é uma alternativa de código aberto ao Firebase do Google, oferecendo bancos de dados PostgreSQL hospedados com interfaces de programação REST. A ferramenta tornou-se especialmente popular entre desenvolvedores que utilizam vibe coding devido à sua facilidade de configuração inicial.

A descoberta foi feita através de um procedimento relativamente simples de análise de segurança. Ao navegar pelo site do Moltbook, os pesquisadores examinaram os arquivos JavaScript carregados automaticamente pelo navegador. Aplicações web modernas agrupam valores de configuração em arquivos JavaScript estáticos, o que pode inadvertidamente expor credenciais sensíveis. Este é um padrão recorrente que a equipe da Wiz tem observado em aplicações desenvolvidas com vibe coding, onde chaves de API e segredos frequentemente acabam no código do frontend, visíveis para qualquer pessoa que inspecione o código fonte da página.

No arquivo JavaScript de produção localizado em uma URL específica do site, os pesquisadores identificaram credenciais de conexão do Supabase codificadas diretamente no código. Embora a exposição dessas credenciais não constitua automaticamente uma falha de segurança, já que o Supabase foi projetado para operar com certas chaves expostas ao cliente, o verdadeiro perigo reside na configuração do backend para o qual essas chaves apontam. Quando configurado adequadamente com Row Level Security (RLS), a chave pública do Supabase funciona como um identificador de projeto e é segura para exposição. Sem políticas de RLS, contudo, essa mesma chave concede acesso completo ao banco de dados para qualquer pessoa que a possua. Na implementação do Moltbook, essa linha crítica de defesa estava completamente ausente.

Utilizando a chave de API descoberta, os pesquisadores testaram se as medidas de segurança recomendadas estavam implementadas. Tentaram consultar a API REST diretamente, uma requisição que deveria retornar um array vazio ou um erro de autorização caso o RLS estivesse ativo. Em vez disso, o banco de dados respondeu exatamente como se eles fossem administradores do sistema, retornando imediatamente tokens de autenticação sensíveis, incluindo as chaves de API dos agentes mais populares da plataforma. Isso confirmou acesso não autenticado a credenciais de usuários que permitiriam a personificação completa de qualquer conta na plataforma.

A extensão da exposição foi mapeada através de técnicas de enumeração do banco de dados utilizando mensagens de erro do PostgREST e introspecção GraphQL. Os pesquisadores descobriram aproximadamente 4,75 milhões de registros expostos distribuídos em diversas tabelas. Os dados incluíam a tabela de agentes com credenciais de autenticação para cada agente registrado no banco de dados. Cada registro de agente continha a chave de API completa que permitia controle total da conta, um token de reivindicação usado para assumir propriedade de um agente, um código de verificação usado durante o registro do agente, além de informações sobre karma e número de seguidores.

Com essas credenciais, um atacante poderia personificar completamente qualquer agente na plataforma, publicando conteúdo, enviando mensagens e interagindo como aquele agente. Isso incluía contas com alto karma e agentes persona conhecidos. Efetivamente, cada conta no Moltbook poderia ser sequestrada com uma única chamada de API.

A tabela de proprietários continha informações pessoais de mais de 17 mil usuários, incluindo endereços de e-mail que deveriam permanecer privados. Diferentemente dos identificadores do Twitter que eram exibidos publicamente nos perfis, os endereços de e-mail foram completamente expostos no banco de dados. Adicionalmente, ao consultar o endpoint GraphQL, os pesquisadores descobriram uma tabela adicional chamada “observers” contendo 29.631 endereços de e-mail adicionais. Esses eram cadastros de acesso antecipado para um novo produto do Moltbook voltado para desenvolvedores de aplicativos para agentes de IA.

A tabela de mensagens entre agentes expôs 4.060 conversas privadas de mensagens diretas entre agentes. Ao examinar essa tabela para entender as interações entre agentes, os pesquisadores descobriram que as conversas eram armazenadas sem qualquer criptografia ou controle de acesso. Mais preocupante ainda, algumas conversas continham credenciais de serviços de terceiros, incluindo chaves de API da OpenAI compartilhadas em texto simples entre agentes. Isso significa que uma única falha de configuração em uma plataforma foi suficiente para expor credenciais de serviços completamente não relacionados, demonstrando o quão interconectados os sistemas modernos de IA se tornaram.

Além do acesso de leitura, os pesquisadores confirmaram capacidades completas de escrita no banco de dados. Mesmo após uma correção inicial que bloqueou o acesso de leitura a tabelas sensíveis, o acesso de escrita a tabelas públicas permaneceu aberto. Os pesquisadores testaram essa capacidade e conseguiram modificar postagens existentes na plataforma com sucesso, alterando o título e conteúdo de uma postagem para demonstrar a vulnerabilidade de forma responsável.

Essa capacidade de escrita significava que qualquer usuário não autenticado poderia editar qualquer postagem na plataforma, injetar conteúdo malicioso ou cargas de injeção de prompt, desfigurar todo o website, ou manipular conteúdo consumido por milhares de agentes de IA. Isso levanta questões sérias sobre a integridade de todo o conteúdo da plataforma, incluindo postagens, votos e pontuações de karma, durante a janela de exposição.

Talvez a descoberta mais reveladora tenha sido a proporção real entre agentes e humanos na plataforma. Enquanto o Moltbook ostentava 1,5 milhão de agentes registrados, o banco de dados revelou apenas 17 mil proprietários humanos por trás deles, uma proporção de 88 agentes para cada pessoa. A plataforma não tinha nenhum mecanismo para verificar se um “agente” era realmente uma IA ou apenas um humano com um script. Qualquer pessoa poderia registrar milhões de agentes com um simples loop de programação e sem limitação de taxa. A revolucionária rede social de IA era em grande parte humanos operando frotas de bots.

Essa descoberta não representa necessariamente uma falha intencional, mas reflete o quão inicial ainda é a categoria de “internet de agentes”. Os construtores dessas plataformas estão ativamente explorando como identidade de agente, participação e autenticidade devem funcionar, e os mecanismos de suporte ainda estão evoluindo. No entanto, isso demonstra como métricas de participação podem ser facilmente infladas sem proteções adequadas como limites de taxa ou verificação de identidade.

A equipe do Moltbook respondeu de forma exemplar após ser notificada. O contato inicial foi feito em 31 de janeiro de 2026 às 21:48 UTC através de mensagem direta no X (antigo Twitter). Apenas 18 minutos depois, às 22:06 UTC, os pesquisadores reportaram a configuração incorreta do RLS do Supabase expondo a tabela de agentes com chaves de API e e-mails. A primeira correção veio às 23:29 UTC, protegendo as tabelas de agentes, proprietários e administradores do site.

No entanto, a segurança raramente é uma correção única, especialmente em produtos de IA de rápida evolução. Os pesquisadores trabalharam com a equipe através de múltiplas rodadas de remediação. Uma segunda correção às 00:13 UTC do dia seguinte protegeu as tabelas de mensagens de agentes, notificações, votos e seguidores. Às 00:31 UTC, os pesquisadores descobriram a vulnerabilidade de acesso de escrita POST, que foi corrigida às 00:44 UTC. Às 00:50 UTC, tabelas adicionais expostas foram descobertas, incluindo a tabela de observadores com 29 mil e-mails, verificações de identidade e aplicativos de desenvolvedores. A correção final veio às 01:00 UTC, com todas as tabelas protegidas e a vulnerabilidade completamente corrigida.

Esse tipo de endurecimento iterativo é comum em novas plataformas e reflete como a maturidade de segurança se desenvolve ao longo do tempo. Cada iteração revelou superfícies adicionais expostas, desde tabelas sensíveis até acesso de escrita e recursos descobertos via GraphQL.

O caso do Moltbook oferece cinco lições fundamentais para o desenvolvimento de aplicações com IA. A primeira é que velocidade sem padrões seguros cria risco sistêmico. O vibe coding desbloqueia velocidade e criatividade notáveis, permitindo que fundadores lancem produtos reais com velocidade sem precedentes. Ao mesmo tempo, as ferramentas de IA atuais ainda não raciocinam sobre postura de segurança ou controles de acesso em nome do desenvolvedor, o que significa que detalhes de configuração ainda se beneficiam de revisão humana cuidadosa. Neste caso, o problema remontou a uma única configuração do Supabase, um lembrete de como pequenos detalhes podem importar em escala.

A segunda lição é que métricas de participação precisam de verificação e proteções. A proporção de 88:1 entre agentes e humanos mostra como métricas de “internet de agentes” podem ser facilmente infladas sem proteções como limites de taxa ou verificação de identidade. Enquanto o Moltbook reportava 1,5 milhão de agentes, estes estavam associados a aproximadamente 17 mil contas humanas. No momento da revisão, havia proteções limitadas como limitação de taxa ou validação de autonomia de agentes.

A terceira lição envolve como falhas de privacidade podem cascatear através de ecossistemas de IA. Usuários compartilharam chaves de API da OpenAI e outras credenciais em mensagens diretas sob a suposição de privacidade, mas um problema de configuração tornou essas mensagens publicamente acessíveis. Uma única má configuração de plataforma foi suficiente para expor credenciais de serviços completamente não relacionados, sublinhando quão interconectados os sistemas modernos de IA se tornaram.

A quarta lição é que acesso de escrita introduz riscos muito maiores que exposição de dados sozinha. Enquanto vazamentos de dados são ruins, a capacidade de modificar conteúdo e injetar prompts em um ecossistema de IA introduz riscos de integridade mais profundos, incluindo manipulação de conteúdo, controle de narrativa e injeção de prompts que podem se propagar downstream para outros agentes de IA. À medida que plataformas orientadas por IA crescem, essas distinções se tornam considerações de design cada vez mais importantes.

A quinta e última lição é que maturidade de segurança é um processo iterativo. Segurança, especialmente em produtos de IA de rápida evolução, raramente é uma correção única. Os pesquisadores trabalharam com a equipe através de múltiplas rodadas de remediação, com cada iteração revelando superfícies expostas adicionais.

O pesquisador de segurança Jameson O’Reilly também descobriu independentemente a configuração incorreta do Supabase, conforme reportado pelo 404 Media. A publicação da Wiz compartilha a experiência da equipe ao encontrar o problema independentemente, o escopo completo do impacto que não havia sido reportado anteriormente, e como trabalharam com o mantenedor do Moltbook para melhorar a segurança.

À medida que a inteligência artificial continua a reduzir a barreira para construir software, mais criadores com ideias ousadas mas experiência limitada em segurança lançarão aplicações que lidam com usuários e dados reais. Essa é uma mudança poderosa. O desafio é que enquanto a barreira para construir caiu dramaticamente, a barreira para construir de forma segura ainda não acompanhou esse ritmo.

A oportunidade, conforme destacam os pesquisadores, não é desacelerar o vibe coding, mas elevá-lo. Segurança precisa se tornar uma parte integrada e de primeira classe do desenvolvimento assistido por IA. Assistentes de IA que geram backends Supabase podem habilitar RLS por padrão. Plataformas de implantação podem escanear proativamente credenciais expostas e configurações inseguras. Da mesma forma que a IA agora automatiza a geração de código, ela também pode automatizar padrões seguros e proteções.

Se essa integração for feita corretamente, o vibe coding não apenas tornará o software mais fácil de construir, mas fará com que software seguro seja o resultado natural, desbloqueando todo o potencial da inovação impulsionada por inteligência artificial.

Referências

Generativa Racionalista

Generativa Racionalista