As suas API keys podem ter ficado expostas?
Em outubro de 2026 tornaram-se públicos três incidentes que envolvem segredos de clientes: as variáveis de ambiente da Railway, a versão 1.107.0 do LiteLLM com um ladrão de credenciais e as API keys cifradas do TiDB Cloud.
Fazemos o inventário dos vossos segredos, rodamo-los numa ordem que corta primeiro o maior risco, revogamos os antigos, verificamos se alguém os usou e passamo-los para um gestor de segredos com tokens de curta duração.
# Que versão do LiteLLM está instalada?$ pip show litellm | grep -i ^versionVersion: 1.107.0# A 1.107.0 é a versão maliciosa publicada a 21-out no PyPI e no Docker Hub$ docker images | grep -i litellm$ grep -rn "litellm" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null# Fixe a última versão boa no lockfile e nas imagens$ pip install "litellm==1.106.2"# Fixar a versão não limpa a máquina: rode os segredos a que tinha acessoTrês incidentes, a mesma tarefa pendente
Nos três casos o fornecedor fez a sua parte e a rotação do que ficou exposto cabe ao cliente: o fornecedor não pode mudar a vossa chave da Stripe nem a da OpenAI.
Railway
A 21 de outubro detetou atividade anómala nos sistemas que guardam as variáveis de ambiente dos clientes. Um terceiro pode ter acedido a variáveis cifradas e, em alguns casos, decifrado-as. Pausou os deploys e pede para rodar credenciais. Não publicou número de afetados nem vetor. Fonte.
LiteLLM 1.107.0
A 21 de outubro foi publicada no PyPI e no Docker Hub uma 1.107.0 maliciosa: rouba credenciais e carrega código remoto ao arrancar qualquer processo Python. Os atacantes usaram tokens OAuth do GitHub CLI roubados a três engenheiros; a tag do GitHub está limpa. É a segunda vez este ano. Fonte: Wiz.
PingCAP / TiDB Cloud
Entre 9 de setembro e 7 de outubro, um terceiro usou credenciais roubadas de uma conta de serviço e copiou metadados de contas e projetos, texto do editor SQL, registos de faturação e valores cifrados de API keys. Sem evidência de impacto nos dados armazenados no TiDB. Fonte: PingCAP.
Seis passos, do inventário aos tokens de curta duração
Os quatro primeiros cortam o acesso e medem o dano. Os dois últimos mudam a forma como guardam os segredos, para que a próxima fuga afete menos coisas e dure menos.
- 01
Inventário de segredos
Variáveis do PaaS, ficheiros .env, segredos do CI, chaves dentro de imagens Docker e do código. Para cada um: a que dá acesso e em quantos sítios está.
- 02
Rodar por ordem
Fornecedores de IA, cloud, bases de dados, gateways de pagamento e tokens de CI. Primeiro o que se converte mais depressa em consumo ou em acesso a mais segredos.
- 03
Revogar as antigas
Uma chave que já não usam mas continua ativa vale o mesmo para quem a tiver. Verificamos em cada fornecedor que a anterior está revogada.
- 04
Rever os logs de utilização
Consumo dos fornecedores de IA, CloudTrail ou o registo de auditoria da vossa cloud, acessos à base de dados e o painel da Stripe, durante a janela de exposição.
- 05
Gestor de segredos
Passamos os segredos para um gestor (o da vossa cloud, Vault ou Doppler) para que cada um esteja num sítio e rodá-lo seja mudar um valor.
- 06
Tokens de curta duração
Onde o fornecedor o permite, o CI e os serviços pedem credenciais temporárias (OIDC, roles de IAM) em vez de guardar chaves que não expiram.
O que se roda primeiro e porquê
O LiteLLM é um proxy à frente dos fornecedores de modelos, por isso uma máquina que o executa costuma ter à mão as chaves de IA. Com uma chave de IA roubada alguém pode gerar consumo à vossa custa em minutos, e uma chave de cloud abre o resto.
Os tokens de CI ficam no fim da lista porque os usamos para fazer deploy das alterações anteriores. Se houver indícios de que o CI está comprometido, sobem para o início e fazemos deploy a partir de outro sítio entretanto.
Criar, fazer deploy, revogar, verificar
Se se revogar antes de fazer deploy da nova, a aplicação cai. Se se fizer deploy da nova e não se revogar a antiga, a fuga continua aberta.
Menos sítios onde vive cada chave
O que mais tempo leva numa rotação de urgência é descobrir onde está cada chave. Um gestor de segredos transforma esse inventário em algo que já existe antes do incidente.
- A mesma API key está no PaaS, no portátil de duas pessoas e no CI
- Ninguém sabe quantos sítios é preciso alterar para a rodar
- As chaves não expiram: uma que vazou há um ano continua a funcionar
- Sem registo de quem leu que segredo e quando
- Cada segredo está num sítio (AWS Secrets Manager, Vault, Doppler ou o da vossa cloud) e as apps leem-no daí
- Rodar é mudar um valor e voltar a fazer deploy
- O CI obtém credenciais temporárias por OIDC em vez de guardar chaves fixas
- O gestor regista os acessos, e é isso que se consulta primeiro num incidente
Usam Railway, LiteLLM ou TiDB Cloud?
Escreva-nos →Perguntas frequentes sobre credenciais expostas
Usamos Railway. Temos de rodar tudo?
Temos o LiteLLM 1.107.0. Basta descer para a 1.106.2?
O que devemos fazer se usamos TiDB Cloud?
Porquê essa ordem?
Rodar significa que já estamos seguros?
Começamos pelo inventário
Diga-nos onde fazem deploy e que fornecedores usam. Com isso preparamos a lista de segredos a rodar e a ordem, e decidem se somos nós a executá-la ou a vossa equipa.
Conte-nos seu desafio. Propomos uma solução.
Sem compromisso. Em menos de 24 horas, você recebe uma proposta com escopo, cronograma e orçamento. Sem letras miúdas.