--- title: "Milhares de bancos de dados da Supabase aparecem expostos na internet segundo pesquisa" author: "Gabriela P. Torres" date: "2026-09-26 06:00:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/26/milhares-de-bancos-de-dados-da-supabase-aparecem-expostos-na-internet-segundo-pesquisa/md" --- ## Resumo - A UpGuard identificou 16.326 instâncias de bancos de dados de clientes da Supabase com tabelas legíveis publicamente. - A análise examinou cerca de 300.000 domínios e usou esquemas de bancos, sem acessar registros individuais. - Mais da metade das instâncias expostas continha indicadores de informações pessoalmente identificáveis. - Os casos incluíam nomes, endereços, telefones, senhas, tokens de autenticação e logs de um serviço de SIM virtual. - A pesquisa relacionou parte do problema ao código gerado por IA e à falta de configuração do Row Level Security. - Tabelas criadas programaticamente não ativam automaticamente o RLS, segundo as fontes consultadas. - A Supabase definiu 30 de outubro de 2026 como prazo para a correção das configurações em projetos existentes. --- Em 25 de setembro de 2026, a empresa de segurança cibernética **UpGuard** divulgou uma pesquisa que identificou **16.326 instâncias de bancos de dados de clientes da Supabase** com tabelas legíveis publicamente, depois de analisar cerca de 300.000 domínios. O achado importa porque mais da metade dessas instâncias continha indicadores de informações pessoalmente identificáveis, como nomes e endereços, enquanto alguns casos também incluíam números de telefone, senhas e tokens de autenticação. A pergunta correta, porém, não é "a Supabase vazou esses dados?", e sim "por que projetos de clientes ficaram acessíveis e quais configurações permitiram isso?". A resposta passa por políticas de segurança ausentes ou fracas, pelo uso de código gerado por IA e pelo prazo de correção anunciado para 30 de outubro de 2026. ## O número mede exposição, não vítimas O número não veio de uma inspeção indiscriminada do conteúdo. Na [descrição metodológica da UpGuard](https://runtimewire.com/article/supabase-upguard-exposed-databases-ai-apps), a **UpGuard** informou ter usado uma abordagem baseada em esquemas, ou "schema-based", que observa a estrutura das bases e sinais como tabelas chamadas "users", sem baixar ou acessar registros individuais. Em termos práticos, a equipe procurou indícios de exposição na forma como os bancos estavam organizados, e não uma cópia completa de cada tabela. Por isso, os **16.326** representam instâncias com tabelas legíveis publicamente; o número, por si só, não informa quantas pessoas foram afetadas nem quantos registros foram efetivamente extraídos. Essa distinção impede uma leitura apressada sobre a responsabilidade. As fontes descrevem projetos de clientes hospedados na **Supabase**, nos quais tabelas ficaram acessíveis por causa de políticas de segurança ausentes ou fracas, sem atribuir automaticamente essa configuração à própria plataforma. Bil Harmer, diretor de segurança da informação da Supabase, classificou a relação como um modelo de **responsabilidade compartilhada**: a empresa fornece ferramentas e padrões seguros, enquanto o cliente mantém o controle final sobre a configuração do projeto. A pergunta seguinte, portanto, é quais informações estavam nessas tabelas e por que o acesso público podia ser tão amplo. ## Que tipo de dado apareceu nas tabelas Os exemplos tornam o problema concreto. Entre os casos documentados aparecem dados de um **consulado africano na França** e informações de uma empresa de manobristas dos Estados Unidos, dois usos distintos que acabaram associados ao mesmo tipo de exposição pública. A pesquisa também encontrou logs de um serviço de SIM virtual ligado à interceptação de SMS, o que amplia a gravidade dos exemplos porque registros operacionais podem revelar como um serviço sensível foi utilizado. Em todos esses casos, o ponto comum apresentado pela pesquisa é a legibilidade pública das tabelas, não uma contagem consolidada de vítimas. O levantamento da **UpGuard** encontrou nomes, endereços e números de telefone entre os dados expostos, além de senhas e tokens de autenticação em menor escala. O relatório liderado por Greg Pollock, diretor de pesquisa da empresa, afirmou que mais da metade dos bancos identificados continha indicadores de **PII**, sigla em inglês para informações pessoalmente identificáveis. A palavra "indicadores" faz diferença: ela descreve sinais de que esse tipo de dado estava presente, sem transformar o levantamento em uma lista completa de cada campo exposto em todas as 16.326 instâncias. A dimensão do achado está, portanto, na repetição da configuração aberta em milhares de projetos e na variedade dos dados que os esquemas sugeriam. ## Onde entra o código gerado por inteligência artificial É na etapa de desenvolvimento que a pesquisa conecta o problema ao avanço das ferramentas de IA para geração de código. O relatório associou a exposição ao chamado **"vibe coding"**, prática em que agentes ou assistentes produzem partes de uma aplicação sem que o desenvolvedor necessariamente revise todas as configurações de segurança. Segundo a pesquisa, muitos desenvolvedores que usam IA não configuram corretamente o Row Level Security, ou **RLS**, conjunto de políticas que controla o acesso às linhas das tabelas. O estudo também descreveu a Supabase, avaliada em US$ 10 bilhões em junho de 2026, como um produto recomendado por ferramentas como o Claude Code, o que ajuda a explicar por que a discussão alcança aplicações construídas rapidamente. A cadeia técnica descrita pelas fontes é direta. Tabelas criadas programaticamente, uma rota comum para agentes de codificação por IA, não ativam automaticamente o **RLS**; se o usuário não configurar manualmente a permissão, a tabela pode permanecer exposta. A análise da UpGuard acrescenta outro ponto: chaves colocadas no código do lado do cliente, isto é, no código executado no lado do cliente, podem expor APIs de forma involuntária. Se a tabela é criada, a política não é aplicada e a chave fica acessível no lado do cliente, então a facilidade de colocar uma aplicação no ar vem acompanhada de uma configuração que precisa ser conferida separadamente. É o tipo de sequência em que o código funciona, mas a barreira de acesso não foi criada. ## Responsabilidade e prazo para corrigir os projetos A resposta da plataforma adotou a mesma separação de responsabilidades. Bil Harmer, **CISO da Supabase**, disse que a empresa não teve acesso prévio ao estudo da UpGuard, mas reiterou que a plataforma segue um modelo de responsabilidade compartilhada. De acordo com a declaração, a Supabase fornece ferramentas e padrões de segurança por padrão, chamados de "secure defaults", enquanto os clientes mantêm a decisão final sobre a forma como seus projetos são configurados. Harmer também afirmou que a empresa notifica clientes quando descobre falhas específicas, mas a declaração não transforma a configuração final em uma tarefa automática da plataforma. A consequência prática é que o diagnóstico precisa ser lido junto com a responsabilidade de quem criou e ajustou cada projeto. Depois da divulgação da pesquisa, a **Supabase estabeleceu 30 de outubro de 2026** como prazo para que desenvolvedores corrijam as configurações de segurança de projetos existentes. A medida coloca o RLS no centro da revisão: tabelas criadas por código precisam ter as permissões verificadas manualmente, e chaves ou APIs acessíveis no lado do cliente exigem a mesma inspeção. O próximo passo documentado é, portanto, revisar as políticas dos projetos já publicados antes do prazo, em vez de tratar a legibilidade pública como detalhe de desenvolvimento. Se a condição encontrada pela UpGuard foi uma tabela aberta, então a correção passa por fechar essa leitura para quem não deveria ter acesso; senão, o prazo anunciado não resolve a causa descrita pelas fontes.