Vulnerabilidade BOLA na API da Lovable, plataforma de desenvolvimento de aplicações assistido por IA, expôs código, credenciais e conversas com o modelo de quem usa o serviço.
"BOLA" significa Broken Object Level Authorization. É uma falha em APIs em que a autenticação funciona, mas a autorização por objeto não existe. O usuário A se loga com credenciais válidas, recebe um token legítimo e, ao trocar o identificador do recurso na chamada de API, acessa dados dos usuários B, C e D sem que o backend sequer verifique a quem aquele objeto pertence. A API confia no token e ignora o escopo. Não é coincidência que BOLA esteja no topo do OWASP API Security Top 10 desde a primeira edição do ranking, em 2019.
O caso tem duas narrativas em disputa. O pesquisador @weezerOSINT diz que se trata de um vazamento em massa atingindo todos os projetos criados antes de novembro de 2025, bastando poucas chamadas de API pra explorar. A Lovable nega que houve violação de dados e afirma que este comportamento é intencional pra projetos marcados como públicos, sendo a "documentação ruim" a única falha real. Vale entrar nessa divergência, até porque ela determina o tamanho do problema.
A defesa da Lovable se ancora num ponto legítimo. Um projeto marcado como público em uma plataforma de desenvolvimento é, de fato, público. Código, histórico de build, conversas com a IA. Quem marcou a opção e saiu colando credenciais dentro dos prompts tem uma parcela gigante de responsabilidade no que expôs. A empresa admite que a documentação sobre o significado de "público" era ambígua, o que se parece muito com um sopro de honestidade.
Mas tem um detalhe que a própria Lovable admitiu e que desmonta centralmente a sua defesa. Em fevereiro de 2026, durante uma unificação de permissões no backend, a empresa afirma que "reativou acidentalmente" acesso a chats em projetos públicos. O ato falho está na escolha da palavra "acidentalmente". Se houve reativação acidental, é porque antes havia restrição. E se havia restrição, o comportamento posterior não é intencional, mas regressão. O argumento de que tudo é "by design" cai no momento em que se reconhece que algo voltou sem querer.
A cronologia também pesa contra a versão da empresa. O reporte chegou em 3 de março via HackerOne. Ficou 48 dias parado, classificado como "duplicate submission" sob o entendimento de que ver chats de projeto público era intencional. A divulgação pública só veio em 20 de abril, após quase sete semanas de dados sensíveis permanecerem acessíveis enquanto o canal oficial de bug bounty tratava o report como simples "ruído". A partir daí, mais do que um debate semântico sobre o que é ou não público, o caso evoluiu pra uma falha de processo de segurança em cima do que deveria ser só uma falha técnica facilmente sanável. Quarenta e oito dias é tempo suficiente pra um atacante automatizar a coleta de cada chat público exposto na plataforma.
De outro lado, mesmo aceitando o argumento de que projeto público é público, o pesquisador fere de morte a defesa da empresa quando destaca que uma credencial de banco em um histórico de chat com o modelo não chega lá por escolha consciente do usuário. Veja, a própria interface da Lovable convida o desenvolvedor a colar o contexto real do projeto pra obter ajuda contextualizada. Além disso, em nenhum momento da conversa o sistema sinaliza que aquela informação pode ir a público. O design da interface sugere confidencialidade que a arquitetura não entrega.
Pra mim a Lovable tem razão num ponto secundário: público é público, e parte do conteúdo exposto é fruto de uma configuração que o usuário, em tese, escolheu de forma consciente. Mas o pesquisador tem razão no ponto central: houve BOLA real, com regressão admitida em fevereiro, e com falha clara de escalonamento no canal de bug bounty. Não é um empate. É um 7x1 do @weezerOSINT sobre a Lovable.
O caso interessa pra quem não é técnico porque a cadeia de exposição não para no desenvolvedor. Entre os usuários da plataforma estão funcionários de empresas como Uber, Zendesk e Deutsche Telekom, segundo o The Register. Ainda que esperemos mais discernimento da equipe técnica de uma empresa deste tamanho, não há nada impedindo um desenvolvedor menos cuidadoso de jogar uma credencial em alguma IA pra fechar um ticket no prazo, desesperadamente. Basta isto pra que esta credencial passe a existir num servidor de terceiros. Se esse servidor expõe o chat por BOLA, o vazamento não atinge só o desenvolvedor, mas a cadeia inteira de empresas que confiam nele.
E isto não vale apenas pra Lovable. Vale pra qualquer plataforma de IA em que a conversa com o modelo pareça privada porque a interface é íntima, enquanto o conteúdo dessa conversa mora num banco de dados que não é seu. A privacidade percebida e a privacidade efetiva são coisas diferentes, e essa diferença só aparece no dia do vazamento.
Plataformas que crescem rápido e tratam segurança como algo que podemos "ver depois" surgem na mesma velocidade em que a tecnologia evolui, e essa velocidade só aumenta. A adoção destas ferramentas está se mostrando ainda mais rápida, principalmente pelo número exponencialmente crescente de "desenvolvedores assistidos por IA". E se nenhum destes atores está prestando a devida atenção às questões de segurança, temos nós, os usuários, que tratar cada prompt como o que ele de fato é: uma carta sem envelope, num cofre que não é nosso, com a senha rabiscada a lápis na parede ao lado da porta.