Zeabur fecha após segunda invasão em sete semanas
A invasão de 14–15 de outubro de 2026 é real e foi confirmada pela própria Zeabur: 321.810 contas e 3.218.965 registros de variáveis de ambiente lidos no banco de produção, além de acesso root a 101 servidores dedicados no GCP. Ninguém reivindicou o ataque. A empresa atribui a entrada a credenciais internas guardadas em texto claro e diz que vai encerrar a plataforma até 31/12/2026.
Juízos analíticos
Cada avaliação vem com seu nível de confiança declarado, conforme a prática de inteligência (ICD 203 / FIRST). Confiança alta não é certeza; confiança baixa não é chute — é o peso que a evidência disponível sustenta.
O incidente de outubro é real e a escala informada (321.810 contas; 3.218.965 registros de variáveis de ambiente; 566 chaves zSend em texto claro) vem da própria vítima, que a cruzou com logs de consulta ao banco. O número é confiável como piso, mas nenhuma parte independente o auditou.
A entrada não dependeu de vulnerabilidade nova: o atacante usou chaves AWS e tokens de administrador do cluster guardados em texto claro num repositório privado de configuração, e a senha root dos servidores GCP estava em texto claro na configuração de inicialização. Seria desmentido se o relatório final mostrar um vetor externo não descrito até agora.
A Zeabur levanta a hipótese de que as credenciais usadas em outubro vieram do incidente de agosto (chave privada de GitHub App vazada), mas diz que não consegue confirmar. Considero a ligação plausível, não demonstrada. A hipótese cai se o relatório final identificar outra origem para as credenciais.
O alcance do incidente cresceu a cada comunicação, então o relatório preliminar deve ser lido como piso. A primeira nota na página de status falava só de bancos gerenciados em clusters compartilhados em desativação e dizia não haver evidência sobre servidores dedicados. Cerca de 4h40 depois a própria empresa retratou isso. O relatório de 19/10 traz uma janela de atividade do atacante bem mais longa que a da notificação inicial, desde que os horários estejam no mesmo fuso, o que o texto não deixa explícito.
O risco de uso posterior dos segredos roubados é alto até que cada cliente os rotacione. Em agosto, usuários relataram uso indevido de chaves de OpenAI, Anthropic e OpenRouter e a Zeabur abriu processo de ressarcimento. Para outubro não encontrei, em fonte que eu tenha lido, abuso comprovado nem extorsão; isso não prova que não exista.
Não é possível atribuir o ataque a nenhum ator. Nenhum grupo reivindicou, não há pedido de resgate nem oferta de dados que eu tenha encontrado, e a empresa não descreve o atacante.
Análise
Correção do registro: o campo de vítima trazia a manchete do BleepingComputer, não o nome da organização. A vítima é a Zeabur, plataforma taiwanesa de deploy em nuvem. O selo 'claimed' e o veredito 'unverified' estavam errados. Não existe alegação de ator: quem descreve o incidente, em relatório e página de status, é a própria vítima. O selo correto é 'confirmed' e o veredito é 'real'. A data de 20/10 é a da matéria; o incidente foi em 14–15/10 e o encerramento foi comunicado em 17/10.
O que a vítima admite: no relatório preliminar de 19/10, a Zeabur diz que um atacante usou credenciais internas vazadas para entrar no cluster compartilhado, em parte dos servidores dedicados e em sistemas internos, e leu o banco da plataforma. A tabela de impacto confirma 3.218.965 registros de variáveis de ambiente (nomes e valores), 321.810 contas (e-mail, usuário, telefone e dados de projeto) e 566 chaves zSend em texto claro, já revogadas. Os tokens de acesso da plataforma estão guardados só como hash. A Zeabur diz que o atacante leu a chave de assinatura de login e avalia que a usou para forjar credenciais. Segundo o BleepingComputer, que cita a Zeabur, houve login root em 101 servidores GCP de 92 usuários, chaves SSH inseridas em 50 deles e 16 cópias de discos de clientes anexadas a máquinas virtuais do atacante. Li esses números do servidor GCP e dos discos na matéria do BleepingComputer, não na parte do relatório a que tive acesso.
O que a evidência demonstra e o que não: a causa imediata é de higiene de credenciais. As chaves AWS e os tokens do cluster ficavam em texto claro num repositório privado de configuração, e a senha root dos servidores GCP ficava em texto claro na configuração de inicialização. Segundo a Zeabur, a regra de rede interna permitia que um nó adicionado se conectasse à plataforma. Como o atacante obteve as credenciais, a empresa diz que não consegue confirmar. A hipótese dela é a chave privada de GitHub App vazada em agosto. O BleepingComputer descreve a falha como não rotacionar todas as credenciais de administrador desde agosto, com portais administrativos acessíveis pela internet. A Zeabur afirma ter rotacionado as chaves que sabia comprometidas, o que sugere que o problema foi o que ela não sabia estar comprometido. Não há log público que prove a ligação entre os dois ataques.
Onde as versões divergem: a Zeabur mudou três vezes o que disse. A primeira nota (16/10) restringia o acesso a bancos de usuários em clusters compartilhados em desativação e dizia não ter evidência sobre servidores dedicados. Cerca de 4h40 depois, retratou-se. A notificação inicial aos usuários falava em janela de quatro horas (21:00 de 14/10 a 01:00 de 15/10, horário local, equivalente a 13:00–17:00 UTC). O relatório de 19/10 registra atividade de 14/10 01:36 a 15/10 21:05, uma janela de dezenas de horas. Os horários do relatório não trazem fuso nas partes que li. A diferença de escala entre a primeira nota e o relatório preliminar é, ela mesma, informação sobre a capacidade de detecção da empresa. Em agosto, relatos de usuários indicam que a Zeabur soube do ataque por aviso externo e que o primeiro comunicado subestimou o impacto.
Contexto de agosto e o CVE: no primeiro incidente (27/08), o relatório da empresa diz que o ataque começou numa vulnerabilidade em um serviço público de usuário e atravessou quatro fronteiras: rede interna do cluster compartilhado, contas da plataforma, conta AWS e produção. O serviço era NextChat. A imprensa técnica taiwanesa liga a entrada ao CVE-2026-7644, falha de autorização em addMcpServer em NextChat até a versão 2.16.1; os registros do CVE confirmam a falha, mas a ligação com a Zeabur vem de fontes secundárias, e não li o número do CVE na página do relatório. O CVE é de software de terceiros e se refere a agosto, não ao incidente de outubro. Uma fonte chinesa que li atribui a falha a um 'RCE no AI Hub'; isso não bate com o relatório da própria Zeabur, e descartei. Um blog taiwanês menciona também uma alegação de fórum na dark web sobre 612 GB de banco e código-fonte, sobre a qual a Zeabur teria dito que a evidência existente não a sustenta; não encontrei confirmação primária e não conto como evidência.
O encerramento: a Zeabur disse que vai suspender os clusters compartilhados e as renovações de servidores dedicados em 01/12 e encerrar tudo em 31/12/2026. A carta do fundador atribui a decisão também à complexidade crescente da plataforma e ao ritmo de crescimento impulsionado pela IA, e diz que as duas invasões foram o ponto em que esses problemas apareceram. Ou seja, a causalidade 'hack levou ao fechamento' é a leitura da imprensa; a empresa descreve uma soma de fatores, e não dá para separá-los de fora. Um órgão local de proteção ao consumidor de Taipei comentou apenas a devolução de saldos na moeda original do pagamento. Não encontrei manifestação de autoridade de proteção de dados.
Cronologia
- 27 ago 2026Primeiro incidente: o atacante entra por um serviço de usuário (NextChat) num cluster compartilhado, chega a chaves Legacy API, depois a credenciais AWS e ao banco de produção. A Zeabur envia o primeiro aviso em 28/08, 08:53, e o segundo às 17:03.
- 07 set 2026A Zeabur publica o relatório do incidente de agosto (data informada pela imprensa taiwanesa; a página do relatório que li não mostra a data).
- 14 out 2026Início da atividade do atacante em outubro, segundo o relatório preliminar: chaves AWS internas a partir de 01:36 e tokens de administrador do cluster compartilhado a partir de 01:40. Às 13:40, login como root em 101 servidores dedicados no GCP. O relatório que li não declara o fuso dos horários.
- 15 out 2026Às 15:30, o atacante adiciona um nó à rede interna a partir de um servidor GCP comprometido. A última atividade registrada é às 21:05. Todos os usuários são deslogados e os tokens de acesso da plataforma são revogados.
- 16 out 2026A página de status publica a primeira nota (00:08) e a retrata cerca de 4h40 depois, dizendo que o incidente é mais amplo e que o atacante tinha leitura no banco de dados.
- 17 out 2026O fundador, Yuanlin Lin, avisa os usuários por e-mail que a plataforma será encerrada em etapas e abre reembolso de saldo e pedidos de indenização.
- 19 out 2026A Zeabur publica o relatório preliminar do incidente de outubro.
- 20 out 2026A página de status marca o incidente como resolvido e o BleepingComputer publica a matéria que originou o nosso registro.
Dados envolvidos
Impacto
Afeta os 321.810 titulares de conta, cujos e-mail, usuário e telefone foram lidos, e qualquer cliente com variáveis de ambiente no cluster compartilhado ou em servidores GCP dedicados. Isso inclui chaves de IA, senhas de banco, credenciais de nuvem e chaves de assinatura, que equivalem a acesso a sistemas de terceiros. Quem já havia migrado as variáveis para o próprio servidor dedicado, como a Zeabur orientou após agosto, ficou fora da leitura do banco, embora hosts comprometidos ainda possam expô-las. Para os 92 usuários de servidores GCP com root comprometido, a Zeabur recomenda reconstruir o servidor. O impacto operacional é o fim do serviço: migração obrigatória até 31/12/2026, com reembolso de saldo e indenização por perdas solicitados separadamente ao suporte. Quem foi afetado em agosto pode ter tido segredos expostos duas vezes.
Elos técnicos
Recomendações
- Trate como comprometido todo segredo que esteve em variável de ambiente na Zeabur desde 27/08/2026, não só desde outubro. Rotacione primeiro credenciais de nuvem, chaves de assinatura (JWT, sessão) e senhas de banco. Revogue as antigas só depois de emitir as novas.
- Procure uso indevido desde 27/08: logs de auditoria de nuvem (CloudTrail e equivalentes), acessos a bancos a partir de IPs desconhecidos e faturamento e uso das APIs de IA. Preserve esses registros antes de rotacionar.
- Em servidores GCP dedicados na Zeabur, reconstrua em vez de limpar. Troque a senha root, remova chaves SSH desconhecidas em authorized_keys e confira nos logs do GCP discos anexados a VMs que você não criou e snapshots inesperados.
- Revise a instalação de GitHub App da Zeabur no seu GitHub: escopos concedidos, logs de auditoria da organização no período e chaves de deploy. Considere revogar e reinstalar se for migrar.
- Se usou o zSend, gere novas chaves e revise o histórico de envio e a reputação do domínio (SPF, DKIM, DMARC) à procura de mensagens que você não enviou.
- Na migração, não leve segredos antigos. Crie os novos no destino, com escopo mínimo e prazo de validade, e confirme que nenhum serviço NextChat até a v2.16.1 segue exposto.
- Para quem opera plataformas: tire credenciais de repositórios e de configuração de inicialização, use segredos com escopo e expiração, não deixe interfaces administrativas e SSH públicos, e mantenha isolamento e monitoramento em infraestrutura em desativação, que foi a porta de entrada nos dois incidentes.
- Fique atento a phishing contra o seu e-mail ou telefone cadastrado: esses dados de conta foram lidos.
Lacunas de inteligência
O que ainda não sabemos. Um relatório que não declara seus buracos está vendendo, não analisando.
Como o atacante obteve as chaves AWS e os tokens do cluster. Só o relatório final da Zeabur, ou uma análise forense independente, resolve.
Se a chave de GitHub App vazada em agosto foi o elo entre os dois incidentes. Um confronto entre o log de uso da chave e o repositório de configuração resolveria.
Quem é o atacante, se é o mesmo de agosto e se há motivação financeira. Resolveria uma reivindicação, uma oferta de dados ou evidência técnica comum aos dois incidentes.
O fuso e a janela exata da atividade. O relatório que li não declara o fuso; o texto integral, com a linha do tempo, esclareceria.
Se os segredos de outubro foram usados e com que impacto financeiro. Dados de uso indevido reportados por clientes e provedores, ou a política de indenização, esclareceriam.
Se alguma autoridade de proteção de dados recebeu notificação, em Taiwan ou em outras jurisdições dos usuários. Não achei manifestação pública de nenhuma; comunicado do regulador ou da Zeabur resolveria.
Quantos dos 321.810 titulares estão em cada país. Sem essa distribuição não dá para dizer quais regimes de notificação se aplicam.
A existência real da alegação de 612 GB do fórum, ligada a agosto. Só captura primária do post ou resposta da Zeabur resolveria.
Fontes e avaliação
Notação Admiralty (padrão NATO, usado por CERT-EU e OpenCTI): a letra avalia a confiabilidade da FONTE (A completamente confiável a F não avaliada); o número avalia a credibilidade da INFORMAÇÃO (1 confirmada a 6 não julgável). As duas dimensões são avaliadas de forma independente — fonte boa não torna informação frágil confiável.