Falha de configuração no Supabase expõe dados sensíveis e APIs do Moltbook
Uma grave falha de configuração na infraestrutura do Moltbook, uma rede social voltada para agentes de IA, deixou todo o banco de dados da plataforma exposto na internet. O problema estava ligado ao uso incorreto do Supabase, serviço de backend como serviço (BaaS), e permitiu tanto leitura quanto escrita sem qualquer autenticação, oferecendo a qualquer pessoa acesso administrativo completo às informações armazenadas.
O incidente resultou na exposição de aproximadamente 1,5 milhão de chaves de API de autenticação, 35 mil endereços de e-mail de usuários e um volume significativo de mensagens privadas trocadas dentro da plataforma. Em outras palavras, além de dados cadastrais e de acesso, informações sensíveis de conversas e integrações de terceiros ficaram temporariamente abertas a exploração.
A investigação mostrou que as credenciais de conexão com o banco de dados Supabase estavam embutidas diretamente no código JavaScript do lado do cliente. Isso significa que, ao inspecionar o código carregado pelo navegador, qualquer usuário poderia visualizar chaves e segredos que normalmente deveriam permanecer protegidos no ambiente de servidor. Com essas credenciais, era possível se conectar ao banco de dados com privilégios administrativos, sem necessidade de login ou qualquer tipo de verificação de identidade.
Outro ponto crítico foi a ausência de políticas de Row Level Security (RLS) no Supabase. O RLS é um mecanismo essencial de proteção que restringe o acesso às linhas de uma tabela com base na identidade do usuário ou em regras específicas. Sem esse recurso ativado, o banco operava praticamente como uma grande planilha pública para quem tivesse as credenciais expostas. A combinação de credenciais administrativas no front-end e falta de RLS criou um cenário de risco extremo.
Entre os dados expostos, estava a tabela de agentes, que continha tokens capazes de permitir a tomada completa de qualquer conta associada a esses agentes de IA. Também foi comprometida a tabela de proprietários, com e-mails, identificadores e outros metadados de usuários humanos que administram ou interagem com os agentes. Em termos práticos, isso abria margem para sequestro de contas, fraudes, engenharia social e ataques direcionados.
As mensagens privadas trocadas dentro do Moltbook também ficaram acessíveis. O conteúdo incluía, em alguns casos, chaves de API de serviços de terceiros, como provedores de IA generativa. Isso multiplica o impacto, pois a falha não se limitava à plataforma em si, mas potencialmente atingia integrações externas conectadas a esses agentes. Com acesso às chaves, um invasor poderia consumir serviços pagos, executar ações em nome do usuário ou vazar ainda mais dados em outros ambientes.
Mais grave ainda, a permissão de escrita no banco permitia que qualquer pessoa editasse ou apagasse postagens, alterasse conteúdos existentes e até inserisse informações maliciosas. Isso possibilitaria manipulação de dados, desinformação dentro da comunidade de usuários e comprometimento da confiabilidade de todo o ecossistema da plataforma. Em um ambiente orientado a agentes de IA, a adulteração de dados de treinamento, prompts e respostas poderia causar efeitos em cadeia e resultados imprevisíveis.
De acordo com um analista de segurança que acompanha o caso, a vulnerabilidade atinge o nível máximo de criticidade. Segundo ele, o cenário habilita, em algumas condições, até mesmo a execução remota de código, já que a combinação de acesso amplo ao banco e controle sobre conteúdos pode ser explorada para implantar cargas maliciosas indiretamente por meio de integrações e automações. Por isso, o problema foi classificado como de prioridade absoluta de correção.
O time responsável pelo Moltbook foi notificado e iniciou uma correção em etapas. Primeiro, foram restringidas as permissões de leitura, bloqueando o acesso público às tabelas mais sensíveis. Em seguida, o acesso de escrita foi limitado, estabelecendo novas regras de autorização no Supabase. Embora os detalhes técnicos da mitigação não tenham sido totalmente divulgados, é provável que o processo tenha incluído a regeneração de chaves, ativação de políticas de RLS e revisão do código para remover credenciais do lado do cliente.
Esse caso ilustra de forma contundente um erro ainda comum em aplicações modernas: tratar serviços de backend gerenciados, como Supabase, Firebase ou similares, como se fossem bancos de dados privados, quando na prática eles expõem endpoints acessíveis pela internet e exigem configuração cuidadosa de segurança. Ao colocar chaves de administração em código front-end, a aplicação perde imediatamente o princípio básico de separação entre cliente e servidor.
Outro ponto que merece destaque é a falsa sensação de segurança em ambientes Cloud e SaaS. Muitos times acreditam que, por estarem usando uma plataforma gerenciada, backups, redundância e proteção de dados são “automáticos” e suficientes. Na prática, a responsabilidade pela configuração correta de permissões, regras de segurança e manuseio de credenciais continua sendo do time de desenvolvimento e de segurança da empresa. Um erro de configuração, como o que ocorreu no Moltbook, pode anular grande parte dos controles nativos do provedor.
Para os usuários, o incidente levanta preocupações importantes. Com e-mails, tokens e mensagens privadas expostos, existe risco de phishing, ataques direcionados e uso indevido de chaves de API. Quem utilizou a plataforma para integrar agentes de IA com contas em outros serviços deve considerar a revogação de chaves, redefinição de senhas e monitoramento de atividades suspeitas. Também é prudente evitar compartilhar segredos, credenciais ou informações sensíveis em campos de texto que podem ser armazenados sem criptografia robusta.
Do ponto de vista das empresas que constroem produtos baseados em IA, a falha serve como alerta para a necessidade de incorporar segurança desde o desenho da arquitetura. Plataformas que gerenciam agentes de IA normalmente tratam de dados de usuários finais, prompts privados, documentos confidenciais e integrações com ferramentas de negócios. Qualquer descuido em autorização, segmentação de dados ou controle de acesso pode dar a um invasor uma visão privilegiada sobre a operação e os dados corporativos.
Há, ainda, uma lição relevante sobre o uso correto do Supabase. Entre as boas práticas recomendadas estão: nunca expor chaves de serviço ou administrativas em código cliente; separar rigorosamente credenciais públicas (limitadas) de credenciais privadas; ativar e testar políticas de Row Level Security em todas as tabelas que armazenem dados de usuários; revisar periodicamente permissões de leitura e escrita; e implementar camadas adicionais de API intermediária, quando necessário, para abstrair o acesso direto ao banco.
O caso também reforça a importância de testes de segurança contínuos, como pentests, análise de código e revisões de configuração específicas para ambientes em nuvem. Em aplicações que crescem rapidamente, é comum que protótipos e configurações temporárias nunca sejam endurecidas antes de ganhar escala. Isso cria “dívidas de segurança” que só aparecem quando uma falha é explorada – muitas vezes tarde demais, depois que dados já foram exfiltrados.
Por fim, o episódio do Moltbook evidencia uma tendência que deve se acentuar: quanto mais as empresas dependem de agentes de IA e plataformas de automação, maior o potencial de impacto de falhas de segurança. Quando um agente comprometido tem acesso a e-mails, documentos internos, sistemas corporativos ou APIs críticas, o estrago vai muito além do vazamento de dados básicos. Proteger essas plataformas com rigor, desde a camada de backend até a forma como os usuários interagem com elas, deixa de ser um diferencial e passa a ser uma exigência mínima para operar com responsabilidade no ecossistema de IA.