Railway: environment variables accessed, rotate all your secrets

Railway, the cloud platform developers use to deploy applications, APIs, databases and backend services, has detected suspicious activity on the systems that store customer environment variables and is asking all users to rotate their secrets and credentials. According to BleepingComputer, the platform has around 4.8 million users and hosts more than 16 million services.

The story is reported by The Hacker News, TechCrunch and BleepingComputer; the details that follow come from TechCrunch and BleepingComputer, which quote the post Railway published on its blog and its status page.

What happened

In Railway’s statement, quoted by both outlets, the company writes that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway points out that these variables may contain API keys and database and registry credentials.

What has been stated so far:

• according to the initial analysis only a subset of users is affected, but the advice to rotate everything applies to all users;
• Railway has not said how many users are affected or what the root cause was: founder and CEO Jake Cooper told TechCrunch that a post-mortem will be published;
• users whose accounts are confirmed as compromised will be notified directly (BleepingComputer);
• the company did not answer TechCrunch’s question about a possible ransom demand.

The link to AI inference providers

Railway places the incident within a series of attacks against platforms aimed at compromising AI inference providers, the services that run models and return answers to hosted applications. According to BleepingComputer, these providers were notified directly and advised to revoke all their keys as a precaution.

TechCrunch notes that a few days earlier OpenCode had disclosed the theft of customer API keys in a similar attack, which the company attributed to an AI model distillation attack; ARX News covered it on 19 October. The sources do not say whether the same actors are behind both incidents. Also according to TechCrunch, the Railway incident appears to be separate from the critical PHP vulnerabilities («PHP2Shell») disclosed the same week.

Impact on the service

During the investigation Railway paused builds and deployments. TechCrunch describes a brief pause followed by restoration; BleepingComputer reports that, according to the status page update of 22 October at 08:44 UTC, builds had resumed for Pro and Enterprise workspaces, with many deployments still queued, while for Hobby, Free and Trial restoration was planned in that order.

Technical details and ATT&CK techniques

The initial vector is not known. The key point is that the secrets were stored encrypted and that, according to Railway, the attacker managed to obtain part of them in clear text: whoever holds them can access databases, cloud services and private registries as the legitimate owner, without going through the platform.

Indicative MITRE ATT&CK mapping, derived from the reported facts: T1199 (Trusted Relationship) for access to customer resources through the platform provider; T1078.004 (Valid Accounts: Cloud Accounts) for any use of the stolen secrets. No indicators of compromise have been published.

Impact for European and Italian companies

Railway is also used by European and Italian teams, often for projects that started quickly and then stayed in production. A service’s environment variables are effectively its keys: databases with customer data, cloud accounts, payment keys, AI provider tokens, credentials for the registries that production images are pulled from.

• GDPR: if the secrets included credentials for databases holding personal data, document your assessment of the event and decide, based on the logs, whether there has been a breach that must be notified.
• NIS2: for entities in scope, an incident at a platform provider falls under supply chain security management (Article 21); if the logs show misuse of credentials, assess whether the event is significant for notification purposes.
• Healthcare and special categories of data: where hosted services process health data, check database access first.

What to do now

1. Take inventory: all projects, services and environments on Railway, with their variables, including shared ones and private registry credentials.
2. Rotate all secrets, as Railway asks, starting with database credentials, cloud and AI provider keys, registry tokens, payment keys and signing secrets (sessions, JWT, webhooks). Create the new credential, roll it out, then revoke the old one.
3. Keep queued deployments in mind: if a service reads its variables at startup, the new key only takes effect after the next deployment. Before revoking the old one, check that the service is already using the new one.
4. Review the logs of your services on Railway, as the company advises, and above all those on the other side: database access, cloud account audit logs, AI provider usage and billing, registry pulls. Look for access from unusual addresses and countries starting from the days before the notice.
5. Reduce the value of your secrets: least privilege, database access restricted to the addresses that need it, spending caps on AI providers, short-lived tokens where possible.
6. Follow Railway’s updates: the direct notification to compromised accounts and the announced post-mortem.

How ARXDOME helps

If the exposed secrets open databases or servers you manage, ARX Sentry collects logs and security events from computers, servers and firewalls and groups them into families, such as failed logons and use of explicit credentials, in the SOC pages. ARX Horizon enriches every connection with country, network operator and threat lists, so a logon with valid credentials from an unusual address stands out right away.

Last updated: 22 October 2026