Para: desenvolvedores e operadores que executam aplicações ou bancos de dados na Railway, a plataforma de hospedagem de aplicações (PaaS), especialmente os que guardam chaves de API de IA, pagamentos, GitHub, nuvem ou credenciais de banco de dados em variáveis de ambiente.
Este artigo se baseia nas publicações oficiais do blog da Railway (a divulgação, o relatório preliminar e os guias para usuários) e na sua página de status. Ele não trata de técnicas de ataque, que a empresa também não divulgou.
Em andamento: este artigo será atualizado conforme a organização publicar novas informações
Em 24 de outubro de 2026, 11:00 UTC (20:00 JST)Ainda não se sabe
- Quais variáveis de ambiente foram descriptografadas (a empresa diz que não consegue identificá-las)
- Se o código-fonte foi acessado (a ser confirmado no relatório final)
- Detalhes do ataque
- Se as chaves expostas foram usadas
O relatório preliminar da empresa é datado de 22 de outubro; segundo a página de status, foi disponibilizado às 16:38 UTC de 23 de outubro. A empresa diz que a investigação continua e que publicará um acompanhamento quando ela terminar. Não há data informada para o relatório final.
A página de status marcou o incidente como resolvido às 22:06 UTC de 23 de outubro; builds e deploys estão funcionando normalmente. Novos cadastros continuam pausados.
O que os usuários da Railway devem fazer hoje
Os passos 1 e 2 valem para todos os usuários. A empresa diz que o impacto pode ser limitado, mas recomenda essas ações a todos os usuários por precaução.
Rotacione os segredos: reemita na origem e revogue os valores antigos
A empresa pede que você revogue e reaplique todas as variáveis de ambiente sensíveis armazenadas na Railway antes de 21 de outubro. Isso inclui chaves de API e credenciais de registries privados.
Trabalhe nesta ordem:
- Liste suas variáveis de ambiente. Abra a aba Variables de cada serviço e marque os valores secretos (chaves de API, tokens, senhas, chaves de assinatura, strings de conexão)
- Emita novos valores no painel de cada origem: a API de IA, o provedor de pagamentos, o GitHub, a nuvem, bancos de dados externos etc.
- Atualize as variáveis da Railway e faça o redeploy dos serviços. Os contêineres leem as variáveis apenas na inicialização; por isso, continuam rodando com os valores antigos até o redeploy (guia da empresa)
- Quando os novos valores estiverem funcionando, revogue ou exclua os valores antigos na origem
Alterar o valor apenas dentro da Railway deixa o valor exposto utilizável até que você o revogue na origem (observação deste site).
Se você rotacionou antes das 03:32 UTC de 22 de outubro
Na divulgação de 21 de outubro, a empresa pediu que os usuários rotacionassem imediatamente todas as variáveis de ambiente. Depois, disse ter confirmado às 03:32 UTC de 22 de outubro que o invasor não tinha mais acesso aos seus sistemas. O relatório preliminar explica que a empresa queria expulsar o invasor antes de pedir a rotação, para que as novas credenciais não fossem comprometidas de novo logo em seguida. Por isso, é mais seguro rotacionar mais uma vez os segredos rotacionados antes das 03:32 UTC de 22 de outubro (observação deste site). A página de status diz que essa atualização, por si só, não exige repetir rotações já concluídas desde que o incidente foi contido.
Bancos de dados: regenere as senhas e remova o acesso público
A empresa aconselha todos os usuários a remover o acesso público de rede aos bancos de dados. O guia dela diz que um banco de dados com acesso público (o proxy TCP) habilitado pode ser alcançado com suas credenciais de qualquer lugar da internet até que você rotacione.
- Para PostgreSQL, MySQL, Redis e MongoDB, use Regenerate na tela do banco de dados. Ele altera a senha no banco e as variáveis em uma única etapa e encerra as sessões abertas (guia da empresa)
- Não edite manualmente variáveis de senha como POSTGRES_PASSWORD nem altere a senha diretamente no banco de dados. A variável e o banco ficam dessincronizados (guia da empresa)
- Faça o redeploy de todos os serviços que referenciam as variáveis (por exemplo,
${{ Postgres.DATABASE_URL }}). Substitua strings de conexão coladas por referências - Em Settings, Networking, desative o Public Access se nada fora do projeto precisar dele. Tudo o que estiver fora (desenvolvimento local, CI, ferramentas de BI) precisa receber o novo
DATABASE_PUBLIC_URLcolado manualmente
GitHub e registries: revise os logs de auditoria e os apps conectados
A empresa recomenda verificar os logs de auditoria do GitHub e o acesso de apps, além dos logs de auditoria de registries como o Docker Hub. O guia dela lista estas verificações:
- Conta pessoal: o log de segurança do GitHub (90 dias), os apps OAuth e GitHub Apps autorizados, as chaves SSH e GPG e os tokens de acesso pessoal. Revogue o que você não reconhecer e regenere os tokens
- Organização: o log de auditoria da organização (180 dias). Exporte o log antes de revogar qualquer coisa. Em cada repositório, revise deploy keys, secrets, webhooks e colaboradores
- GitHub Container Registry (ghcr.io): a Railway removeu os tokens do GitHub que armazenava, mas esses tokens continuam funcionando no GitHub até serem revogados. Exclua o token antigo no GitHub, crie um novo com o escopo read:packages e configure-o em cada serviço
O guia também alerta que um invasor com acesso de push pode adicionar um webhook ou secret que sobrevive à redefinição de senha.
APIs de IA e pagamentos: procure uso e cobranças que você não fez
Segundo o relatório preliminar da empresa, o invasor parece ter buscado chaves de API de provedores de IA. A empresa publicou guias de verificação de uso para OpenAI, Anthropic, OpenRouter, Grok, Stripe, AWS e GCP. O guia da OpenAI, por exemplo, orienta a:
- Excluir a chave possivelmente exposta e criar uma nova no mesmo projeto
- Abrir o uso, agrupar por chave de API e comparar o volume de tokens, o número de requisições e a mistura de modelos na janela de exposição com o seu tráfego normal
- Verificar na cobrança os gastos do período e quaisquer créditos consumidos
- Revisar os membros e a participação no projeto em busca de pessoas que você não convidou
- Guardar os detalhes de uso e contatar o suporte do provedor se encontrar uso indevido
Verifique pelo menos desde o início da janela do ataque (13:58 UTC de 20 de outubro) até o momento em que você rotacionou a chave (observação deste site).
Dentro da Railway: faça login de novo, recrie os tokens e faça o redeploy
Durante a resposta, a empresa revogou todas as sessões de login, os tokens de acesso da Railway, as conexões com o GitHub e as credenciais dos buckets de armazenamento. Os commits enviados enquanto os deploys estavam pausados não foram implantados.
- Faça login com a mesma conta Gmail, conta do GitHub ou e-mail com que você se cadastrou. Entrar com outra identidade cria uma conta nova e vazia (guia da empresa)
- Reconecte o GitHub nas configurações da conta, reconecte o repositório em Settings do serviço e faça o deploy do commit mais recente
- CLI: execute
railway logoute depoisrailway login. CI: recrie o token de projeto (RAILWAY_TOKEN) ou o token de conta/workspace (RAILWAY_API_TOKEN) e substitua-o nos segredos do seu CI - Faça o redeploy dos serviços que usam buckets para que adotem as novas credenciais. Verifique também se os buckets têm arquivos que você não enviou ou exclusões que você não fez (buckets não têm backups automáticos, diz a empresa)
- No log de auditoria do workspace, procure leituras de variáveis, alterações de credenciais de registry e deploys na janela de exposição que não foram feitos pela sua equipe nem pela Railway (exibida como "Railway Staff")
Segredo armazenado na Railway antes de 21 de outubro
Trate como exposto, tenha sido contatado ou não
↓→
1. Emita um novo valor na origem
Atualize a variável e faça o redeploy; depois revogue o valor antigo
Banco de dados com acesso público
Acessível pela internet com uma senha vazada
↓→
2. Regenere a senha e remova o acesso público
Faça o redeploy de todos os serviços que a referenciam
API de IA, pagamentos, GitHub
Chaves que o invasor parece ter buscado
↓→
3. Verifique uso, cobranças e logs de auditoria
De 13:58 UTC de 20 de out. até a rotação
Cuidado com mensagens que dizem ser do suporte da Railway
A empresa diz que enviará e-mails diretamente aos clientes afetados. O guia de recuperação de conta dela orienta os usuários a não enviar senhas, códigos de login, códigos de recuperação, tokens de API ou valores de segredos ao suporte. Se uma mensagem ligada a este incidente pedir valores de segredos ou códigos de login, presuma que não é genuína (observação deste site).
Os avisos de revogação do GitHub, da OpenAI e de outros provedores decorrem do pedido da Railway, e a empresa diz que eles não implicam que suas credenciais tenham sido afetadas. Não clique em links nessas mensagens; abra diretamente o painel de cada provedor.
O que aconteceu (segundo a Railway)
O texto a seguir se baseia nas publicações do blog da Railway "Security Disclosure: Wednesday October 21st" (21 de outubro de 2026) e "Preliminary Report: Oct 21st Security Incident" (datada de 22 de outubro; disponibilizada às 16:38 UTC de 23 de outubro, conforme a página de status), e na sua página de status. Os horários são em UTC.
20 out., 13:58
O monitoramento sinaliza atividade anormal na forma de latência elevada; o engenheiro de plantão começa a investigar.20 out., 14:03–16:51
A atividade é identificada como uma tentativa de escalonamento de privilégios por uma parte externa hostil. Um possível escalonamento de privilégios é encontrado na infraestrutura de build, e os pipelines de build são interrompidos.20 out., 18:05–19:53
Mitigações são implantadas e a exploração não pode mais ser reproduzida. Às 19:53, novas evidências mostram que o invasor poderia escalar o acesso em maior escala, em várias partes do sistema em paralelo.21 out., 04:24–05:23
A perícia constata que o invasor havia obtido segredos em forma criptografada, sem conseguir descriptografá-los naquele momento.21 out., 05:27–07:25
O invasor obtém credenciais do ambiente de CI e descriptografa artefatos que contêm acessos adicionais a APIs.21 out., 07:25–09:18
Evidências no banco de dados mostram uma consulta não autorizada a variáveis de ambiente criptografadas; um subconjunto foi descriptografado usando uma combinação de credenciais comprometidas.21 out., 09:25
A Railway notifica os provedores sobre as superfícies que o invasor acessou e pede que revoguem as chaves (o FAQ do relatório indica 09:35).21 out., 20:19–22:10
A Railway anuncia a invalidação das sessões de usuários e publica sua divulgação de segurança e as orientações aos clientes.22 out., 03:32
A Railway confirma que o invasor não tem mais acesso a nenhum sistema interno e começa a reinicializar os sistemas internos com novas credenciais.22 out., 17:00–22:49
É informada a restauração completa da API e dos deploys normais para todos os planos.23 out., 16:38
O relatório preliminar datado de 22 de outubro é disponibilizado (página de status).23 out., 18:57
Concluem-se as notificações aos workspaces avaliados como de maior risco (página de status).23 out., 22:06
A página de status marca o incidente como resolvido. Novos cadastros continuam pausados.
- O que aconteceu
- Um terceiro não autorizado acessou sistemas internos, obteve variáveis de ambiente criptografadas de clientes e descriptografou um subconjunto delas
- Escala
- No máximo 1,85% de todos os workspaces (cerca de 100.000 workspaces) tiveram algumas variáveis de ambiente potencialmente comprometidas. Os registros das consultas, por si sós, não permitem identificar quais variáveis específicas foram afetadas, porque as chaves tinham criptografia de envelope (a chave que criptografa os dados é, ela mesma, criptografada com outra chave), diz a empresa
- Objetivo do invasor (avaliação da empresa)
- Obter chaves de API de provedores de IA para a "destilação" de modelos (treinar outro modelo com as saídas de um modelo; explicação deste site). A empresa acredita que isso faz parte de uma série de ataques contra empresas de plataformas com o objetivo de comprometer provedores de inferência de IA
- Ambientes de maior risco
- Workspaces com um número muito grande de variáveis de ambiente e ambientes com muitas chaves de provedores de IA
- Declarado como não acessado
- Não houve login em contas de usuários da Railway
- Ainda não confirmado
- O acesso ao código-fonte não foi descartado e será confirmado no relatório final
- Notificações aos provedores
- A Railway notificou GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Google, Stripe e outros sobre chaves potencialmente descriptografadas e pediu que as revogassem. Para alguns provedores, forneceu todas as chaves cadastradas na plataforma, independentemente do impacto conhecido. Mais de 100.000 usuários foram afetados por pedidos de redefinição feitos aos provedores
- Impacto nos serviços
- Os serviços em execução permaneceram no ar. Novos builds e deploys, o painel, a API, a CLI e o suporte ficaram indisponíveis em alguns momentos
- Ações da empresa
- Desligou ferramentas internas potencialmente comprometidas; rotacionou todas as chaves e as rotacionou de novo após validar que o invasor havia sido removido; contratou uma empresa externa de perícia; moveu os builders para ambientes single-tenant; rotacionou as credenciais de todos os buckets de armazenamento; reconstruiu ferramentas internas a partir de código-fonte validado; adicionou uma forma de revogar em massa as permissões de aplicações da Railway
O que se sabe e o que não se sabe
Situação em 24 de outubro de 2026. Esta tabela será atualizada conforme a empresa publicar novas informações.
| Item | O que foi divulgado | Situação |
|---|---|---|
| Variáveis de ambiente criptografadas obtidas | Obtidas por meio de uma consulta não autorizada | Confirmado (empresa) |
| Descriptografia | Um subconjunto descriptografado usando uma combinação de credenciais comprometidas | Confirmado (empresa) |
| Workspaces no escopo | No máximo 1,85% de todos os workspaces (cerca de 100.000) | Possível (empresa) |
| Quais variáveis foram descriptografadas | Não podem ser identificadas apenas pelos registros das consultas | Em investigação |
| Credenciais de registries privados | Listadas para rotação | Possível (empresa) |
| Contas de usuários | O invasor não acessou contas de usuários da Railway | Negado (empresa) |
| Código-fonte | Acesso não descartado; a ser confirmado no relatório final | Em investigação |
| Serviços em execução | Permaneceram no ar | Confirmado (empresa) |
| Janela do ataque | 13:58 UTC de 20 out. a 03:32 UTC de 22 out. | Confirmado (empresa) |
| Detalhes do ataque | Não divulgados, para proteger os clientes | Em investigação |
| Uso indevido das chaves expostas | Não informado | Não informado |
| Horário em que os provedores foram notificados | 09:25 UTC na linha do tempo do relatório, 09:35 UTC no FAQ | Inconsistente no relatório |
Como ler os números: o que os 100.000 representam
Os "cerca de 100.000" do relatório preliminar são o número de workspaces (1,85% do total) que tiveram algumas variáveis de ambiente potencialmente comprometidas. O relatório diz que mais de 100.000 usuários foram afetados por pedidos de revogação feitos aos provedores e que os clientes contatados como de alto risco ultrapassam os 1,85%. Ser contatado, ou ter uma chave revogada, não confirma a exposição. Por outro lado, a empresa diz que workspaces fora dos grupos de maior risco não estão confirmados como seguros.
Por que chaves de API de IA são alvo
O que segue é geral e não significa que essas coisas aconteceram neste incidente. O objetivo que a empresa descreve para este invasor é obter chaves de API de IA para a destilação de modelos.
Uma chave de API de IA é dinheiro e capacidade de computação que qualquer pessoa que a possua pode gastar. Quando uma chave roubada é muito usada, a conta vai para o dono dela. Quando grandes volumes de saída são coletados em nome do dono, o provedor pode suspender a conta por violação de política, como a proibição de destilação. Como isso funciona e como recorrer está em por que uma conta é banida depois que a chave de API é roubada.
Uma plataforma de hospedagem guarda as chaves de muitos clientes em um só lugar. Isso provavelmente explica por que a empresa descreve workspaces com muitas variáveis de ambiente ou muitas chaves de IA como de maior risco. No mesmo mês, o desenvolvedor do LiteLLM também disse que o invasor em seu incidente procurava principalmente chaves de provedores de LLM (um incidente separado; nenhuma ligação entre os dois foi divulgada). Para um panorama mais amplo dos ataques que usam IA ou visam chaves de IA, veja como se defender de ciberataques com IA.
O que os usuários da Railway devem revisar: lições dos fatos divulgados
Esta seção não avalia a resposta da empresa. Ela se concentra no que os usuários podem fazer para estar preparados para o próximo incidente, com base no que foi divulgado.
Presuma que a criptografia do lado da plataforma não protege contra o comprometimento da plataforma
As variáveis de ambiente da Railway eram criptografadas, mas, segundo o relatório preliminar, o invasor descriptografou um subconjunto usando uma combinação de credenciais comprometidas. Uma plataforma de hospedagem precisa converter as variáveis de volta em valores em texto claro para executar sua aplicação; assim, quando os privilégios dentro da plataforma são tomados, a criptografia sozinha não consegue protegê-las totalmente (observação deste site).
Além da criptografia da plataforma, guarde os segredos de modo que um vazamento cause dano limitado. Como primeiro passo, defina limites de gastos e alertas com seus provedores de API de IA e de pagamentos. Chaves separadas para produção, homologação e desenvolvimento também reduzem o que você precisa rotacionar. O armazenamento de segredos é tratado em o que realmente é perigoso em .env e chaves de API.
Mantenha os bancos de dados fora da internet pública
Segundo o guia da empresa, um banco de dados com acesso público habilitado pode ser alcançado de qualquer lugar da internet com uma string de conexão vazada. Um banco de dados usado apenas pela rede privada do projeto não pode ser alcançado diretamente de fora, mesmo que sua string de conexão vaze.
O acesso externo geralmente só é necessário para desenvolvimento local, CI ou ferramentas de BI. Mesmo assim, considere abri-lo apenas enquanto for necessário ou usar um usuário separado, somente leitura (observação deste site).
Compartilhe segredos por referências para que a rotação aconteça em um só lugar
O guia da empresa recomenda compartilhar strings de conexão e chaves por variáveis de referência, como ${{ Postgres.DATABASE_URL }}, em vez de colá-las em cada serviço. Com referências, alterar o valor de origem e fazer o redeploy alcança todos os serviços, e nenhuma cópia colada é esquecida.
No mesmo espírito, mantenha uma lista atualizada de qual segredo cada serviço usa e onde ele é reemitido (observação deste site). Quando você precisa rotacionar tudo, como agora, essa lista define quanto tempo o trabalho leva. Em um caso semelhante, o incidente de segurança na Vercel, o que importou foi se os segredos estavam armazenados em uma categoria cujos valores não podem ser exibidos depois.
Limite as conexões com o GitHub aos repositórios e escopos necessários
Neste incidente, a empresa revogou os tokens do GitHub que mantinha e recomenda revisar os logs de auditoria do GitHub e o acesso de apps. Limite o acesso ao GitHub que você concede a uma plataforma de hospedagem aos repositórios que ela implanta e dê aos tokens de container registry apenas acesso de leitura (read:packages), para que um vazamento alcance menos (observação deste site). O problema de credenciais vazadas que continuam válidas é tratado em credenciais vazadas que continuam válidas.
Fontes (registro público)
Os fatos deste artigo se baseiam nas seguintes fontes públicas. Os detalhes do ataque não são reproduzidos.
- Railway, "Security Disclosure: Wednesday October 21st" (21 de outubro de 2026; a página de status publicou "We have published a security notice" às 22:10 UTC de 21 de outubro) — blog.railway.com
- Railway, "Preliminary Report: Oct 21st Security Incident" (datado de 22 de outubro de 2026; disponibilizado às 16:38 UTC de 23 de outubro, conforme a página de status) — blog.railway.com
- Railway, "Railway Platform Outage" (página de status, verificada até a atualização "Resolved" das 22:06 UTC de 23 de outubro) — status.railway.com
- Guias para usuários da Railway (22–23 de outubro de 2026): "Rotate PostgreSQL Database Credentials" blog.railway.com / "Check for Anomalous GitHub Access" blog.railway.com / "Check for Unexpected OpenAI Usage" blog.railway.com / "Redeploy Buckets and Reconnect GitHub After the Credential Reset" blog.railway.com / "Recover Failing Deploys" blog.railway.com / "Resolving Login Issues" blog.railway.com
- Os guias para outros serviços (MySQL, Redis, MongoDB, Anthropic, OpenRouter, Grok, Stripe, AWS, GCP) estão listados no blog de engenharia da empresa — blog.railway.com
Histórico de atualizações
2026-10-24: Primeira versão, com base na divulgação da Railway (21 de outubro), no relatório preliminar (22 de outubro) e na página de status (até a atualização das 22:06 UTC de 23 de outubro). Corrigida no mesmo dia após a conferência das fontes: o horário de publicação do relatório preliminar agora segue a página de status (16:38 UTC de 23 de outubro), e a situação do acesso às contas de usuários agora é "Negado (empresa)". O escopo da descriptografia e se o código-fonte foi acessado serão acrescentados quando o relatório final for publicado.
Leia a seguir
- Incidentes semelhantes: o que os desenvolvedores devem fazer após o incidente de segurança na Vercel / o comprometimento do LiteLLM 1.107.0
- Por que chaves de IA são alvo: como se defender de ciberataques com IA / chaves de API roubadas e banimento de contas
- Armazenamento de segredos: o que realmente é perigoso em .env e chaves de API / chaves de API vazadas por código escrito por IA
- Outros incidentes de 2026: lista de vazamentos de dados e ciberataques