Vazamento na Railway: como rotacionar segredos com os deploys pausados

O incidente de segurança da Railway (abre em nova aba) criou uma situação estranha. A recomendação oficial é rotacionar todos os segredos imediatamente. Só que os deploys estão pausados. Quando você revoga uma chave antiga, a aplicação em produção, que ainda usa essa chave, para de funcionar. E você não consegue fazer o deploy da chave nova porque os builds não voltaram.

Este guia trata desse problema específico: rotacionar com o pipeline travado. Ele cobre o que a Railway admitiu até agora, a ordem em que eu revogaria as credenciais, como trocar as variáveis dentro da plataforma, como procurar sinais de abuso e o que continua sem resposta.

O que a Railway confirmou até 22 de outubro

O aviso publicado no blog da empresa em 21/10/2026, assinado por Jacob Cooper, diz que a Railway detectou "atividade anômala envolvendo sistemas que armazenam variáveis de ambiente de clientes". Segundo a investigação até aquele momento, um terceiro não autorizado pode ter acessado variáveis criptografadas e, para parte delas, obtido o conteúdo descriptografado. Esse segundo detalhe pesa mais que o primeiro. Para essa parcela, "estava criptografado" deixou de valer como defesa.

O mesmo texto traz o contexto que muda a prioridade para quem trabalha com IA. A Railway acredita que o ataque faz parte de uma série recente contra empresas de plataforma, "com o objetivo de comprometer provedores de inferência de IA". A empresa afirma ter notificado esses provedores para revogarem todas as chaves de forma proativa. A análise inicial sugere impacto restrito a um subconjunto de usuários. Mesmo assim, a recomendação vale para todos: rotacionar todas as variáveis de ambiente, incluindo chaves de API e credenciais de registries privados, e revisar os logs dos serviços. As contas afetadas serão avisadas por e-mail conforme forem confirmadas.

O fundador da Railway, Jake, foi mais direto no X. A frase dele importa porque fala em servidores comprometidos, e não apenas em "atividade anômala":

Hoje, fomos alertados sobre atividade maliciosa que comprometeu os servidores da Railway. Estamos compartilhando isso com vocês de forma ampla e rápida. Recomendamos que as pessoas rotacionem suas chaves por excesso de cautela.

— Jake (@JustJake), 21 de out. de 2026, no X

A página do incidente (abre em nova aba) mostra a sequência em UTC. Os textos do blog e da status page circularam primeiro por terceiros, então vale abrir a página você mesmo antes de agir.

• 21/10, 07:24: começa a investigação. O incidente aparece como Major Outage e afeta builds em US West, EU West, Southeast Asia e US East, a API (backboard.railway.com) e o suporte.
• 09:28: problema identificado. Dashboard, API e CLI ficam indisponíveis e novos builds são pausados em todas as regiões.
• 19:30: a Railway anuncia reativação escalonada: primeiro Enterprise, depois Pro, Hobby, Free e Trial.
• 21:59: sai o aviso de segurança. Os deploys continuam pausados, inclusive para Enterprise, "então as aplicações ainda não podem ser atualizadas com novas credenciais".
• 22:10: a Railway passa a rotacionar todas as credenciais dos buckets da própria plataforma. As novas aparecem automaticamente no dashboard, mas os serviços só podem ser redeployados quando os builds voltarem.
• 22/10, 01:22: saem guias por provedor: OpenRouter, PostgreSQL, Grok, buckets/GitHub, Anthropic, OpenAI, Stripe, GitHub, MongoDB, Redis, MySQL, AWS e GCP.
• 02:19: builds ainda fora do ar, sem mudança desde a atualização anterior.

Uma consequência prática passa despercebida. Se os provedores de inferência atenderam ao pedido de revogação proativa, suas chaves de LLM podem já estar mortas, quer você tenha feito algo ou não. Não há confirmação pública de quais provedores revogaram, nem de quando. Se seu serviço começou a devolver erro de autenticação da OpenAI ou da Anthropic, esse é um suspeito forte.

Vale a pena fazer isso tudo?

