Invasões em duas plataformas de hospedagem para desenvolvedores, em outubro de 2026, alcançaram variáveis de ambiente e chaves de IA

Duas plataformas de hospedagem usadas por desenvolvedores sofreram invasões em outubro de 2026, e ambas as empresas dizem que o atacante buscava chaves de serviços de IA guardadas em variáveis de ambiente.

Entre 14 e 15 de outubro de 2026, a Zeabur teve o cluster compartilhado, parte dos seus servidores dedicados e sistemas internos acessados por um atacante que usou credenciais internas vazadas, até chegar ao banco de dados da plataforma.

Pouco depois, a Railway identificou uma intrusão entre 20 e 22 de outubro de 2026 que levou à descriptografia de um subconjunto de variáveis de ambiente armazenadas na plataforma.

Este texto reúne o que as duas empresas publicaram em comunicados oficiais, separa o que cada uma provou do que ainda é hipótese e aponta o que a investigação precisa responder.

Os horários abaixo seguem o UTC, como nos comunicados das empresas.

Zeabur: o acesso começou por credenciais em texto puro

O comunicado da Zeabur, publicado em 19 de outubro de 2026 e escrito em inglês, descreve dois caminhos de acesso que se encontraram dentro da rede interna da empresa.

O primeiro caminho passou por chaves AWS internas e por tokens de administrador do cluster compartilhado, usados a partir de 14 de outubro de 2026, às 01h36 e às 01h40.

Essas credenciais estavam guardadas em texto puro num repositório privado de configuração, e a empresa não consegue confirmar como o atacante chegou a elas.

A interface de administração do cluster estava aberta à internet pública naquele momento, e os tokens não tinham data de expiração, pois tinham sido criados em janeiro de 2024.

Com esses tokens, o atacante leu as configurações e os segredos de todos os serviços do cluster em 9 regiões, e a Zeabur só confirma a leitura nas regiões que têm registros completos.

Nas regiões sem registros, a empresa trata o conteúdo como vazado, porque não há como conferir o que foi lido.

Entre 13h40 e 17h04 do dia 14, o atacante também executou comandos dentro de contêineres de bancos de dados de clientes, em 865 serviços, embora nem todos os comandos tenham funcionado.

Os registros de auditoria guardam os comandos, mas não guardam o que eles devolveram, então a empresa não consegue medir quanto de cada banco foi de fato copiado.

Zeabur: o banco de dados da plataforma e as contas

No dia 15, entre 16h10 e 16h47 UTC, o atacante leu o banco de dados de produção da plataforma com uma conta interna somente leitura, usando um nó que ele mesmo tinha adicionado à rede interna às 15h30.

A empresa cruzou os registros das duas pontas da rede interna com os registros do banco e atribuiu as 29 conexões desse período ao mesmo nó, somando 8.903 operações rastreáveis.

Os números confirmados pela Zeabur são 3.218.965 registros de variáveis de ambiente, 321.810 contas com dados de perfil como e-mail, nome de usuário e telefone, 566 chaves da API de envio zSend em texto puro e 11.536 tokens de acesso.

Os tokens de acesso estavam guardados apenas como resumo criptográfico, que não se reverte, e todos foram revogados.

Segundo a empresa, o atacante procurava chaves de API que pudesse usar diretamente, sobretudo de serviços de IA, e a Zeabur registra que essa leitura é apenas uma observação da intenção do atacante.

Para isso, ele procurou chaves em variáveis de ambiente e arquivos de configuração, leu credenciais de instâncias de n8n e de new-api e one-api, e tentou chamar o Amazon Bedrock com as chaves AWS da própria Zeabur, sem êxito.

Em 602 das 607 instâncias de n8n verificadas, a chave de criptografia estava numa variável de ambiente, de modo que as credenciais de terceiros guardadas ali ficaram efetivamente em texto puro.

A empresa também confirmou que o atacante leu a chave usada para assinar os logins, e avalia que ela foi usada para forjar acessos.

Entre 16h12 e 17h19 do dia 15, a API da Zeabur foi chamada como duas contas, uma delas de funcionário da empresa, e as listas de contas e projetos foram lidas sem alteração de recursos.

A chave de assinatura foi trocada às 20h25 do dia 15, e todos os usuários tiveram a sessão encerrada.

Zeabur: os servidores dedicados no GCP

Em paralelo, o atacante entrou como root em 101 servidores dedicados que a Zeabur administra no GCP, a partir de 14 de outubro, às 13h40 UTC.

As configurações de inicialização desses servidores guardavam a senha de root em texto puro, e a empresa avalia que uma chave antiga do GCP permitiu ler essas configurações.

Em 50 desses servidores, o atacante acrescentou chaves SSH sob seu controle, para manter acesso permanente.

Os registros confirmam ainda a criação de 5 máquinas virtuais no projeto da Zeabur no GCP, às quais foram anexadas 16 cópias de discos de servidores de clientes.

A empresa classifica os 101 servidores como afetados, com possível exposição de dados e possíveis mecanismos de acesso não autorizado deixados no lugar.

Railway: a escalada de privilégio e a descriptografia

A Railway informa que a intrusão ocorreu entre 20 de outubro, às 13h58 UTC, e 22 de outubro, às 03h32 UTC, quando a empresa confirmou que o atacante já não tinha acesso aos sistemas internos.

