Para: desenvolvedores e operadores que fazem deploy de aplicações ou bancos de dados na Zeabur, a plataforma de deploy de aplicações (PaaS), especialmente quem guarda em variáveis de ambiente chaves de API de serviços de IA, de pagamento, de nuvem ou credenciais de bancos de dados. Este artigo se baseia no relatório preliminar oficial da Zeabur e no anúncio de encerramento, e não trata de técnicas de ataque.
Em andamento: este artigo será atualizado conforme a organização publicar mais informações
- Quem é afetado
desenvolvedores e operadores que fazem deploy de aplicações ou bancos de dados na Zeabur, a plataforma de deploy de aplicações (PaaS), especialmente quem guarda em variáveis de ambiente chaves de API de serviços de IA, de pagamento, de nuvem ou credenciais de bancos de dados.
- Confirmado até agoraVer a tabela ↓
- Variáveis de ambiente no banco de dados da plataforma
- Dados de contas
- Chaves de API do zSend
Mais 2
- Access Tokens da plataforma
- Os que a empresa chama de GCP Dedicated Servers
- Ainda não confirmado
- Como o invasor obteve as credenciais iniciais
- Quantos dados foram de fato retirados dos bancos de dados do cluster compartilhado
- Se backups e outros objetos armazenados foram baixados
Mais 1
- Se os tokens vazados dos que a empresa chama de Hetzner and DigitalOcean Dedicated Servers foram usados
- O que fazer agoraVer os passos ↓
- Revogue cada segredo das suas variáveis de ambiente no serviço que o emitiu
- Usuários do cluster compartilhado: troquem também as senhas dentro do banco de dados
- Recrie os Access Tokens da Zeabur e as chaves de API do zSend
Mais 4
- Se você conectou o GitHub, verifique o log de auditoria de 15 de outubro
- Verifique o uso e as faturas a partir de 14 de outubro
- Se você teve prejuízo, envie o pedido até 30 de novembro de 2026
- Usuários de Dedicated Servers: tratem o servidor como comprometido se ele estiver no escopo
- Onde verificar (fonte)Todas as fontes ↓
- Zeabur, «Zeabur October 2026 security incident (preliminary report)» (19 de outubro de 2026)
- Última verificação
- Em 31 de outubro de 2026
Próximos avisos e o que verificamos
O relatório de 19 de outubro diz: «A investigação está em andamento e atualizaremos este artigo conforme ela avançar». Em 31 de outubro, a página ainda mostrava 19 de outubro como data. O único aviso posterior no blog da empresa é uma publicação de 22 de outubro sobre reembolsos e pedidos de ressarcimento pelo incidente, que não atualiza a investigação.
O que os usuários da Zeabur devem fazer hoje
Revogue cada segredo das suas variáveis de ambiente no serviço que o emitiu
Isso inclui chaves de API (serviços de IA, pagamentos, e-mail), chaves de nuvem, senhas de bancos de dados e chaves de assinatura e de criptografia. A ordem indicada pela empresa é: revogar primeiro o valor antigo no provedor do serviço, depois criar um novo, colocá-lo na Zeabur e fazer um novo deploy.
Apagar ou editar a variável apenas na Zeabur não impede o uso de uma cópia que alguém já tenha. Isso vale mesmo que você tenha substituído o valor após o incidente de agosto, porque a empresa diz que a troca de agosto não cobriu as credenciais usadas desta vez.
Usuários do cluster compartilhado: troquem também as senhas dentro do banco de dados
A empresa diz que mudar as variáveis de ambiente na Zeabur não muda as senhas dentro do banco de dados. Trocar senhas também não desfaz o vazamento de dados que já vazaram. Se o seu banco de dados armazena hashes de senhas, sessões de login ou tokens dos seus próprios usuários, revogue-os e gere-os de novo também.
A empresa também pede aos usuários que:
- n8n: substituam a chave de criptografia do n8n e recriem todas as credenciais de terceiros armazenadas no n8n
- new-api/one-api: revoguem as chaves dos serviços de IA de origem e gerem de novo os tokens de acesso
- PostgreSQL: procurem roles, funções, triggers, tarefas agendadas ou extensões que não reconheçam; em caso de dúvida, criem um novo banco de dados e importem apenas os dados
- Regiões de Taipé (tpe1) e Hong Kong (hkg1): tratem como vazados os dados dos backups dos bancos de dados
Recrie os Access Tokens da Zeabur e as chaves de API do zSend
A empresa diz que todos os usuários foram desconectados e todos os Access Tokens da plataforma foram revogados. Faça login de novo, crie novos tokens na página de Access Token e verifique se há requisições que você não reconhece. Usuários do zSend precisam recriar suas chaves de API do zSend (todas as 566 foram revogadas).
Se você conectou o GitHub, verifique o log de auditoria de 15 de outubro
A empresa diz que a chave privada da Zeabur GitHub App foi lida e substituída às 18:54 UTC de 15 de outubro, e que até agora não encontrou uso dela. Ela pede que os usuários verifiquem no log de auditoria do GitHub as ações da Zeabur GitHub App das 15:05 às 18:54 UTC de 15 de outubro: clones ou pushes inesperados, novas deploy keys e webhooks alterados.
Verifique o uso e as faturas a partir de 14 de outubro
Revise o uso e as faturas de cada serviço cujas chaves você armazenou, a partir de 14 de outubro de 2026. A empresa diz que essa é a data do primeiro uso conhecido das credenciais, não uma prova de que nada vazou antes. Usuários dos Dedicated Servers rotulados como «GCP Dedicated Servers» devem voltar até 1º de setembro. Para entender por que chaves de IA roubadas viram faturas rapidamente, veja chaves de API roubadas e banimento de contas.
Se você teve prejuízo, envie o pedido até 30 de novembro de 2026
O aviso da empresa de 22 de outubro diz que pedidos de ressarcimento de perdas causadas pelo incidente de outubro devem ser enviados como um chamado separado ao suporte da Zeabur (Zeabur Support) até 30 de novembro de 2026, e que só serão aceitos os enviados até essa data. Ela pede as contas e serviços afetados, os tipos de chaves ou credenciais vazadas e as faturas ou registros de uso de terceiros que cubram o período do incidente. Os pedidos são tratados separadamente dos reembolsos do saldo da conta.
Usuários de Dedicated Servers: tratem o servidor como comprometido se ele estiver no escopo
Para os Dedicated Servers rotulados como «GCP Dedicated Servers», a empresa diz para tratar o servidor como comprometido. Faça backup dos seus dados e reconstrua o servidor; essa é a forma mais confiável de remover qualquer coisa deixada para trás. Se não puder reconstruir de imediato, os passos mínimos indicados pela empresa são remover chaves SSH que você não reconhece, verificar contas, tarefas agendadas e serviços, trocar a senha de root e desativar o login por senha no SSH, e substituir todas as credenciais do servidor. O relatório da empresa lista os sinais a procurar; confira-os na página oficial.
Para os servidores que a empresa chama de «Hetzner and DigitalOcean Dedicated Servers», ela pede que você verifique no console do provedor se a senha de root foi redefinida ou o sistema foi reinstalado após 14 de outubro.
O que aconteceu (segundo o relatório da Zeabur)
O que segue se baseia no relatório preliminar da Zeabur de 19 de outubro de 2026 (publicado também em japonês e em outros quatro idiomas). Todos os horários estão em UTC.
Agosto de 2026
Outro incidente de segurança, separado, na Zeabur. A empresa diz que a troca feita depois não cobriu as credenciais usadas em outubro.14 de outubro, 01:36
Primeiro uso conhecido, pelo invasor, de uma chave interna de nuvem da Zeabur, seguido do acesso ao cluster compartilhado.15 de outubro, 13:56
A Zeabur inicia sua investigação após o relato de um usuário.15 de outubro, 16:10–16:47
O invasor lê o banco de dados da plataforma (confirmado pela empresa).15 de outubro, 20:25
A Zeabur troca sua chave de assinatura de login; todos os usuários são desconectados.15 de outubro, 21:05
Última atividade do invasor observada até agora.17 de outubro
A Zeabur anuncia que encerrará as atividades em 31 de dezembro de 2026.19 de outubro
A Zeabur publica seu relatório preliminar sobre o incidente.22 de outubro
A Zeabur fixa 30 de novembro de 2026 como prazo para pedidos de ressarcimento pelo incidente e diz que os dados dos serviços serão apagados em 31 de dezembro.
Armazenadas na Zeabur: lidas
Variáveis de ambiente mantidas no banco de dados da plataforma Zeabur, incluindo projetos que nunca as moveram
Movidas para o próprio Dedicated Server após agosto
Fora da leitura do banco de dados da plataforma. Se o próprio servidor estava no escopo, os segredos dele também precisam ser substituídos
A empresa pede a todos os usuários que substituam os segredos de qualquer forma. Essa divisão só indica o quão certa é a exposição.
- O que aconteceu
- Um invasor usou credenciais internas vazadas da Zeabur para invadir o cluster compartilhado, alguns Dedicated Servers e sistemas internos, e leu o banco de dados da plataforma
- Dados lidos
- Variáveis de ambiente (3.218.965 registros), dados de contas (321.810 contas), chaves de API do zSend (566), além de Access Tokens da plataforma armazenados como hashes irreversíveis (11.536, todos revogados)
- Outros sistemas
- Comandos foram executados dentro de 865 contêineres de bancos de dados no cluster compartilhado; logins como root foram confirmados em 101 dos servidores que a empresa chama de GCP Dedicated Servers
- Causa (empresa)
- Credenciais administrativas de longa duração armazenadas em texto puro e utilizáveis a partir da internet. A empresa diz que a causa raiz é responsabilidade da Zeabur
- Resposta
- Credenciais usadas revogadas, SSH público para interfaces administrativas e servidores bloqueado, todos os usuários desconectados, todos os Access Tokens revogados
- Ressarcimento
- Cobranças extras em chaves de API de terceiros ou contas de nuvem causadas pelo incidente podem ser reclamadas por meio de um chamado ao suporte, até 30 de novembro de 2026 (aviso de 22 de outubro)
O que se sabe e o que não se sabe
Situação em 31 de outubro de 2026. Os termos próprios da empresa são «confirmado» (um log registra diretamente), «avaliado» (momento e conteúdo coincidem, mas não há registro direto), «não é possível confirmar» (não há registros para verificar; tratado como vazado) e «hipótese» (uma explicação possível sustentada apenas por indícios indiretos). A coluna de situação segue esses termos. Quando houver novidades, ela será atualizada.
| Item | O que diz o relatório | Situação |
|---|---|---|
| Variáveis de ambiente no banco de dados da plataforma | 3.218.965 registros (nomes e valores) lidos | Confirmado (empresa) |
| Dados de contas | 321.810 contas: e-mail, nome de usuário, número de telefone e outros, além de dados de projetos | Confirmado (empresa) |
| Chaves de API do zSend | 566 chaves armazenadas em texto puro, todas revogadas | Confirmado (empresa) |
| Access Tokens da plataforma | 11.536 tokens armazenados apenas como hashes irreversíveis, todos revogados | Confirmado (empresa) |
| Variáveis de ambiente e segredos do cluster compartilhado | 9 regiões; parte confirmada, o restante tratado como vazado | Confirmado em parte; restante não é possível confirmar (empresa) |
| Conteúdo dos bancos de dados do cluster compartilhado | Comandos executados em 865 serviços de bancos de dados; não é possível confirmar quanto foi retirado | Avaliado (empresa) |
| Os que a empresa chama de GCP Dedicated Servers | Logins como root confirmados em 101 servidores (92 usuários) | Confirmado (empresa) |
| Backups de bancos de dados (Taipé tpe1, Hong Kong hkg1) | Não é possível confirmar se foram baixados. Em separado, a empresa diz que evidências em um host comprometido confirmam que às 15:42 UTC de 15 de outubro o invasor obteve um backup do banco de dados de um cliente | Não é possível confirmar (empresa) |
| Os que a empresa chama de Hetzner and DigitalOcean Dedicated Servers | Tokens administrativos vazados; não é possível confirmar se foram usados | Não é possível confirmar (empresa) |
| Dados de autenticação de dois fatores e de passkeys | Apenas estatísticas foram consultadas; não há registro de leitura do conteúdo | Sem registro de leitura do conteúdo (empresa) |
| Como as credenciais iniciais foram obtidas | Não é possível confirmar; uma ligação com agosto é hipótese não confirmada | Não é possível confirmar (empresa) |
| Uso indevido de chaves vazadas | A chave de um serviço de IA de um usuário foi usada em cerca de 1.107 requisições em 16 de outubro; a empresa diz que é uma hipótese que ela tenha vindo deste vazamento | Hipótese (empresa) |
Como ler isto: «não é possível confirmar» também significa trocar
A empresa diz que, quando não é possível descartar um acesso não autorizado, ela parte do princípio de que os dados podem ter sido expostos. Para os seus próprios segredos, a diferença prática entre «confirmado», «avaliado» e «não é possível confirmar» é pequena: todos significam revogar e substituir.
Ao que variáveis de ambiente vazadas podem levar
De modo geral, segredos retirados de variáveis de ambiente podem ser usados indevidamente das formas abaixo. Isso não significa que tudo isso aconteceu aqui.
- Chaves de API de serviços de IA: outra pessoa envia requisições na sua conta e você recebe a fatura. A empresa observou que o invasor procurava principalmente chaves que pudesse usar diretamente, em especial chaves de serviços de IA
- Senhas de bancos de dados e strings de conexão: ler ou alterar os dados da sua aplicação, incluindo registros dos seus próprios usuários
- Chaves de assinatura e de criptografia: forjar tokens de sessão ou descriptografar dados que sua aplicação protege
- Chaves de nuvem e de pagamento: criar recursos ou fazer chamadas que custam dinheiro
Um exemplo anterior: após o incidente das variáveis de ambiente da Railway, a empresa de hospedagem enviou aos serviços emissores listas de chaves possivelmente expostas para que pudessem ser revogadas. Este caso pode não seguir o mesmo caminho, então revogue você mesmo suas chaves.
Para operadores: lições do que a empresa divulgou
Estes pontos vêm da causa e das falhas que a própria empresa listou. Não são um julgamento adicional sobre a Zeabur.
- Dê prazo de validade aos tokens administrativos e mantenha as interfaces administrativas fora da internet. A empresa diz que os tokens administrativos do cluster não expiravam, não eram trocados desde janeiro de 2024 e que a interface administrativa era acessível pela internet.
- Após um incidente, troque todas as credenciais que podem ter sido lidas, não só as confirmadas como vazadas. A empresa diz que a troca de agosto não cobriu as credenciais usadas em outubro.
- Não deixe segredos em texto puro nos backups e mantenha as chaves dos backups separadas. A empresa diz que os backups do cluster continham todos os segredos e que uma chave trocada durante a resposta foi capturada por um backup posterior.
- Crie alertas para leituras em massa de segredos. A empresa diz que mais de 16 horas de atividade em 14 de outubro não geraram nenhum alerta e que o incidente foi descoberto após o relato de um usuário.
Para as suas próprias aplicações, o segredo mais seguro é aquele que a plataforma nunca armazena: credenciais de curta duração ou um cofre de segredos separado que a aplicação lê em tempo de execução (veja o que realmente é perigoso em .env e chaves de API).
Fontes (registro público)
Os fatos deste artigo se baseiam nas informações públicas abaixo. Não há especulação sobre vias de invasão que a empresa não confirmou, e indicadores de comprometimento não são reproduzidos aqui.
- Zeabur, «Zeabur October 2026 security incident (preliminary report)» (19 de outubro de 2026) — zeabur.com
- Zeabur, «Zeabur service migration, refunds, and security incident claims» (22 de outubro de 2026) — zeabur.com
- Zeabur, «Zeabur is shutting down: what happens next» (17 de outubro de 2026) — zeabur.com
Histórico de atualizações
2026-10-31: Primeira versão, com base no relatório preliminar da Zeabur de 19 de outubro, no anúncio de encerramento de 17 de outubro e no aviso de 22 de outubro sobre pedidos de ressarcimento pelo incidente. Em 31 de outubro, nenhum relatório de investigação posterior aparece no blog da empresa. Atualizaremos este artigo quando houver novidades.
Leia em seguida
- Incidente do mesmo tipo: Variáveis de ambiente da Railway possivelmente expostas (outubro de 2026) / Violação no OpenCode Console (outubro de 2026)
- Por que chaves de IA são alvo: como se defender de ciberataques com IA / chaves de API roubadas e banimento de contas
- Chaves vazadas que continuam válidas: credenciais vazadas que continuam válidas
- Outros incidentes de 2026: Vazamentos de dados e ciberataques de 2026