A plataforma PaaS de Taiwan, Zeabur, enfrentou um incidente de segurança cibernética em 27 de agosto de 2026, quando um conjunto de credenciais de serviço interno foi utilizado de forma não autorizada. Os atacantes usaram essas credenciais para consultar a base de dados que armazena variáveis de ambiente do projeto, resultando na exposição de informações sensíveis dos usuários, como API Key / Token, strings de conexão de banco de dados e JWT Secret, configurados no Zeabur para OpenAI, Anthropic, OpenRouter, Gemini, GitHub, AWS, Cloudflare, Stripe, entre outros. O fundador, Lin Yuanlin, já confirmou publicamente o incidente e afirmou que compensará os usuários assim que as perdas individuais forem verificadas. Este artigo compila as medidas atualmente divulgadas oficialmente, os passos de remediação que os usuários devem tomar imediatamente, e a coincidência temporal do buraco de segurança do LiteLLM que está a ser observada.
Linha do tempo do incidente: 27/08 descoberta → 28/08 notificação → 29/08 declaração do fundador
De acordo com a declaração pública do fundador Lin Yuanlin e a página de status oficial (https://status.zeabur.com/incident/1037896) e reportagens da mídia (Dongqu, INSIDE), a linha do tempo do incidente é a seguinte:
- 2026-08-27: Zeabur confirma que um conjunto de credenciais de serviço interno foi utilizado de forma não autorizada, permitindo que os atacantes consultassem a base de dados que armazena variáveis de ambiente do projeto.
- No mesmo dia: A equipe do Zeabur completou o controle inicial, revogou as credenciais e bloqueou o acesso.
- 2026-08-28: Notificaram os usuários afetados em duas etapas; a empresa também indicou que, mesmo sem receber um e-mail, os usuários devem verificar, pois qualquer valor que corresponda ao formato conhecido de credenciais pode ter sido exposto.
- 2026-08-29: O fundador Lin Yuanlin emitiu uma declaração pública de desculpas, afirmando que as perdas individuais seriam compensadas assim que verificadas.
Relatos da mídia também mencionam que os usuários só perceberam anomalias na fatura na madrugada de 28 de agosto e consultaram o suporte ao cliente, recebendo a resposta “sem anomalias” até cerca das 17 horas, quando finalmente receberam a notificação oficial. O fundador declarou que continuará a monitorar e notificará individualmente os usuários que possam ter sido afetados, colaborando com fornecedores e autoridades para uma investigação mais aprofundada.
Escopo da exposição + serviços conhecidos que foram efetivamente utilizados de forma indevida
Foi confirmado que as chaves expostas estão nas variáveis de ambiente, abrangendo as seguintes categorias:
- API de AI / LLM: OpenAI, Anthropic, OpenRouter, Gemini
- Hospedagem de código fonte: GitHub
- Serviços em nuvem: AWS, Cloudflare
- Serviços de pagamento: Stripe
- Strings de conexão de banco de dados
- Chaves de aplicação como JWT Secret
- Anthropic
- OpenAI
- OpenRouter
Devido a atividades suspeitas no LiteLLM, o Zeabur AI Hub suspendeu os serviços até novo aviso. A empresa divulgará um relatório completo e um plano de compensação posteriormente. O progresso pode ser acompanhado na [Página de Status do Zeabur](https://status.zeabur.com).
Coincidência temporal do buraco de segurança do LiteLLM (causalidade não confirmada oficialmente)
A Zeabur ainda não confirmou oficialmente uma relação direta entre este incidente e o LiteLLM. No entanto, a coincidência é que, um dia antes do incidente, o GitHub oficial do LiteLLM divulgou uma vulnerabilidade de alto risco: [GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222).
O conteúdo da vulnerabilidade: usuários do LiteLLM que já estão logados podem, através de requisições personalizadas, fazer com que o LiteLLM exponha as chaves de API upstream (incluindo OpenAI, Claude, etc.).
Se você está usando o LiteLLM como um intermediário de API:
- Atualize imediatamente o LiteLLM para a versão corrigida.
- Limite parâmetros controláveis como api_base para evitar a exposição de endpoints internos.
- Revise e troque todas as chaves de API upstream (OpenAI / Anthropic / OpenRouter, etc.).
- Verifique os registros de acesso do LiteLLM e fique atento a qualquer chamada anômala.
⚠️ Atenção: A Zeabur não confirmou que a vulnerabilidade do LiteLLM é a causa raiz do incidente. Neste momento, só podemos afirmar que os dois eventos ocorreram em uma proximidade temporal. A Zeabur indicou que fornecerá mais informações em um relatório completo posterior.
4 passos que os usuários devem tomar imediatamente
Se você já colocou uma API Key ou token de nuvem nas variáveis de ambiente do Zeabur (independentemente de ter ou não recebido a notificação do Zeabur), por favor, siga os passos abaixo imediatamente:
- Passo 1 — Revogar chaves antigas: Acesse o painel do provedor original (OpenAI / Anthropic / OpenRouter / GitHub / AWS / Stripe, etc.) e revogue as chaves afetadas. A revogação não pode ser feita apenas excluindo as variáveis de ambiente no Zeabur, pois as chaves antigas ainda são válidas.
- Passo 2 — Criar novas chaves: Crie novas chaves no painel do provedor original e cole-as de volta nas variáveis de ambiente do Zeabur.
- Passo 3 — Verificar uso e faturas: Acesse o painel do provedor original e verifique o uso da API, consumo de tokens e faturas dos últimos 7 dias. Fique atento a aumentos repentinos ou padrões de requisições estranhas (como prompts desconhecidos ou uso anômalo durante a noite).
- Passo 4 — Verificar registros de acesso: Se o provedor original fornecer logs de requisições (como OpenAI Usage, Anthropic Console), baixe os registros dos últimos 7 dias para manter como evidência.
⚠️ A “revogação” é crucial: na maioria dos painéis de serviços de API, “criar novas chaves” não fará com que as chaves antigas se tornem inválidas automaticamente. Você deve ativamente “revogar” as chaves antigas, caso contrário, elas ainda podem ser utilizadas indevidamente.
Como solicitar assistência e apresentar provas à Zeabur
Se você suspeita que sua chave foi utilizada de forma indevida, complete primeiro os passos de revogação e criação de novas chaves, e depois prepare as seguintes informações:
- Intervalo de tempo em que a utilização indevida ocorreu (quanto mais preciso, melhor).
- Montante afetado ou números de consumo de tokens.
- Informações de rastreamento como IP de origem da requisição, identificação do dispositivo (device fingerprint), etc.
- Outras evidências que possam ajudar as autoridades na investigação.
Envie essas informações para a página de suporte técnico da Zeabur. A empresa afirma que dará a mais alta prioridade a todos os pedidos relacionados a este incidente e, após concluir as investigações e verificações necessárias, procederá com a compensação o mais rápido possível.
Autoproteção do usuário — melhores práticas para prevenir eventos semelhantes
Este incidente revela os riscos inerentes à “gestão centralizada de variáveis de ambiente” em plataformas PaaS: uma vez que as credenciais internas da plataforma são comprometidas, todas as chaves dos usuários podem ser expostas simultaneamente. Aqui estão algumas medidas de autoproteção que podem ser adotadas imediatamente:
- Não mantenha chaves a longo prazo em uma única plataforma: se puder armazená-las localmente ou em seu próprio gerenciador de segredos (como 1Password, AWS Secrets Manager, GCP Secret Manager), não as coloque na plataforma.
- Defina limites de gastos para cada serviço: tanto OpenAI quanto Anthropic suportam limites orçamentais rígidos, permitindo cortar o uso imediatamente ao detectar anomalias.
- Troque regularmente as chaves: troque a API Key a cada 90 dias para reduzir a janela de exposição em caso de vazamento.
- Ative listas brancas de IP no painel dos fornecedores de AI: limite o acesso à API Key apenas a um intervalo de IPs específicos.
- Crie chaves independentes para cada serviço: não use a mesma chave para todos os serviços, facilitando a revogação rápida em caso de problemas.
- Defina alertas de uso: configure notificações automáticas por e-mail/SMS quando o uso ultrapassar um determinado limite.
Para as equipes de desenvolvimento, medidas adicionais incluem: a curto prazo — armazenamento criptografado das chaves de variáveis de ambiente (plataformas como Zeabur deveriam suportar nativamente a criptografia estilo KMS). A médio prazo — adotar recuperação de segredos de zero confiança, como HashiCorp Vault, AWS Secrets Manager. A longo prazo — pressionar os fornecedores de SaaS a mudarem as API Keys para tokens de curta duração (como OAuth-style), reduzindo o risco de exposição de chaves estáticas.
Declaração pública do fundador Lin Yuanlin
A seguir está o texto original da declaração do fundador Lin Yuanlin emitida em 29 de agosto (trecho):
“Olá a todos, sou Yuanlin Lin, o fundador da Zeabur. Sobre o incidente de vazamento de variáveis de ambiente do Zeabur descoberto ontem, já completamos as seguintes ações: no dia em que detectamos anomalias, completamos o controle inicial; continuamos a monitorar se há mais anomalias; notificamos todos os usuários que possam ter sido afetados e publicamos um aviso; estamos colaborando com fornecedores e autoridades para uma investigação mais aprofundada.”
“Se você já recebeu nosso e-mail de notificação, ou se atualmente possui API Keys de serviços de AI de terceiros como OpenAI, Anthropic, OpenRouter, etc., por favor, siga rapidamente as instruções de troca abaixo e verifique imediatamente seu uso e faturas.”
“Se você descobrir que suas credenciais foram utilizadas de forma indevida, complete imediatamente a troca de credenciais e verifique o uso e as faturas dos serviços relacionados, e por favor, ajude-nos a obter do painel dos fornecedores de AI as informações sobre as requisições indevidas: tempo de ocorrência, montante ou consumo de tokens, IP de origem da requisição, identificação do dispositivo, entre outras informações que possam nos ajudar a investigar com as autoridades.”
“Por favor, envie todas as informações que possam nos ajudar a colaborar com as autoridades na investigação e verificação de suas perdas para a página de suporte técnico da Zeabur. Daremos a mais alta prioridade a todos os pedidos relacionados a este incidente e, após concluir as investigações e verificações necessárias, procederemos o mais rápido possível com a compensação.”
Conclusão: desenvolvimentos futuros e link de status oficial
Este incidente nos lembra mais uma vez: colocar API Keys nas variáveis de ambiente de uma plataforma PaaS de terceiros é, na essência, como colocar todas as chaves em um único cofre. Se o cofre for comprometido, todos os usuários são afetados ao mesmo tempo.
A Zeabur indicou que divulgará a causa raiz completa do incidente, o número de pessoas afetadas, o cronograma de compensação e o relatório final do incidente. Os leitores podem acompanhar os últimos desenvolvimentos através dos seguintes canais:
- Página de Status Oficial da Zeabur: [status.zeabur.com](https://status.zeabur.com)
- Número do incidente da Zeabur: [incident/1037896](https://status.zeabur.com/incident/1037896)
- Detalhes da vulnerabilidade do LiteLLM: [GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222)
- Reportagens da mídia: Dongqu, INSIDE
Se você detectar uso suspeito ou precisar enviar informações sobre casos de perdas, entre em contato com a equipe oficial através da página de suporte técnico da Zeabur o mais rápido possível.