Os CVEs do vibe coding não são argumento contra IA — são contra ler menos quando importa mais

A Lovable embarcou, em 170 aplicações em produção, um controle de acesso invertido: usuário autenticado batia no muro; qualquer um sem login passava direto. O bug virou CVE-2025-48757. A IA implementou autenticação — e trocou o sinal da regra.

Esse é o tipo de falha que normalmente atribuímos a programador júnior cansado às quatro da tarde. Aqui veio de um pipeline em que ninguém leu o diff antes de aceitar.

Os três incidentes que vamos olhar — Lovable, Moltbook, e o estudo do grupo Tenzai — não são argumento contra usar IA para programar. São argumento contra fazer vibe coding no código que vira passivo legal quando dá errado: autenticação, autorização, e segredos.

Lovable: a RLS de cabeça para baixo

CVE-2025-48757. Cento e setenta apps em produção, todos com o mesmo padrão: as políticas de Row Level Security do Supabase configuradas no sentido contrário do pretendido. Quem estava logado via menos do que devia ver. Quem não estava logado via tudo.

O detalhe que importa: o código parecia certo. A IA tinha gerado as policies, tinha incluído cláusulas de checagem, tinha estruturado os blocos de SQL como manda o manual. Faltou apenas o sentido da comparação. auth.uid() != owner_id onde deveria ser =. Um caractere de diferença. Cento e setenta apps vivendo essa diferença em produção.

A leitura honesta: o diff de uma política de RLS cabe em vinte linhas. Não é território de "deixar o modelo levar". É território onde a pessoa que aceita o pull request tem obrigação de rodar o teste óbvio — logar como usuário A, tentar ler dado de usuário B, ver o que acontece. Esse teste não foi feito 170 vezes seguidas porque o fluxo nunca pediu por ele.

Moltbook: três dias entre o lançamento e o vazamento

A Moltbook era uma rede social vibe-coded. Subiu, recebeu usuários, e três dias depois um pesquisador conseguiu puxar 1,5 milhão de tokens de API e 35 mil emails de uma só vez. A causa: Row Level Security do Supabase não configurada — não invertida como na Lovable, simplesmente ausente.

A IA, ao gerar a camada de dados, criou tabelas funcionais e endpoints que respondiam corretamente. O que faltou foi a etapa em que alguém pergunta: "esse endpoint, sem autenticação, deveria devolver o quê?" A resposta default do Supabase, sem RLS, é tudo. E tudo é o que saiu.

Três dias é um tempo curto até para padrões de segurança permissivos. Mostra a forma da falha: não é que a IA escreveu código vulnerável que ninguém viu antes do deploy. É que a IA não escreveu o código de proteção, e ninguém perguntou onde ele estava.

Tenzai: 69 falhas em 15 apps

O estudo do grupo Tenzai (dezembro de 2025) é o mais útil para entender padrão de classe. Pegaram 15 apps de produção construídos com cinco ferramentas diferentes de coding com IA. Auditaram. Encontraram 69 vulnerabilidades.

Os dois números que saltam: 100% dos apps sem proteção contra CSRF e sem os headers básicos de segurança HTTP. 100% com vetor de SSRF explorável. Não é uma ferramenta específica falhando — é o que cinco ferramentas, independentemente, não geram a menos que peçam.

A categoria importa. CSRF, headers, SSRF — são exatamente o tipo de proteção que entra em listas de checagem, em middlewares de framework, em configurações de boilerplate. É código defensivo de fronteira. O modelo gera o que foi pedido (a feature) e não gera o que não foi pedido (a defesa). Quem aceita o diff sem ler a configuração do servidor não vê o que está faltando — vê só o que foi entregue.

O padrão comum

Os três incidentes compartilham geografia: código que toca a fronteira entre o aplicativo e o mundo. Autenticação, autorização, configuração de cabeçalhos, gestão de secrets.

Fora dessa fronteira — em script de ETL, em parser de planilha, em utilitário interno — o custo de aceitar um diff ruim é ter que reescrever. Dentro da fronteira, o custo é ter o nome da empresa em uma manchete sobre vazamento.

Não é uma questão de "IA não serve". A Lovable, a Moltbook e os 15 apps do Tenzai foram entregues em prazos que código artesanal não atingiria. O ganho de velocidade é real. O que esses três casos mostram é o tipo específico de código em que esse ganho não cobre o preço.

A regra de leitura

A heurística que funciona é geográfica, não tecnológica. Se o pull request toca auth/, users/, policies/, configuração de RLS, qualquer arquivo com secret ou token no nome, ou camada de middleware — leia. Linha por linha. Rode o teste óbvio (logar como A, tentar acessar B). Em qualquer outro lugar do repositório, vibe coding pode valer.

A diferença entre os três incidentes e os projetos que não viraram CVE provavelmente não é talento, ferramenta, ou modelo. É a pergunta feita antes de aceitar o diff: este código, se estiver errado, custa uma reescrita ou custa uma manchete? Quando a resposta é a segunda, a leitura deixa de ser opcional.