O ponto de partida foi uma escalada de privilégio na infraestrutura de build, detectada no dia 20, que levou a empresa a pausar os pipelines de compilação.

Na madrugada do dia 21, a empresa percebeu que o atacante conseguia puxar segredos em formato criptografado, e depois chegou a credenciais do ambiente de integração contínua, onde descriptografou artefatos que guardavam acessos adicionais de API.

Uma consulta registrada no banco mostrou a leitura não autorizada de variáveis de ambiente criptografadas, e a Railway diz que apenas um subconjunto foi descriptografado.

Como as chaves estavam protegidas em criptografia de envelope, a consulta sozinha não permite saber quais chaves de quais projetos foram afetadas.

Os registros das cargas do atacante, lidos pela equipe, mostraram os nomes das chaves de API que ele buscava, e os fornecedores foram avisados às 09h25 UTC do dia 21.

Railway: o alcance e o número de 1,85%

A Railway afirma que, pelo desenho de isolamento de chaves, no máximo 1,85% dos workspaces teve variáveis de ambiente potencialmente comprometidas.

A própria empresa converte esse percentual em cerca de 100.000 workspaces, mas diz que o número de usuários atingidos por pedidos de troca de chaves dos fornecedores foi maior.

Alguns fornecedores receberam a lista de todas as chaves armazenadas, e não apenas as chaves comprovadamente lidas, por precaução.

Como não consegue saber quais variáveis foram descriptografadas, a Railway contata os clientes com impacto definido e também os que considera de alto risco.

Segundo a empresa, o atacante buscava dois tipos de alvo, workspaces com muitas variáveis de ambiente e ambientes com muitas chaves de fornecedores de IA.

A Railway diz que nenhuma conta de usuário foi acessada, mas não descarta o acesso ao código-fonte e promete confirmar esse ponto no relatório forense final.

Na avaliação forense da empresa, o atacante provavelmente buscava chaves de IA e de plataformas de API para destilar modelos, e essa conclusão ainda é preliminar.

O que já está provado e o que não está

Pelos registros diretos citados pela Zeabur, estão provados a leitura de 53 segredos de produção entre 15 de outubro, às 14h52, e 16h51 UTC, a leitura do banco da plataforma e a entrada como root em 101 servidores.

Não estão provados o início exato do acesso indevido, a origem das credenciais iniciais e o alcance real da leitura dos bancos de clientes.

Na Railway, estão provados a escalada de privilégio, a obtenção de credenciais do ambiente de integração contínua e a descriptografia de um subconjunto de variáveis, mas não o conjunto exato das chaves afetadas.

A Railway também não divulgou detalhes técnicos das explorações, por cautela, e isso limita a análise de quem depende do relato para reconstruir o caminho do ataque.

O que a investigação precisa responder

A primeira pergunta é como o atacante obteve a credencial inicial da Zeabur, já que os registros do cluster e da AWS não mostram uso de credenciais válidas antes de 14 de outubro, às 01h36 UTC.

A segunda é quanto dos bancos de clientes foi copiado de fato, porque os registros guardam o comando e não a saída.

A terceira é se o código-fonte de clientes da Railway foi lido, ponto que a empresa diz estar em aberto.

A quarta é se as chaves descriptografadas foram usadas, e essa resposta depende dos registros dos próprios fornecedores de IA, e não só dos registros das plataformas.

A quinta é por que a detecção demorou: a Zeabur registra mais de 16 horas de atividade em 14 de outubro sem nenhum alerta, e a investigação começou só no dia 15, após o relato de um usuário.

Causa apontada pelas empresas e a correção de agosto

A Zeabur atribui a causa principal a credenciais administrativas de longa duração, guardadas em texto puro e utilizáveis a partir da internet pública.

A empresa admite que a troca feita após o incidente de agosto não cobriu os tokens de administrador nem as chaves AWS usadas agora.

Ela também reconhece que o relatório de agosto dizia que todas as chaves administrativas internas tinham sido desativadas ou trocadas, e que essa afirmação estava incompleta.

Uma hipótese da própria empresa liga o acesso inicial a uma chave de aplicativo do GitHub vazada em agosto, mas não há registro direto que comprove esse caminho.

Os downloads do repositório de configuração em 30 de agosto e 2 de setembro, feitos com a autorização de um funcionário, também ainda não têm autor identificado.

O que os clientes devem fazer segundo as empresas

A Zeabur pede a troca de todas as senhas e chaves guardadas na plataforma, inclusive as trocadas após agosto, e a revogação da credencial antiga no fornecedor antes de criar outra.

A empresa também registra que trocar as variáveis na plataforma não muda as senhas dentro dos bancos, e que a troca não invalida dados que já vazaram.

A Railway pede a revogação e nova aplicação das variáveis sensíveis armazenadas antes de 21 de outubro, além da remoção do acesso público aos bancos de dados.

A Railway também recomenda revisar os registros de auditoria do GitHub e dos registros de imagens de contêiner, para checar acessos e aplicativos autorizados.

Os dois comunicados dizem que as investigações continuam, e que as empresas vão publicar atualizações quando tiverem respostas mais completas.