CVE-2025-48757 é uma vulnerabilidade da Lovable classificada como crítica (CVSS 9.3) que expôs mais de 170 aplicações. O problema: qualquer pessoa, sem iniciar sessão, conseguia ler —e, em muitos casos, modificar— dados na tua base de dados: nomes, emails, chaves de API de terceiros, até o estado dos pagamentos. A causa de fundo não é um bug escondido da Lovable, mas sim um padrão partilhado por quase todas as aplicações "vibe-coded": confiar toda a segurança da base de dados às políticas de RLS do Supabase… e deixá-las incompletas.
O que realmente aconteceu
A Lovable cria aplicações em que o browser comunica diretamente com a base de dados (Supabase) através de chamadas REST, usando a chave pública anon. Esse é um design sólido desde que cada tabela tenha políticas de Row-Level Security (RLS) a decidir que linhas cada utilizador pode ler ou alterar. A vulnerabilidade surgiu porque muitos projetos foram lançados com tabelas que tinham RLS nenhuma ou insuficiente. Um atacante só tinha de editar o pedido REST —mudar um filtro no URL— para pedir "todas as linhas" de uma tabela que devia estar protegida.
Foi reportada em março de 2025 por Matt Palmer e Kody Low, e de forma independente por Danial Asaria, com divulgação pública a 29 de maio de 2025 (análise técnica, registo do CVE). Qualquer projeto Lovable que use uma base de dados criada a 15 de abril de 2025 ou antes pode estar afetado.
Porque é que te afeta mesmo que não uses a Lovable
Isto não é um problema exclusivo da Lovable. Qualquer aplicação que comunique com o Supabase diretamente a partir do browser —quer a tenhas construído com Bolt, v0, Cursor ou à mão— depende de a RLS estar correta em todas as tabelas. A aplicação parece perfeita, o início de sessão funciona, mas a segurança real vive na base de dados, não na interface. Esconder um botão no frontend não protege nada: o pedido REST continua lá, ao alcance de quem souber onde olhar.
Como saber se a tua aplicação é vulnerável
- Abre as DevTools (F12) → separador Network enquanto usas a tua aplicação e observa as chamadas a
*.supabase.co/rest/v1/. Copia um desses URLs, abre-o numa janela anónima (sem sessão) e vê se devolve dados. - Tenta pedir a mais: se uma chamada devolve os teus dados, remove o filtro do URL. Se te devolver as linhas de outros utilizadores, a tua RLS não é eficaz.
- Verifica o painel do Supabase → Authentication → Policies. Qualquer tabela com dados reais que mostre "RLS disabled" ou sem qualquer política é uma porta aberta.
Como corrigi-lo
- Ativa a RLS em todas as tabelas, não apenas nas "importantes". A regra é negar por omissão: sem uma política que o permita, ninguém entra.
- Escreve políticas explícitas por operação (select/insert/update/delete) associadas a
auth.uid(), para que cada utilizador só toque nas suas próprias linhas. - Nunca uses a chave
service_roleno frontend: ela ignora completamente a RLS. Essa chave vive apenas no servidor. - Volta a testar com o passo da janela anónima acima: se o pedido sem sessão passar a devolver vazio ou um erro, estás no bom caminho.
Como a Scanaris o verifica
A Scanaris analisa o teu site em modo só de leitura e deteta a impressão digital deste padrão: endpoints do Supabase acessíveis a partir do browser, CORS permissivo, chaves e tokens expostos no teu JavaScript, e dados que a aplicação serve sem sessão. Cola o teu URL e ela diz-te, em segundos e ordenado por gravidade, o que está à vista de todos —antes que outra pessoa o encontre.