O vazamento de variáveis de ambiente da Railway: o que a Railway confirmou, e o que muda num servidor que é seu

Em 21 de outubro de 2026, a Railway publicou uma divulgação de segurança: uma parte não autorizada obteve acesso aos sistemas que armazenam variáveis de ambiente de clientes, e para alguns clientes, obteve os valores descriptografados dessas variáveis. A Railway pausou todos os deploys em toda a plataforma, revogou seus próprios tokens de acesso, e pediu que cada cliente rotacionasse cada secret armazenado na plataforma. Isto é o que a própria Railway confirmou, o que ainda é de segunda mão, e a razão arquitetônica real pela qual um modelo onde você é dono do servidor muda o formato desse risco específico — não todo o risco, o formato desse em particular.

O que a própria Railway divulgou

A Railway publicou dois documentos que importam aqui: uma divulgação de segurança no mesmo dia, 21 de outubro, e um relatório preliminar de incidente mais longo alguns dias depois. Ambos seguem online no blog da Railway, e são a fonte primária de tudo a seguir.

Segundo o relatório preliminar da Railway, o ataque ocorreu entre 20 de outubro, 13h58 UTC, e 22 de outubro, 3h32 UTC — o segundo horário marca o momento em que a Railway confirmou que o atacante não tinha mais acesso a nenhum sistema interno. O primeiro sinal foi mundano: um alerta de monitoramento para o engenheiro de plantão por latência elevada. A investigação transformou isso em outra coisa rapidamente. Às 14h03 UTC do dia 20, a equipe da Railway já havia identificado uma tentativa de escalada de privilégios em sua infraestrutura de build e interrompeu os pipelines de build. Às 19h53 UTC naquele mesmo dia, novas evidências mostraram que o atacante conseguia escalar seu acesso “em maior escala, por várias partes do sistema Railway, em paralelo” — nesse ponto a Railway tratou isso como uma campanha sustentada e direcionada, não um bug isolado. Em 21 de outubro às 7h25 UTC, a perícia forense mostrou que o atacante havia alcançado o ambiente de CI da Railway e descriptografado artefatos contendo credenciais de API.

O próprio relato da Railway sobre a motivação do atacante é específico: o relatório diz que o atacante “estava tentando obter chaves de API de provedores de IA para realizar ataques de destilação”, e que evidências iniciais sugeriam que o atacante tinha acesso a “modelos abliterated e recursos computacionais substanciais” que permitiram uma exploração incomumente sofisticada da infraestrutura da Railway. Essa atribuição se sustentando ou não conforme a investigação avança, é a própria caracterização da Railway, não um palpite da cobertura externa.

A parte que chega diretamente aos clientes: o atacante acessou os sistemas internos da Railway e descriptografou variáveis de ambiente armazenadas para um subconjunto de workspaces de clientes. Os próprios números da Railway, publicados no relatório preliminar: no máximo 1,85% de todos os workspaces tiveram algumas variáveis de ambiente potencialmente comprometidas — cerca de 100.000 workspaces, segundo a contagem da Railway. A Railway diz que esse número se manteve porque seus sistemas são “construídos de forma que, se um conjunto de chaves for comprometido, isso não deveria comprometer todo o sistema” — ou seja, o raio de impacto foi contido por design, não por sorte. Separadamente, a Railway notificou diretamente um número maior (não especificado) de workspaces que julgou de alto risco com base na análise forense do que o atacante realmente estava mirando — principalmente workspaces com chaves de provedores de IA de alto valor. As contas individuais de usuários da Railway em si não foram acessadas nem comprometidas; isso foi sobre variáveis de ambiente ligadas aos workspaces, não sobre tomada de contas.

A resposta da Railway, em suas próprias palavras: todos os deploys foram pausados em toda a plataforma durante a triagem (os deploys já existentes continuaram online; o que parou foram novos builds e novos deploys saindo). A Railway revogou todos os seus próprios tokens de acesso “por excesso de cautela”. Notificou fornecedores parceiros — GitHub, GitLab, e provedores de IA entre outros — para que pudessem revogar proativamente as credenciais expostas, concluído às 9h25 UTC do dia 21 de outubro. Suas ações recomendadas para cada cliente: rotacionar cada variável de ambiente e chave de API armazenada na Railway, renovar credenciais de registro privado, remover acesso de rede pública a bancos de dados onde existisse, e revisar os logs de auditoria do GitHub e de registros Docker em busca de qualquer coisa incomum. Os deploys foram restaurados gradualmente a partir de 22 de outubro, com restauração completa mais tarde naquele mesmo dia.

