Chaves públicas do Google Cloud expostas ganham acesso indevido a endpoints do Gemini

Chaves usadas em aplicações cliente podem autenticar chamadas ao Gemini após a ativação da API no mesmo projeto, ampliando risco de consumo de cota, cobrança indevida e acesso a arquivos enviados.

Componente	Chaves de API do Google Cloud com prefixo AIza em projetos que tiveram a Generative Language API, usada pelo Gemini, habilitada.
Vetor	Chaves embutidas em JavaScript de sites ou aplicações Android podem ser coletadas publicamente e reutilizadas contra endpoints do Gemini quando a API está ativa no projeto.
Impacto	Uso de cota e cobrança de chamadas de LLM, além de acesso condicionado a arquivos enviados e conteúdos em cache por endpoints como /files e /cachedContents.
Prioridade	Inventariar projetos com APIs de IA habilitadas, localizar chaves expostas em cliente ou repositórios públicos e rotacionar primeiro as chaves antigas.
Artefatos	Foram identificadas 2.863 chaves vivas acessíveis publicamente; outro levantamento encontrou mais de 35.000 chaves únicas em 250.000 aplicativos Android analisados.
Mitigação	O Google informou ter implementado medidas proativas para detectar e bloquear chaves vazadas que tentem acessar a API do Gemini.

Resumo técnico

Uma mudança de escopo operacional em projetos do Google Cloud transformou chaves de API originalmente tratadas por muitos desenvolvedores como identificadores de uso e cobrança em credenciais capazes de autenticar chamadas a endpoints sensíveis do Gemini. O ponto central é a relação entre chaves públicas já distribuídas em código cliente e a habilitação posterior da Generative Language API no mesmo projeto. Quando essa API é ativada, chaves existentes no projeto podem passar a aceitar chamadas ao Gemini, mesmo que tenham sido publicadas antes com a expectativa de uso em serviços como mapas embutidos em páginas web.

O problema não depende de uma falha clássica de execução remota nem de exploração de memória. O risco nasce da combinação entre chaves acessíveis publicamente, permissões amplas e ativação de uma API de inteligência artificial com custo e superfície de dados próprios. Em um levantamento, 2.863 chaves ativas com prefixo AIza foram encontradas na internet. Essas chaves estavam em locais como JavaScript de sites, onde são facilmente coletadas por varreduras automatizadas. Em paralelo, uma análise de 250.000 aplicativos Android encontrou mais de 35.000 chaves únicas incorporadas em pacotes móveis, reforçando que esse padrão de exposição não está restrito a aplicações web.

A consequência técnica é relevante para equipes de cloud security porque o modelo mental antigo, no qual certas chaves eram vistas como tokens de identificação de projeto para fins de faturamento, deixa de ser suficiente quando novas APIs são habilitadas no projeto. Uma chave exposta pode consumir cota, gerar custos com inferência e, dependendo do estado do projeto e dos recursos associados, consultar dados acessíveis por endpoints do Gemini, incluindo arquivos enviados e conteúdos armazenados em cache. Não há confirmação de exploração em larga escala no ambiente real, mas há uma alegação pública de cobrança anômala de US$ 82.314,44 entre 11 e 12 de fevereiro de 2026 associada a uma chave do Google Cloud supostamente roubada, contra um gasto mensal regular de US$ 180.

Fluxo técnico

O fluxo começa com uma decisão comum de implementação: inserir uma chave de API do Google Cloud em código do lado do cliente para habilitar recursos relacionados ao Google em um site ou aplicativo. Esse padrão aparece, por exemplo, em integrações que precisam identificar um projeto para serviços públicos. A chave, por estar no JavaScript entregue ao navegador ou dentro de um pacote móvel, não deve ser tratada como segredo. O risco aumenta quando o mesmo projeto passa a ter a API do Gemini habilitada, pois a chave já publicada pode herdar capacidade de autenticação contra endpoints da nova API.

A condição crítica é a presença de uma chave válida, exposta e aplicável a APIs habilitadas no projeto. O comportamento observado inclui chaves novas criadas no Google Cloud com configuração inicial ampla, descrita como sem restrição, tornando-as aplicáveis a qualquer API habilitada no projeto. Se uma chave assim estiver em um site público ou em um repositório acessível, um operador não autorizado pode coletá-la por raspagem, testar sua validade e direcionar chamadas ao Gemini para consumir cota da conta proprietária. Esse abuso não exige acesso ao console do Google Cloud; ele depende da reutilização da própria chave em endpoints aceitos pelo serviço.

Dois endpoints citados concentram a atenção defensiva: /files e /cachedContents. O primeiro está relacionado a arquivos enviados para uso com a API, enquanto o segundo se vincula a conteúdos em cache. O acesso efetivo a dados por esses caminhos depende do que existe no projeto, das configurações aplicáveis e do estado dos recursos. Ainda assim, a simples possibilidade de uma chave pública tocar esses endpoints muda a classificação de risco, porque a exposição deixa de ser apenas um problema de cobrança e passa a envolver também conteúdo processado por fluxos de inteligência artificial. Para defesa, a distinção importante é que a chave não precisa ter sido criada com intenção maliciosa; ela pode ter sido implantada anos antes sob premissas que mudaram quando a API de IA foi habilitada.

Superfície afetada

A superfície mais exposta está em projetos do Google Cloud que combinam três condições: chaves de API acessíveis publicamente, APIs de IA habilitadas e ausência de segmentação efetiva por uso. Sites que carregam chaves no JavaScript, aplicativos Android que empacotam chaves no binário e repositórios públicos com configurações antigas são pontos de coleta previsíveis. O risco é maior para chaves antigas, porque elas podem ter sido distribuídas quando a equipe acreditava que o uso público era aceitável para aquele tipo de integração e depois ganharam alcance adicional com a ativação do Gemini no projeto.

