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, 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.