Guias de Segurança
Código escrito por IA vazou uma chave de API e gerou cobranças fraudulentas — a verdadeira causa foi um CVSS 10.0 sem correção
Um app criado com ajuda da IA tem a chave de API roubada e acumula cobranças fraudulentas. A causa real não foi o suspeito óbvio, mas um RCE público CVSS 10.0 com meses sem patch — e como evitar que se repita, de forma defensiva.
Um caso que desenvolvedores indie sem familiaridade com segurança costumam enfrentar, com todo detalhe identificável removido e transformado em lição. Não há reprodução de ataque aqui — o objetivo é a defesa, para que o mesmo erro não aconteça com você.
- Classe
- Vazamento de chave de API / cobrança fraudulenta
- Severidade
- Crítica (um CVSS 10.0 publicado foi abusado)
- Causa raiz
- Um RCE pré-autenticação no framework web ficou sem correção por meses
- Escopo do vazamento
- Todos os segredos do ambiente (o chaveiro inteiro)
- Escopo da execução
- Permaneceu dentro de um container sem privilégios (o root do host ficou intacto)
- Correção permanente
- ①atualizar para a versão corrigida ②rotacionar todas as chaves ③monitorar CVEs por máquina
“Parou as cobranças” ≠ “resolvido”
Parar a fatura é primeiros socorros. Fechar o caminho do vazamento é uma operação separada. Você só termina quando faz as duas coisas.
O que aconteceu (linha do tempo)
Dia 0 — publicado e em operação
Um app criado com a ajuda da IA foi publicado e estava rodando em produção.Um dia — a fatura dispara
A fatura da IA na nuvem salta de repente. Jobs em massa num modelo que jamais seria usado, fazendo um trabalho que não era seu.Investigação — abuso por terceiros
"Nosso app saiu do controle" não explica. Um terceiro estava operando com uma chave roubada.A caçada — começa a investigação de verdade
"Então, de onde a chave vazou?" — essa era a investigação de verdade.
Por que não foi pego de início (os desvios)
Na ordem em que os erros foram cometidos — porque os erros são a lição.
Pulou para um culpado
→ Antes de decidir "culpa minha" ou "culpa deles", olhe primeiro os dados.
Um grep limpo quase trouxe alívio
Esconder o sintoma pareceu corrigir
Um grep limpo não é o sinal de tudo certo
Mesmo sem nenhuma chave em arquivo algum, uma vulnerabilidade pode extrair variáveis de ambiente de um processo em execução. Vazamentos acontecem em tempo de execução (RCE, headers HTTP), não só em arquivos. Veja O que é RCE.
A causa real: um CVSS 10.0 publicado e negligenciado
Uma assinatura estranha em logs de acesso antigos casou instantaneamente com a inteligência de ameaças. A faixa de versões do framework web em uso tinha um RCE pré-autenticação publicado (CVSS 10.0) que já estava sendo explorado na prática — e ficou sem correção por meses.
- Isso não foi um bug passivo — foi um invasor executando código no servidor e exfiltrando o ambiente.
- A salvação: a execução ficou dentro de um container sem privilégios (o root do host não foi tomado). A análise da invasão não encontrou backdoor persistente, minerador nem C2 — o impacto confirmado foi o roubo de segredos.
- Como o banco de dados interno estava acessível, a resposta presumiu que o conteúdo do banco também havia vazado.
Lição: quando algo se comporta de forma estranha, suspeite primeiro de um CVE conhecido. Não presuma que é um bug seu.
A contagem também estava errada — julgue pela versão em execução
Expandindo a análise, "mais 8 dependências vulneráveis" foi reportado — também errado. Tinham sido contadas pelo piso no package.json (a faixa com o acento circunflexo ^). As realmente perigosas eram apenas as 2 dependências fixadas que ficaram para trás.
Confira suas próprias versões em execução
Veja as versões de fato resolvidas, no lockfile ou no container em execução.
# npm: ver o que está de fato instalado
npm ls next react react-dom
# dentro de um container em execução
docker exec <container> npm ls <package>Os números aqui são a verdade — não o ^ no package.json.
O que foi feito primeiro (passos reproduzíveis)
Revogar a chave abusada imediatamente
Atualizar o framework para a versão corrigida
Rotacionar todos os segredos
Análise da invasão
Defesa do lado da conta
A prevenção de verdade: deixe as máquinas vigiarem
Resumindo, este incidente foi "um humano deixou passar um CVSS 10.0 publicado". Patrulhas manuais sempre deixam algo escapar. As máquinas, não.
Varredura de dependências que você pode começar hoje
Grátis para começar — um passo no CI.
# OSV scanner (Google) verifica seu lockfile
osv-scanner --lockfile=pnpm-lock.yaml
# No GitHub, ative o Dependabot (Settings do repo → Security)Este site, seguindo esta própria lição, monitora suas dependências em busca de CVEs — praticamos o que recomendamos.
Lições
Erros comuns
- Considerar resolvido em "parou as cobranças"
- Relaxar porque o grep está limpo
- Mascarar o sintoma num proxy e achar que corrigiu
- Contar vulnerabilidades pelo piso do
package.json - Rotacionar só a única chave confirmadamente abusada
Defesa correta
- Tratar primeiros socorros e "fechar o caminho do vazamento" como dois trabalhos separados, fazer ambos
- Suspeitar também de vazamentos em tempo de execução (RCE, headers)
- Atualizar a raiz (o framework)
- Julgar pela versão de fato em execução
- Substituir todo o env se ele vazar
Em uma linha: a fatura descontrolada era a ponta do iceberg. A causa real foi um RCE CVSS 10.0 negligenciado — e a verdade não veio de um palpite de sorte, mas de errar, colidir e desgastar os erros.
Leia a seguir
- Glossário: O que é RCE · O que é um CVE · O que é CVSS
- Defesa: Rodando Next.js com segurança (higiene de CVE)
- Incidente: Quando o .env ficou exposto para o mundo inteiro
FAQ
QSe uma chave de API vaza, basta revogar apenas a chave que foi abusada?
Não. Quando o caminho do vazamento é em tempo de execução (um RCE ou um vazamento por header), suponha que todos os segredos do ambiente vazaram de uma vez e rotacione todos. A chave que você viu sendo abusada é só a ponta do iceberg.
QSe um grep no meu código e no git não encontra nenhuma chave, estou seguro?
Não necessariamente. Mesmo sem nenhuma chave em arquivo algum, uma vulnerabilidade no framework pode exfiltrar variáveis de ambiente direto do processo em execução. Vazamentos também acontecem em tempo de execução, não só em arquivos.
QO que impede isso de acontecer de novo, da forma mais confiável?
Monitorar suas dependências em busca de CVEs por máquina. A causa raiz aqui foi um humano deixando passar um CVSS 10.0 publicado por meses; o Dependabot ou o osv-scanner fecham essa lacuna de forma estrutural.