Railway e Heroku foram comprometidas pela própria infraestrutura compartilhada. Este é o padrão real, não um discurso de vendas.

Duas plataformas que rodam as aplicações de muitas outras pessoas publicaram incidentes de segurança reais e confirmados nos últimos anos: a Railway em outubro de 2026, e a Heroku em abril de 2022. Os dois são documentados pelas próprias empresas, não são rumores. E os dois remontam à mesma forma de risco subjacente: uma vulnerabilidade em uma infraestrutura que a plataforma opera em nome de muitos clientes ao mesmo tempo, que se transformou em acesso a dados de clientes que não tinham nada a ver com a falha original.

Este post não é “toda plataforma já foi violada” — isso seria falso, e não vamos afirmar isso. São dois incidentes reais e bem documentados, o que eles realmente têm em comum, e o que um modelo em que você traz seu próprio servidor muda nesse padrão específico. Já escrevemos uma análise completa do incidente da Railway separadamente: a violação da Railway nas variáveis de ambiente. Este post olha o padrão nos dois incidentes.

O que realmente aconteceu, nos dois casos

Railway, outubro de 2026. O relatório preliminar da Railway descreve um atacante que escalou privilégios dentro da infraestrutura de build da Railway, chegou ao ambiente de CI dela, e dali acessou os sistemas que armazenam as variáveis de ambiente dos clientes — descriptografando parte delas. Pelos próprios números da Railway, até 1,85% de todos os workspaces, cerca de 100.000, tiveram variáveis de ambiente potencialmente expostas. O detalhamento completo e as palavras da Railway estão no nosso post dedicado à violação.

Heroku, abril de 2022. Um atacante obteve as credenciais de uma conta de máquina da Heroku, deixadas em um repositório privado arquivado do GitHub que continha o código-fonte da Heroku. Esse acesso chegou a um banco de dados da Heroku que armazenava os tokens OAuth da integração com GitHub dos clientes, e dali a um banco de dados interno de clientes, de onde senhas de clientes com hash e salt foram exfiltradas. A Heroku fez a divulgação em 15 de abril de 2022, revogou os tokens da integração com GitHub, forçou uma redefinição de senha para os usuários afetados, e a própria integração com GitHub ficou fora do ar até 25 de maio de 2022. A equipe de segurança do GitHub confirmou separadamente que os tokens OAuth roubados foram usados para acessar repositórios privados em dezenas de organizações, incluindo o npm.

O padrão por trás dos dois

Em nenhum dos casos um cliente fez algo errado, e não foi um ataque de força bruta contra uma conta individual. Nos dois casos, o ponto de entrada foi uma peça de infraestrutura que a plataforma opera de forma centralizada — o pipeline de build/CI da Railway, o controle de código-fonte interno e as credenciais de conta de máquina da Heroku — e o ponto de saída foram dados de um grande número de clientes sem relação entre si, alcançados através desse único sistema compartilhado.

Esse é o mecanismo real que vale a pena nomear: em uma plataforma multi-tenant, o sistema de build, o control plane e o compute que roda o código dos clientes costumam estar todos dentro do mesmo perímetro interno de um único operador. Uma fuga de credenciais ou um bug de escalada de privilégios em qualquer um desses sistemas é potencialmente um caminho para os dados de todo mundo, porque “todo mundo” compartilha a infraestrutura onde esse bug vive.

O que um modelo com servidor próprio realmente muda — e o que não muda

Escrevemos isso com cuidado no post da Railway e também se aplica aqui: o control plane do Railyard também armazena as variáveis de ambiente dos clientes de forma centralizada, criptografadas em repouso, da mesma forma geral que qualquer plataforma que guarda segredos de clientes — Railway e Heroku inclusos. Um comprometimento do banco de dados do control plane do Railyard e da sua chave de criptografia é o mesmo tipo geral de risco que qualquer repositório central de segredos carrega, independente de onde o compute roda. Ter seu próprio servidor não faz esse banco de dados desaparecer.

O que muda é o que a cópia descriptografada e ativa de um segredo toca depois de saber desse repositório. No Railyard, as variáveis são descriptografadas uma única vez, no momento do deploy, e entregues a um servidor na própria conta de nuvem daquele cliente específico — não a uma frota de compute compartilhada que a própria plataforma opera. Não existe um único pipeline de build ou ambiente de CI cujo comprometimento dê a um atacante um ponto de apoio nas aplicações em execução de outros clientes, porque não existe uma frota compartilhada de aplicações em execução para pivotar. O ambiente ativo de cada cliente é uma máquina diferente em uma conta diferente.

Essa é uma afirmação estreita e específica: ela fecha um caminho — um bug na infraestrutura compartilhada da plataforma se tornando uma rota para os segredos ativos de muitos clientes sem relação ao mesmo tempo — não todos os caminhos. Não é uma afirmação de que o Railyard, ou qualquer um, é imune a uma violação. Uma empresa que diz que não pode ser violada é uma empresa da qual você deveria ser mais desconfiado, não menos.

O que realmente fazer, em qualquer plataforma

• Rotacione segredos em um cronograma, não só depois de uma divulgação. Uma chave de API estática e de longa duração parada no painel de qualquer plataforma é um risco permanente, independente de qualquer incidente específico.
• Limite o alcance das credenciais. Quanto menor o alcance de uma única chave roubada, menos uma violação de qualquer tipo custa.
• Pergunte o que precisa ser comprometido para chegar a um segredo descriptografado e em uso ativo — não só se os dados estão “criptografados em repouso”. Criptografia em repouso é o mínimo em todo lugar; a pergunta real é quantos sistemas compartilhados existem entre um bug em outra parte da plataforma e seus segredos de fato em execução.
• Leia os relatórios de incidente que as empresas realmente publicam. As divulgações da Railway e da Heroku aqui são genuinamente informativas quando você separa o que foi confirmado do que foi amplificado secundariamente — veja nosso detalhamento da violação da Railway como exemplo dessa separação.

Veja as comparações completas: Railyard vs. Railway e Migrando da Heroku.

Perguntas frequentes

Toda plataforma PaaS já foi violada? Não, e não estamos afirmando isso. Este post cobre dois incidentes específicos, confirmados e bem documentados — Railway (2026) e Heroku (2022) — não toda plataforma do mercado.

Rodar seu próprio servidor torna uma violação impossível? Não. O control plane de uma plataforma ainda precisa guardar seus segredos em algum lugar antes de fazer o deploy deles, e esse repositório continua sendo um alvo em qualquer arquitetura, Railyard incluso. O que muda é se um bug na infraestrutura compartilhada de build/compute da plataforma pode se tornar um caminho para os segredos ativos de outros clientes — em um modelo com servidor próprio, não existe uma frota de compute compartilhada para esse bug pivotar através dela.

Qual é o ponto real em comum entre os incidentes da Railway e da Heroku? Nos dois casos, o ponto de acesso inicial foi uma infraestrutura que a plataforma opera em nome de muitos clientes ao mesmo tempo (o pipeline de build/CI da Railway; o controle de código-fonte interno e as credenciais de conta de máquina da Heroku), e o impacto atingiu clientes que não tinham nada a ver com a vulnerabilidade original.

Fontes

• Security Disclosure: Wednesday October 21st — blog oficial da Railway
• Preliminary Report: Oct 21st Security Incident — blog oficial da Railway
• April 2022 Incident Review — blog oficial da Heroku
• Incident 2413 — página de status oficial da Heroku
• Security alert: Attack campaign involving stolen OAuth user tokens — blog oficial do GitHub
• Heroku Forces User Password Resets Following GitHub OAuth Token Theft — cobertura secundária