Vibe coding deixou 400 chaves de acesso à vista em aplicativos no ar

Vibe coding é fazer um programa pedindo para a inteligência artificial escrever o código, e publicar sem revisar linha por linha. Uma varredura em 5.600 aplicativos feitos assim encontrou mais de 400 chaves e credenciais expostas, além de mais de 2.000 falhas de alto impacto.

PrimeiroO que a varredura achou

O termo é de Andrej Karpathy, cofundador da OpenAI, num post de 2 de fevereiro de 2025. Ele descreveu assim: a pessoa conversa com a máquina, aceita o que ela escreve e esquece que o código existe. O uso se espalhou. Em 6 de novembro de 2025, o dicionário Collins elegeu "vibe coding" a palavra do ano.

A empresa de segurança Escape reuniu aplicativos que já estavam no ar, feitos nas plataformas que geram o programa inteiro a partir dessa conversa, e testou cada um. Publicou o resultado em 29 de outubro de 2025.

Uma chave de acesso, também chamada de chave de API, é a senha que um programa usa para falar com outro serviço, como o banco de dados ou o provedor de inteligência artificial. Quem tem a chave faz tudo que o programa faria.

Boa parte dessas chaves estava no arquivo que o navegador de qualquer visitante baixa para exibir a página. Não era preciso senha nem ferramenta para lê-las.

Já as mais de 2.000 falhas não vieram de simples leitura. A Escape rodou um teste automatizado, configurado para não executar nada destrutivo, que consultava as interfaces do aplicativo usando as próprias credenciais achadas na página. É uma sondagem ativa, ainda que sem força bruta.

SegundoPor que isso acontece

Quando alguém pede para a inteligência artificial escrever um programa, o resultado quase sempre funciona na primeira tentativa. Essa é a parte fácil, e é a única que a pessoa consegue conferir sozinha. Um erro de segurança não aparece na tela.

A Veracode monta 80 tarefas de programação em que existe um jeito seguro e um jeito inseguro de resolver, e observa qual deles os modelos escolhem sozinhos, sem ninguém pedir segurança. A medição publicada em 24 de março de 2026 mostra os dois lados dessa conta.

O resultado muda conforme a linguagem de programação. Python ficou em 62%, C# em 58% e JavaScript em 57%. Java ficou em 29%, o pior da lista.

Duas falhas tiveram as piores taxas. Uma é o XSS, quando o programa deixa outra pessoa injetar código na página que a vítima abre: 15% de aprovação. A outra é a injeção em registro de log, com 13%. As duas exigem acompanhar o caminho que um dado percorre dentro do sistema.

TerceiroA chave que vaza continua funcionando

Quando uma chave vai parar num repositório público, que é o lugar onde o código do projeto fica guardado com todo o seu histórico, o dono costuma apagar o registro daquela alteração e seguir em frente.

Apagar não resolve, porque o histórico do repositório guarda as versões anteriores e porque quem copiou já copiou. O que encerra o acesso é trocar a chave no serviço que a emitiu.

E o volume está subindo. Foram 28.649.024 chaves e senhas novas em repositórios públicos do GitHub em 2025, alta de 34% em um ano e o maior salto já registrado pela empresa. As ligadas a serviços de inteligência artificial passaram de 1,27 milhão, crescimento de 81%.

O mesmo relatório isolou as alterações de código feitas com o assistente Claude Code. Nelas, a taxa de vazamento foi de 3,2%, contra 1,5% na média de todas as alterações públicas do GitHub. É 2,1 vezes mais.

QuartoO que dá para conferir hoje

As três checagens abaixo não exigem ferramenta paga e qualquer pessoa consegue fazer pelo navegador.

• Abra o site sem estar logado. Copie o endereço de uma página interna, abra numa janela anônima e veja se ela carrega. Se carregar, ela está aberta para qualquer pessoa.
• Troque o número do endereço. Se a página termina em /pedido/1043, tente /pedido/1044. Se aparecer o pedido de outra pessoa, não existe controle de acesso ali.
• Se uma chave já vazou, emita outra. Apagar o arquivo não invalida a chave antiga.

Para quem programa, vale uma quarta: nenhuma chave pode estar em arquivo de código. O lugar delas é o arquivo de configuração separado, o .env, e esse arquivo precisa estar listado no .gitignore, que é a lista do que não sobe para o repositório.

QuintoSites que conferem por você

Os quatro abaixo são gratuitos e não pedem cadastro. Eles fazem coisas diferentes, e a diferença importa.

• securityheaders.com e o HTTP Observatory, da Mozilla, leem o que o seu servidor já entrega a qualquer visitante e dão uma nota aos cabeçalhos de proteção. Cabeçalho é uma instrução que o servidor manda junto com a página, dizendo ao navegador o que pode e o que não pode ser feito ali. Vale rodar os dois, porque as notas nem sempre coincidem.
• crt.sh não toca no seu site. Ele consulta os registros públicos de transparência de certificados e mostra os nomes de host que aparecem em certificados emitidos para o seu domínio. É onde costuma aparecer o ambiente de teste ou o painel antigo que continua no ar. Certificado emitido por autoridade interna não entra nesses registros. O serviço fica fora do ar com alguma frequência, inclusive na data desta publicação.
• ssllabs.com/ssltest, da Qualys, testa o certificado e a criptografia. Este é diferente dos outros: ele envia conexões preparadas para descobrir se o servidor responde a falhas conhecidas. Os termos de uso exigem que você tenha permissão do dono do site, a avaliação leva de um a dois minutos, e o resultado vai para um quadro público a menos que você marque a caixa "Do not show the results on the boards".
• gitleaks roda na sua máquina, no seu repositório, e procura chave e senha no histórico inteiro do projeto. É aberto e gratuito.

O haveibeenpwned.com não olha sistema nenhum: consulta uma base de vazamentos já conhecidos e diz se um e-mail seu aparece em algum.

Existe ainda a categoria dos serviços que ficam ligados ao repositório e avisam a cada alteração. Aikido e Snyk são dois deles, os dois com plano gratuito. No Aikido, o plano gratuito cobre 10 repositórios e 2 pessoas sem pedir cartão, e o pago começa em 300 dólares por mês para 10 pessoas.

SextoO que ainda não se sabe

A Escape declara quatro limites do próprio levantamento, e eles mudam como o número deve ser lido.

• A coleta foi feita uma vez só, em outubro de 2025. A própria empresa diz que falhas podem ter sido corrigidas ou criadas desde então. Os números descrevem aquele momento.
• O total subestima o problema. Como o teste evitou operações destrutivas, o relatório diz que os achados são apenas uma parte do que seria explorável.
• Domínios identificáveis como de saúde ou educação foram excluídos de propósito, por decisão legal e ética. Ainda assim o relatório lista registro médico entre os dados pessoais encontrados, e não explica como os dois fatos convivem. A explicação não está no material publicado.
• A amostra não é aleatória. Os aplicativos vieram de busca no Shodan, de diretórios de lançamento e de fóruns das próprias plataformas. A cobertura inicial de descoberta era de cerca de 4.000 aplicações Lovable, 449 do Create.xyz e 159 do Base44, mais amostras menores de Vibe Studio e Bolt.new. A divisão final das 5.600 analisadas não foi publicada.