Por que as variáveis de ambiente da Railway foram expostas?

Com base no que a Railway publicou, o caminho foi: escalada de privilégios dentro da infraestrutura de build da Railway, que deu ao atacante um ponto de apoio no ambiente de CI, que continha artefatos descriptografados com credenciais de API — e a partir daí, o acesso se estendeu aos sistemas que armazenam variáveis de ambiente de clientes, permitindo ao atacante descriptografar um subconjunto delas. Resumindo: um único sistema interno comprometido (build/CI) foi suficiente para alcançar um sistema diferente (o cofre de secrets criptografados) que, sozinho, deveria ter sido um alvo mais difícil. Esse encadeamento é a verdadeira lição, mais do que qualquer etapa isolada.

O que ainda é de segunda mão, não palavras da Railway

Alguns detalhes amplamente divulgados desde a revelação não vieram do próprio blog da Railway, e devem ser lidos como reportados, não confirmados. A pesquisadora de blockchain Taylor Monahan e vários veículos da indústria cripto reportaram que chaves privadas de carteiras armazenadas como variáveis de ambiente na Railway foram esvaziadas por um único endereço, com perdas reportadas em torno de US$ 371.000 em mais de 500 transações, em mais de 19 blockchains EVM, e um primeiro roubo com timestamp cerca de duas horas antes do aviso público da Railway. Os próprios materiais publicados pela Railway não mencionam uma cifra de roubo em cripto, um endereço de carteira específico do atacante, nem essa comparação de horários — esse enquadramento vem inteiramente de pesquisadores externos e dos veículos que os cobrem. É plausível, bate com o tipo de workspace que o atacante parecia priorizar, mas não é algo que este texto possa verificar além de “vários veículos reportaram isso, a Railway não confirmou nem negou a cifra específica em suas próprias publicações até o momento desta escrita.”

Por que um modelo BYO-server muda o formato do risco, honestamente

Seria fácil escrever esta seção como “o Railyard não tem esse problema.” Isso não é exato, e vale a pena ser preciso sobre o porquê.

O plano de controle do Railyard também armazena as variáveis de ambiente dos clientes de forma centralizada, criptografadas em repouso, em seu próprio banco de dados — usando a mesma abordagem geral (criptografia em repouso com uma chave mantida pelo servidor) que qualquer plataforma que armazena secrets de clientes, Railway incluída. Se o próprio banco de dados do plano de controle do Railyard e sua chave de criptografia fossem ambos comprometidos, a mesma classe geral de exposição que a Railway descreveu é estruturalmente possível aqui também. Ser dono do próprio servidor não muda o fato de que um painel central precisa guardar suas variáveis em algum lugar antes de poder entregá-las a um servidor — alguém precisa custodiar o secret entre o momento em que você o digita e o momento em que seu app o lê.

O que muda é o que acontece depois disso: onde a cópia descriptografada acaba vivendo, e o que um atacante precisa invadir para chegar a um secret vivo, descriptografado, realmente em uso. No caso da Railway, o caminho real que o atacante percorreu passou por infraestrutura de build e um ambiente de CI que fazem parte do próprio ambiente operacional compartilhado e multi-tenant da Railway — os mesmos sistemas que constroem e rodam as aplicações de todo mundo. Um bug de escalada de privilégios nessa infraestrutura compartilhada colocou o atacante em posição de alcançar secrets de workspaces que não tinham nada a ver com a vulnerabilidade original. A infraestrutura de build, o plano de controle, e o computação que roda o código do cliente estão todos dentro do perímetro interno de uma única empresa, então uma rachadura em qualquer um deles é potencialmente uma rachadura em todos.

Num modelo BYO-server, o plano de controle ainda precisa descriptografar as variáveis de um cliente em algum momento — mas faz isso para entregá-las, uma vez, no momento do deploy, a um servidor que está na própria conta de nuvem daquele cliente específico, não para uma frota de computação compartilhada que a plataforma opera. A cópia viva e descriptografada do ambiente de uma aplicação — a que um atacante realmente quer, porque é a que está na memória de um processo em execução — existe numa infraestrutura à qual os próprios engenheiros da plataforma não têm acesso permanente fora dessa única etapa de entrega. Um bug no próprio pipeline de build da plataforma é um risco real para os dados do plano de controle da plataforma (como em qualquer lugar), mas não dá a um atacante uma frota de computação compartilhada para pivotar em direção aos secrets vivos de outros clientes, porque não existe tal frota — o ambiente “vivo” de cada cliente é uma máquina diferente, numa conta diferente.