A superfície também inclui processos de desenvolvimento e governança. Projetos compartilhados por várias equipes podem acumular APIs habilitadas por demandas diferentes, enquanto a mesma chave permanece em produção em páginas, aplicativos e exemplos internos. Quando uma API com custo variável e potencial acesso a artefatos de IA é adicionada ao projeto, a exposição anterior passa a ter outro impacto. Isso torna insuficiente validar apenas se a chave aparece em código público; é necessário cruzar a exposição com a lista de APIs habilitadas, idade da chave, finalidade original, consumo recente e presença de arquivos ou cache associados ao Gemini.

• Projetos do Google Cloud com Generative Language API habilitada e chaves de API públicas com prefixo AIza.
• JavaScript de sites que contém chaves usadas originalmente para serviços públicos, como integrações de mapas.
• Aplicativos Android com chaves incorporadas no pacote, especialmente quando o mesmo projeto habilita APIs adicionais depois da publicação.
• Chaves criadas como sem restrição e aplicáveis a todas as APIs habilitadas no projeto.

Hunting e telemetria

A investigação deve começar pelo inventário de chaves. Equipes de segurança precisam correlacionar cada chave com projeto, APIs habilitadas, origem de uso esperada e presença em superfícies públicas. O objetivo não é apenas encontrar strings com prefixo AIza, mas determinar se uma chave publicamente visível pode chamar a API do Gemini. Essa validação deve ser feita por meios administrativos e logs internos, sem reproduzir chamadas ofensivas. A análise de histórico ajuda a priorizar chaves criadas antes da habilitação de APIs de IA, pois elas podem ter sido publicadas sob critérios de risco desatualizados.

Na telemetria, o sinal mais importante é desvio de uso: aumento repentino de chamadas relacionadas ao Gemini, consumo de cota fora do padrão, cobranças incompatíveis com o volume normal e origem de tráfego que não corresponde aos clientes legítimos. Também vale revisar acessos aos endpoints /files e /cachedContents, principalmente quando partem de chaves associadas a aplicações públicas. Uma chave usada apenas por um site específico não deveria gerar tráfego de inferência em volume elevado, nem acessar recursos de IA que não fazem parte da função esperada da aplicação.

Em ambientes com monitoramento de custo, alertas de billing devem ser tratados como telemetria de segurança. Uma cobrança incomum pode indicar abuso de cota antes mesmo de haver indícios claros em logs de aplicação. A alegação pública de custo acima de US$ 82 mil em dois dias mostra o tipo de impacto financeiro que uma chave abusada pode gerar, embora esse caso específico não confirme exploração ampla. Para resposta, a triagem deve diferenciar uso legítimo recém-implantado, automação interna mal configurada e chamadas externas não autorizadas.

• Chaves AIza presentes em JavaScript público, pacotes móveis, repositórios públicos ou artefatos de build.
• Chamadas ao Gemini usando chaves que deveriam estar limitadas a serviços não relacionados a IA.
• Acesso inesperado a /files e /cachedContents associado a chaves expostas.
• Picos de consumo, aumento de cota e cobranças fora do padrão histórico do projeto.
• Criação recente de chaves sem restrição ou habilitação recente da Generative Language API em projetos antigos.

Mitigação

A resposta deve priorizar redução de exposição e contenção de custo. O primeiro passo é revisar APIs e serviços habilitados em cada projeto do Google Cloud, com atenção específica às APIs relacionadas a inteligência artificial. Se a Generative Language API estiver ativa em um projeto que também contém chaves publicamente acessíveis, essas chaves devem ser tratadas como comprometidas para fins operacionais. A rotação deve começar pelas chaves mais antigas, porque são as mais prováveis de terem sido publicadas quando a equipe ainda considerava esse tipo de chave aceitável em código cliente.

Depois da rotação, a equipe deve validar se as novas chaves estão restritas à finalidade necessária e se não permanecem em artefatos públicos. Chaves que precisam existir em código cliente devem ter escopo minimizado e devem ser separadas de projetos que habilitam APIs sensíveis ou de alto custo quando isso for possível no desenho da aplicação. A separação por projeto reduz o efeito de uma ativação posterior de API, pois impede que uma chave exposta para um serviço público ganhe acesso implícito a fluxos de IA ou a dados associados ao Gemini.

A mitigação também exige governança contínua. Mudanças em APIs habilitadas, permissões de chaves e padrões de consumo precisam ser revisadas como eventos de segurança, não apenas como ajustes de plataforma. O Google informou ter adotado medidas proativas para detectar e bloquear chaves vazadas tentando acessar a API do Gemini, mas isso não substitui inventário local, rotação e monitoramento de custo. Para equipes de engenharia, o aprendizado principal é que o risco de uma chave pública pode mudar depois da implantação, quando novas APIs são ativadas no mesmo projeto ou quando o serviço passa a aceitar aquela credencial em caminhos antes inexistentes.

• Listar projetos com APIs de IA habilitadas e cruzar com chaves presentes em código cliente, aplicativos móveis e repositórios públicos.
• Rotacionar primeiro chaves antigas e chaves sem restrição que estejam associadas a projetos com Gemini habilitado.
• Separar chaves públicas de projetos que armazenam arquivos, conteúdos em cache ou integrações sensíveis de IA.
• Monitorar consumo e cobrança por projeto para detectar abuso de inferência rapidamente.
• Revisar processos de criação de chaves para evitar configuração ampla quando a aplicação precisa apenas de um serviço específico.