Para quem tem qualquer credencial de verdade numa variável da Railway, sim, e não é exagero. A própria empresa diz que parte do conteúdo foi descriptografada e que o atacante mira justamente chaves de inferência. Esperar o e-mail dizendo "sua conta foi afetada" é apostar que a triagem deles será rápida e completa, numa semana em que a plataforma inteira está em incidente.

Há três situações em que eu faria menos:

• Projeto hobby sem chaves pagas nem dados sensíveis. Revogue tudo de uma vez, aceite o downtime e pule o planejamento de transição deste guia. Coordenar a troca só compensa quando a indisponibilidade custa caro.
• Credenciais de bucket gerenciadas pela Railway. A empresa diz que já está rotacionando todas elas. Você só precisa redeployar quando os builds voltarem.
• Migrar de plataforma agora. É tentador, mas, feito no meio do incidente, você vai copiar para outro lugar os mesmos segredos que podem ter vazado. Rotacione primeiro e decida sobre migração depois do postmortem.

Variáveis que não são credenciais, como PORT, NODE_ENV ou nomes de modelos, não precisam ser trocadas. A Railway fala em "todas as variáveis", mas o objetivo de rotacionar é invalidar algo que dê acesso. Um número de porta não dá acesso a nada.

Pré-requisitos

Passo a passo

1. Faça o inventário antes de revogar qualquer coisa

Abra cada serviço, entre em Variables e copie os nomes das variáveis para uma planilha. Os valores não precisam ir para lá. Separe três grupos:

• Variáveis do serviço: definidas direto ali.
• Variáveis compartilhadas: definidas em Project Settings e usadas por vários serviços. Segundo o guia da Railway, você edita uma vez e todos os serviços que a referenciam recebem a mudança.
• Variáveis de referência: apontam para o valor de outro serviço, como uma DATABASE_URL que vem do serviço do Postgres, normalmente no formato ${{Postgres.DATABASE_URL}}. Você não troca esse valor onde ele é consumido. Troca na origem, e os consumidores pegam o novo valor no próximo deploy.

Os dois últimos grupos são a razão de fazer o inventário. Uma chave compartilhada usada por cinco serviços derruba os cinco quando você a revoga. Melhor descobrir isso agora do que em produção.

2. Decida, chave por chave, revogar agora ou na virada

A pausa dos deploys obriga a uma escolha por credencial:

• Revogar agora: o atacante perde acesso imediatamente, e o seu serviço também.
• Preparar a nova e revogar a antiga quando os builds voltarem: sem downtime, mas a chave possivelmente vazada continua válida por horas.

Minha regra é olhar o que a chave permite fazer com o seu dinheiro ou com os seus dados. A Railway diz que o alvo do ataque são provedores de inferência. Chaves de LLM, portanto, estão no topo, pelo motivo declarado do ataque e não só por cautela genérica.

A tabela é uma heurística, não um decreto. Se a sua API de LLM atende clientes pagantes e um downtime de horas sai mais caro que o risco, a alternativa é criar a chave nova agora, deixar a mudança preparada na Railway e apagar a antiga no minuto em que o deploy passar. Nesse caso, acompanhe o consumo da chave antiga sem parar enquanto ela existir.

3. Revogue e reemita fora da Railway

Cada provedor se comporta de um jeito, e isso afeta o plano.

AWS. O guia da Railway manda abrir o console do IAM e buscar o ID da access key exposta para descobrir a qual usuário ela pertence. Na aba Security credentials desse usuário, você clica em Create access key para gerar a substituta e, na chave exposta, usa Actions → Deactivate. A partir daí, requisições assinadas com a chave antiga falham. Desativar é diferente de apagar: a chave pode ser reativada. Isso dá uma saída se você descobrir uma dependência esquecida. Reativar uma chave exposta, porém, deveria ser o último recurso. Pela CLI da AWS:

# descobrir quando a chave foi usada pela última vez
aws iam get-access-key-last-used --access-key-id AKIAEXEMPLO

# criar a substituta para o mesmo usuário
aws iam create-access-key --user-name usuario-do-servico

# desativar a exposta (reversível; delete-access-key é definitivo)
aws iam update-access-key --user-name usuario-do-servico \
  --access-key-id AKIAEXEMPLO --status Inactive