Essa é uma afirmação mais restrita do que “isso não pode acontecer”, e deveria ser: é especificamente sobre o raio de impacto através da computação compartilhada, não uma afirmação de que a criptografia do Railyard seja criptograficamente mais forte que a da Railway. O enquadramento honesto é que um modelo BYO-server elimina um caminho específico para o pior resultado — um atacante pivotando de um bug do lado da plataforma diretamente para os secrets vivos de muitos clientes não relacionados via infraestrutura de execução compartilhada — sem eliminar todos os outros caminhos, incluindo uma violação no próprio banco de dados do plano de controle e seu material de chaves, que continua sendo um risco que qualquer painel centralizado carrega, não importa onde a computação viva.

O que isso significa para você, independente da plataforma

Algumas conclusões práticas se aplicam esteja você na Railway, no Railyard, ou em qualquer outra coisa que guarde secrets num painel:

• Rotacione tudo que passa pelo painel de qualquer plataforma segundo um calendário regular, não só depois de uma divulgação de violação — chaves de API estáticas e de longa duração sentadas num cofre centralizado são um passivo permanente, independente de qualquer incidente específico.
• Restrinja o escopo das credenciais estritamente. Uma credencial de banco de dados que só consegue alcançar um único banco, ou uma chave de API com as permissões mínimas necessárias, limita o que uma cópia roubada realmente vale.
• Prefira os papéis IAM nativos do seu provedor de nuvem ou credenciais de curta duração em vez de secrets estáticos, onde o provedor permitir — uma opção que existe precisamente porque, num modelo BYO-server, a computação está na sua própria conta, então o sistema de identidade nativo da sua própria nuvem é uma opção, ponto.
• Pergunte, para qualquer plataforma que você use, o que precisa ser comprometido para chegar a um secret descriptografado realmente em uso — não só se o banco de dados está criptografado em repouso. Criptografia em repouso é o mínimo esperado; a pergunta real é quantos sistemas existem entre um bug numa parte não relacionada da plataforma e os secrets reais da sua aplicação em execução.

Veja a comparação completa: Railyard contra Railway, e o próprio modelo de variáveis de ambiente: Variáveis e secrets. Se você está migrando da Railway especificamente: Migrar da Railway.

Perguntas frequentes

Por que as variáveis de ambiente da Railway foram expostas? Segundo o próprio relatório preliminar da Railway, um atacante escalou privilégios dentro da infraestrutura de build da Railway, alcançou seu ambiente de CI, e a partir daí acessou os sistemas que armazenam variáveis de ambiente de clientes — descriptografando um subconjunto delas. A Railway não divulgou a vulnerabilidade técnica específica que permitiu a escalada inicial.

Quantos clientes da Railway foram afetados? O próprio número da Railway é no máximo 1,85% de todos os workspaces, cerca de 100.000, com algumas variáveis de ambiente potencialmente comprometidas. Um número maior e não especificado de workspaces julgados de alto risco foram notificados diretamente, separadamente.

A Railway confirmou o roubo de cripto reportado? Não. A cifra de aproximadamente US$ 371.000, o endereço de carteira específico, e a comparação de horários com o aviso público da Railway vêm todos de pesquisadores externos de blockchain e veículos especializados em cripto, não da divulgação publicada nem do relatório preliminar da própria Railway.

Hospedar no seu próprio servidor torna isso impossível? Não. O banco de dados do plano de controle de uma plataforma ainda precisa guardar seus secrets em algum lugar antes de implantá-los, e esse cofre continua sendo um alvo independente da arquitetura. O que muda é que a cópia viva e descriptografada rodando na sua aplicação vive no seu próprio servidor em vez de na frota de computação compartilhada da plataforma, o que elimina um caminho específico — um bug do lado da plataforma virando uma rota para os secrets vivos de outros clientes — sem eliminar todo o risco.

Fontes

• Security Disclosure: Wednesday October 21st — blog da própria Railway
• Preliminary Report: Oct 21st Security Incident — blog da própria Railway
• Railway discloses breach of encrypted environment variables, pauses all deployments — cobertura secundária
• Railway Security Flaw Puts Customer Funds in Crypto at Risk, Deployments Halted — cobertura secundária, as cifras de roubo em cripto reportadas aqui não são confirmadas pela Railway