A Railway (abre em nova aba) é uma plataforma onde desenvolvedores e empresas colocam seus aplicativos para funcionar na nuvem. Na quarta-feira (21), a empresa informou que um terceiro não autorizado pode ter acessado as variáveis de ambiente de seus clientes e, em parte dos casos, lido o conteúdo já decifrado. No mesmo comunicado, pediu que todos trocassem essas informações imediatamente. Avisou também que, enquanto investiga, ninguém pode publicar uma nova versão de nada.
"Variável de ambiente" é o nome técnico de uma coisa simples: a gaveta onde o programa guarda as senhas de que precisa para trabalhar. Ficam ali chaves de serviços de inteligência artificial, senhas de bancos de dados e credenciais da Amazon Web Services, do Stripe e do GitHub. Tudo era guardado criptografado. Segundo a própria Railway, no caso de alguns clientes o invasor conseguiu abrir a gaveta.
O alvo eram as chaves de IA
A Railway diz acreditar que o ataque faz parte de uma série recente contra empresas de plataforma. O objetivo seria chegar aos provedores de inferência de IA, as companhias que vendem acesso a modelos como os da OpenAI (abre em nova aba) e da Anthropic (abre em nova aba). Faz sentido. Uma chave dessas funciona como dinheiro: quem a tem usa o modelo, e a conta vai para o dono. Os guias publicados pela empresa mandam o cliente procurar exatamente esse rastro: gasto na OpenAI que subiu sem aumento de tráfego, saldo de créditos no OpenRouter (abre em nova aba) que caiu sem explicação. A Railway diz ter pedido a esses provedores que revogassem todas as chaves por precaução.
A empresa afirma que o impacto pode se limitar a um grupo de usuários, mas recomenda as mesmas providências a todos. Promete avisar por e-mail os clientes cujas contas forem confirmadas como afetadas.
Troque a fechadura, mas fique do lado de fora
Aqui está o nó. Trocar uma chave tem duas etapas. Primeiro se cancela a velha no serviço de origem. Depois se coloca a nova no aplicativo, o que exige um novo deploy, a publicação de uma versão atualizada. A segunda etapa está bloqueada. Às 18h59 (horário de Brasília), a página de status da Railway reconheceu que os deploys seguiam pausados até para os clientes Enterprise, os que pagam mais. Os aplicativos, portanto, ainda não podiam receber credenciais novas.
O guia do OpenRouter põe o problema por escrito: apagar a chave é permanente, e os serviços hospedados na Railway ficam sem acesso ao OpenRouter até a substituta ser implantada. O cliente ficou entre duas escolhas ruins. Pode revogar agora e tirar o próprio produto do ar. Ou pode esperar e deixar ativa, sem prazo conhecido, uma chave que talvez esteja nas mãos de outra pessoa. Para quem paga IA por uso, esperar pode sair mais caro do que algumas horas fora do ar. A recomendação da Railway está certa. O problema é que a empresa recolheu a ferramenta necessária para segui-la.
A Railway também está trocando por conta própria as credenciais dos seus serviços de armazenamento de arquivos, os "buckets". As novas aparecem sozinhas no painel, mas só passam a valer nos aplicativos quando os deploys voltarem. Se o cliente vir no histórico que um certo Faraz Patankar revogou suas credenciais, não precisa se alarmar. É funcionário da Railway, e a empresa avisou que isso é esperado.
Treze horas de "pane"
A cronologia da página de status (abre em nova aba), em horário de Brasília, mostra a sequência:
- 4h24 de quarta: começam as atualizações sobre uma pane classificada como grave.
- 6h28: a empresa diz ter identificado o problema. Painel, API e linha de comando estão fora do ar, e a preparação de novas versões (os "builds") está parada em todas as regiões.
- 16h30: anuncia uma volta escalonada: primeiro Enterprise, depois Pro, Hobby, Free e Trial.
- 17h44 a 18h59: o aviso de segurança sai no blog e chega à página de status.
- 22h22: saem 13 guias de troca de chaves, entre eles OpenAI, Anthropic, Grok, Stripe, AWS, GCP, PostgreSQL e MongoDB.
- 23h19: os builds continuam parados, sem novidade.
O comunicado diz que a atividade suspeita foi detectada logo de manhã. Durante mais de treze horas, o público viu uma pane. Só no fim da tarde soube que era um caso de segurança. Investigar leva tempo, e anunciar errado custa caro. Mas a chave de quem foi atingido ficou exposta durante todo esse intervalo. A fila da volta, com quem paga mais na frente, segue a lógica comercial. O vazamento não seguiu: atingiu igualmente quem paga muito e quem não paga nada.
O fundador da Railway, Jake Cooper, levou o caso ao X. A mensagem é mais direta que o comunicado oficial: fala em servidores comprometidos, e não em acesso "possível". A promessa de rapidez que ela faz deve ser lida ao lado da cronologia acima.
Hoje, fomos alertados sobre uma atividade maliciosa que comprometeu os servidores da Railway. Estamos compartilhando isso com vocês de forma ampla e rápida. Recomendamos que as pessoas troquem suas chaves, por excesso de cautela.
O que fazer agora
Vale para quem tem um aplicativo na Railway e para quem contratou alguém que mantém um lá:
- Considere vazada toda chave guardada na Railway, incluindo as credenciais de registros privados.
- Confira os gastos. Na OpenAI, o painel de uso separa o consumo por projeto e por chave. No OpenRouter, a página Activity agrupa os pedidos por modelo, chave e aplicativo. Na AWS, olhe o CloudTrail e a fatura.
- Crie a chave nova e desative a antiga. Na AWS, isso se faz no console IAM. Depois da desativação, qualquer pedido feito com a chave velha é recusado.
- Quando os deploys voltarem, edite as variáveis e publique de novo. Variáveis compartilhadas entre serviços se alteram uma única vez, nas configurações do projeto. Depois, confira nos registros do aplicativo se as chamadas voltaram a funcionar.
- Troque a chave também fora da Railway, em qualquer lugar que usava a mesma credencial, como o computador de desenvolvimento ou os sistemas de integração contínua.
A Railway fez parte do que se espera de uma empresa atingida: contou o que houve, pediu a troca das chaves e publicou manuais. O episódio, porém, deixa uma lição. Com a IA cobrada por uso, cada chave de API virou dinheiro vivo, e as plataformas que guardam as chaves de muitos clientes num só lugar viraram alvo preferencial. Quem guarda segredo em gaveta alheia precisa saber quanto tempo leva para trocá-lo quando a gaveta é arrombada, e se o dono da gaveta vai deixar.