OpenAI. Segundo o guia da Railway, que adapta a orientação da própria OpenAI (abre em nova aba), apagar uma chave tem efeito imediato. O detalhe que confunde: chaves de projeto e chaves legadas de usuário ficam em páginas diferentes. Uma chave de projeto se apaga na página de API keys daquele projeto. Chaves de organização ou legadas, em Organization API keys. Se uma Admin key também pode ter vazado, ela fica em Admin keys, e só owners da organização conseguem apagá-la. Crie a nova chave secreta no mesmo projeto.

OpenRouter. Aqui a Railway alerta que apagar é permanente e que seus serviços não alcançam a OpenRouter (abre em nova aba) até a chave nova ser deployada. Por isso o guia fala em desativar a chave exposta. Antes de desativar, porém, há um passo opcional que vale ouro: consultar a própria chave diretamente. A resposta traz usage, usage_daily, usage_weekly e usage_monthly em créditos, além de limit_remaining se a chave tiver teto. Depois de desativada, você perde essa visão rápida. Guarde esses números para comparar mais tarde.

Anthropic, Grok, GitHub, Stripe, bancos. A Railway publicou guias específicos para cada um, e os passos variam. O padrão é o mesmo: criar a nova, invalidar a antiga e conferir o histórico. Para bancos hospedados na própria Railway, siga o guia de PostgreSQL, MySQL, MongoDB ou Redis. Trocar a senha no banco e esquecer de atualizar as variáveis que montam a string de conexão é um jeito fácil de derrubar tudo.

Não esqueça os lugares fora da Railway. O guia da AWS lembra que desenvolvimento local e CI que usavam a chave antiga também precisam ser atualizados.

4. Prepare a troca dentro da Railway

O fluxo descrito nos guias é sempre o mesmo: abrir o serviço, clicar em Variables, editar o valor e fazer o deploy da mudança preparada (staged). Para variáveis compartilhadas, a edição acontece uma vez em Project Settings.

O detalhe que salva horas: editar a variável não muda o processo que está rodando. A mudança fica preparada até o próximo deploy. Com os builds pausados, você pode deixar todas as trocas prontas agora e só aplicá-las quando a sua faixa de plano for reativada. Se esse estado preparado vai sobreviver intacto à reativação, a Railway não disse. Confira as variáveis de novo antes de deployar.

Dashboard, API e CLI ficaram indisponíveis durante parte do incidente, segundo a status page. Se a CLI ou a API estiverem de volta e você preferir automatizar, use as operações de variáveis da sua versão da CLI e confirme a sintaxe com --help antes. Não vale a pena descobrir uma flag errada no meio de uma rotação de segredos.

5. Faça o deploy assim que os builds voltarem

A reativação foi anunciada de forma escalonada: Enterprise, Pro, Hobby, Free e Trial, nessa ordem. Quando a sua vez chegar:

1. Confira se as variáveis preparadas estão com os valores novos.
2. Faça o deploy.
3. Confirme que o novo deployment está ativo.
4. Só então apague as chaves antigas que você deixou vivas de propósito no passo 2.

Como verificar

A verificação tem duas perguntas: a rotação funcionou, e alguém usou a chave antes de você revogá-la?

A rotação funcionou? Olhe os logs do novo deployment. Para AWS, a Railway diz para procurar chamadas bem-sucedidas e a ausência de InvalidClientTokenId ou SignatureDoesNotMatch. O primeiro erro costuma indicar que o ID da chave não é reconhecido. O segundo, que o secret não bate com o ID, um sintoma clássico de atualizar só uma das duas variáveis. Para OpenAI e OpenRouter, o critério é o mesmo: requisições com sucesso nos logs. Se algum erro aparecer, procure de onde vem a credencial velha:

# erros típicos de credencial AWS antiga ou incompleta nos logs exportados
grep -E "InvalidClientTokenId|SignatureDoesNotMatch" deploy.log

Alguém usou a chave? Aqui cada provedor oferece uma lente diferente:

• OpenAI: o painel de uso separa gastos por projeto e por ID de chave. Procure consumo associado à chave exposta que não acompanhe o seu tráfego real. A própria Railway resume o sinal de alerta assim: o gasto subiu sem mudança correspondente no tráfego.
• OpenRouter: a página Activity agrupa requisições por modelo, provedor, chave de API, app e usuário. Modelos que você nunca chama são um indício forte. Compare com os números de usage que você guardou antes de desativar.
• AWS: o guia manda revisar o CloudTrail e o faturamento. Uma busca por ID de chave é um bom começo:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXEMPLO \
  --max-results 50

Fique atento a regiões que você não usa, criação de usuários ou chaves no IAM e instâncias novas. Lembre que o lookup-events cobre eventos de gerenciamento recentes. Acesso a dados em S3, por exemplo, só aparece se você já tinha data events habilitados.

• Bancos: consulte os logs de conexão do banco e procure origens e horários estranhos, além de volumes de leitura incomuns.
• Railway: a recomendação oficial é revisar os logs dos serviços em busca de atividade incomum.

Anote o que encontrar, com horário. Se a Railway entrar em contato dizendo que sua conta foi afetada, essas anotações viram a sua linha do tempo. Se você achar uso indevido na OpenAI, a orientação citada pela Railway é acionar o suporte do provedor. O suporte da Railway responde em [email protected].

Erros comuns

• Revogar a chave compartilhada sem saber quantos serviços dependem dela. É o motivo do inventário. Uma variável em Project Settings derruba todos os serviços que a referenciam.
• Atualizar só metade do par. AWS_ACCESS_KEY_ID novo com AWS_SECRET_ACCESS_KEY velho resulta em SignatureDoesNotMatch.
• Achar que editar a variável já resolveu. Sem deploy, o processo continua com o valor antigo. Com os builds pausados, a chave nova ainda não está em uso.
• Apagar a chave errada na OpenAI. Projeto, organização/legada e Admin ficam em lugares diferentes. Apagar a de projeto e esquecer uma Admin key exposta deixa a porta mais perigosa aberta.
• Apagar na OpenRouter quando a intenção era desativar. A Railway avisa que apagar é permanente. Junto com a chave, vai embora a consulta rápida de uso.
• Esquecer o resto do mundo. .env local, segredos do CI e outros ambientes que usavam a mesma chave. Uma chave revogada que ainda está no CI quebra o próximo pipeline. Uma chave reutilizada que ninguém revogou continua exposta.
• Rotacionar à mão as credenciais de bucket da Railway. A empresa diz que está fazendo isso e que as novas aparecem sozinhas no dashboard. Se você ver revogações feitas por um funcionário da Railway nos buckets, a status page informa que isso é esperado.
• Interpretar "subconjunto de usuários" como "não foi comigo". A própria Railway recomenda que todos ajam enquanto a triagem não termina.

O que ainda não se sabe

Até a manhã de 22 de outubro, várias perguntas continuavam abertas. Elas afetam decisões que você está tomando agora.

• Vetor de acesso: a Railway falou em sistemas que armazenam variáveis e numa campanha contra plataformas. Não detalhou como o atacante entrou nem como obteve conteúdo descriptografado.
• Janela temporal: a investigação começou às 07:24 UTC de 21/10, mas não há indicação pública de desde quando o acesso existia. Isso define até onde você precisa voltar nos logs. Na dúvida, volte mais do que um dia.
• Variáveis seladas: a Railway oferece variáveis sealed, e não há, no material publicado até aqui, nenhuma afirmação de que elas ficaram protegidas. Trate-as como expostas até a empresa dizer o contrário com detalhes.
• Revogação nos provedores: a Railway diz ter pedido revogação proativa. Não está claro quais provedores atenderam, para quais chaves e quando.
• Retorno dos builds: a ordem por plano foi anunciada, mas a atualização das 02:19 UTC ainda não trazia previsão. Também não há garantia publicada de que a plataforma restaurada esteja livre do acesso original. Essa garantia é o que um postmortem deveria responder.

A lição que fica independe do postmortem: segredo guardado em plataforma de deploy é exatamente tão seguro quanto a plataforma, e o seu plano de rotação precisa funcionar justamente no dia em que essa plataforma estiver fora do ar.