Vazamento na API da Lovable expõe código, credenciais e conversas de usuários em falha BOLA grave
Uma vulnerabilidade crítica na Lovable, plataforma de desenvolvimento assistido por IA, expôs informações altamente sensíveis de usuários: códigos-fonte, credenciais embutidas em projetos e históricos completos de chats. Mais do que o problema técnico em si, o caso chamou atenção pela forma como a empresa reagiu inicialmente, negando tratar-se de um vazamento e classificando o comportamento da aplicação como algo “intencional” e previsto no design do produto.
A falha foi detectada por um pesquisador independente, que demonstrou ser possível, a partir de uma conta gratuita comum, acessar dados de outros clientes sem qualquer técnica avançada de ataque. Bastava realizar algumas chamadas à API da plataforma para alcançar perfis de terceiros, projetos marcados como públicos e, em muitos casos, encontrar credenciais de banco de dados e outros segredos diretamente no código.
Esse tipo de vulnerabilidade é conhecido como BOLA (Broken Object Level Authorization), ou falha de autorização em nível de objeto. Em termos simples, isso significa que a aplicação não valida corretamente se o usuário que faz a requisição realmente tem permissão para acessar o recurso solicitado. Em ambientes baseados em APIs, esse é um dos problemas mais graves, pois abre a porta para acessos horizontais e verticais a dados de qualquer cliente com pouco esforço.
Na prática, o fluxo de ataque descrito era extremamente direto. O invasor criava uma conta padrão na Lovable, sem qualquer privilégio especial. Em seguida, utilizava chamadas diretas à API, explorando endpoints que não verificavam de forma adequada a propriedade dos recursos. Assim, conseguia navegar entre projetos de outros usuários, visualizar históricos de interações com a IA e extrair informações sensíveis armazenadas no código, incluindo credenciais e dados relacionados a clientes ou infraestrutura. A ausência de etapas complexas de exploração torna o cenário ainda mais preocupante, pois reduz drasticamente a barreira de entrada para abusos em larga escala.
Em um primeiro momento, a Lovable tentou enquadrar o ocorrido como um comportamento esperado do sistema. A empresa afirmou que não havia violação de dados, alegando que projetos definidos como “públicos” eram, por padrão, amplamente acessíveis, e que o problema estaria na forma como essa configuração foi compreendida pelos usuários. Essa explicação, porém, não se sustentou diante do fato de que muitos não tinham clareza de que não apenas o código, mas também chats e outros artefatos sensíveis poderiam ser vistos por terceiros nesses contextos.
Com a reação negativa de clientes e da comunidade de segurança, a empresa reviu sua posição e reconheceu falhas no processo. Um dos pontos mais graves revelados foi uma mudança implementada em fevereiro de 2026: durante um esforço interno de unificação de permissões no backend, uma alteração reativou, sem intenção, o acesso a históricos de chat em projetos públicos. Essa modificação acabou ressuscitando uma vulnerabilidade que já havia sido tratada anteriormente, evidenciando fragilidades no controle de mudanças, na revisão de código e nos testes de segurança antes de colocar alterações em produção.
Outro aspecto sensível diz respeito ao caminho percorrido pelo reporte original da falha. O pesquisador informou que tinha comunicado o problema com antecedência por meio de um programa de recompensas por bugs. O relatório, contudo, foi classificado como duplicado e tratado sob a premissa de que o comportamento descrito era esperado. A própria Lovable reconheceu, mais tarde, que o caso não chegou corretamente às equipes responsáveis, devido a essa avaliação equivocada no processo de triagem, o que retardou a correção e prolongou a janela de exposição dos dados.
Sob a ótica de segurança, o incidente expõe um padrão cada vez mais comum em plataformas que combinam IA, colaboração em tempo real e APIs complexas. A pressa para lançar funcionalidades, somada a modelos de permissão sofisticados e a decisões de produto voltadas principalmente para reduzir fricção na experiência do usuário, cria um cenário propício para falhas de autorização passarem despercebidas. Em um ambiente onde convivem código proprietário, dados corporativos e conversas estratégicas com assistentes de IA, qualquer brecha de controle de acesso pode comprometer propriedade intelectual, informações confidenciais de negócios e dados pessoais em escala.
O caso também evidencia os riscos de delegar parte relevante do processo de descoberta de vulnerabilidades a terceiros sem garantir um fluxo de governança robusto. Programas de bug bounty são ferramentas importantes, mas não substituem um ciclo maduro de resposta a incidentes. Quando relatórios são mal avaliados, marcados como duplicados ou “comportamento esperado” sem análise profunda, toda a cadeia de proteção se torna frágil. A governança em torno da recepção, priorização, validação e escalonamento de vulnerabilidades passa a ser tão estratégica quanto o patch que corrige o problema técnico.
Empresas de grande porte que utilizam a Lovable, como Uber, Zendesk e Deutsche Telekom, acabam automaticamente envolvidas em um risco indireto. A exposição de trechos de código, chaves de acesso e credenciais internas dentro de projetos hospedados na plataforma abre espaço para ataques em cadeia, capazes de se propagar para ambientes mais amplos, como infraestruturas em nuvem, bancos de dados corporativos e outros serviços integrados. Nesses casos, o impacto deixa de ser um simples incidente de uma aplicação isolada e passa a se configurar como um problema de segurança que atinge todo um ecossistema de fornecedores e parceiros.
Do ponto de vista das organizações que utilizam ferramentas como a Lovable, o episódio reforça a necessidade de revisar a forma como código e segredos são gerenciados. Armazenar credenciais, tokens de API, chaves de banco de dados ou segredos de produção diretamente no código é uma prática que amplifica qualquer falha de autorização. Sempre que possível, esses dados devem ser isolados em cofres de segredo, variáveis de ambiente ou serviços dedicados, com políticas rígidas de acesso e rotação periódica.
Outro aprendizado importante é a necessidade de revisar de forma criteriosa as configurações de visibilidade de projetos e interações. O rótulo “público” costuma ser interpretado por usuários como algo restrito ao compartilhamento de código, mas em plataformas de IA pode incluir também histórico de prompts, respostas da IA, arquivos anexados e metadados. Empresas e desenvolvedores precisam tratar qualquer recurso marcado como público como se fosse, de fato, acessível ao mundo inteiro, evitando expor ali conversas, dados de clientes ou artefatos que contenham informações estratégicas.
Para os times de desenvolvimento da própria Lovable e de outras plataformas semelhantes, o incidente mostra a importância de incorporar testes de autorização em nível de objeto como requisito mínimo de qualidade. Isso inclui, por exemplo, verificar sistematicamente se um usuário consegue acessar apenas seus próprios recursos quando altera identificadores em chamadas à API, bem como realizar testes de regressão de segurança sempre que houver refatorações de permissões, migrações de backend ou unificações de modelos de acesso.
Também se torna fundamental aproximar as áreas de produto, engenharia e segurança. Decisões como tornar determinado tipo de projeto público por padrão, simplificar fluxos de compartilhamento ou oferecer recursos de colaboração instantânea precisam ser acompanhadas por uma análise de risco consistente. Muitas vezes, uma pequena conveniência na experiência de uso implica mudanças profundas na superfície de ataque, exigindo controles adicionais de monitoramento, auditoria e revogação de acesso.
Do lado da resposta a incidentes, a forma como a comunicação é conduzida impacta diretamente a confiança do mercado. Negar inicialmente a gravidade do problema ou tentar enquadrá-lo como um “comportamento esperado” costuma gerar mais desgaste do que admitir o erro, explicar a causa raiz e detalhar as medidas de correção e compensação adotadas. Transparência, prazos claros e atualizações frequentes tendem a reduzir o dano reputacional e a demonstrar compromisso real com a segurança.
Para os profissionais de segurança e líderes de tecnologia, o caso Lovable serve como alerta para uma prioridade concreta: revisar integrações com plataformas de IA e ferramentas de desenvolvimento hospedadas por terceiros. Isso inclui mapear quais dados são enviados, que tipo de código é mantido nesses ambientes, que permissões são concedidas a serviços externos e quais logs ou trilhas de auditoria estão disponíveis em caso de investigação de incidentes.
Por fim, o episódio reforça uma mensagem que o setor de segurança repete há anos: falhas de autorização continuam entre as ameaças mais negligenciadas em aplicações modernas, apesar de estarem entre as mais destrutivas quando exploradas. Em plataformas impulsionadas por IA, onde o valor está diretamente ligado à qualidade e à sensibilidade dos dados processados, ignorar controles robustos de autorização já não é apenas um risco técnico – é um risco estratégico para o negócio como um todo.