Press enter or click to view image in full size
An October intrusion moved from build isolation to cloud credentials and secret decryption. The incident shows why encrypting data is not enough when the systems permitted to decrypt it can be compromised.
A cloud platform can encrypt every customer secret and still suffer a serious credential-exposure incident.
Railway’s November 10, 2026 security report provides a detailed example.
Attackers exploited a weakness in its build infrastructure, obtained an internal credential, accessed stored build histories and source code, then found a second route through a misconfigured cloud trust relationship.
The result was access to encrypted customer environment variables and the decryption of a subset of them.
Railway estimates that the stolen AI credentials generated approximately $740,000 in unauthorized usage.
Understanding this incident requires looking at two different boundaries.
The first was the boundary between an isolated build and Railway’s internal infrastructure.
The second was the boundary between cloud workloads and the credentials permitted to retrieve and decrypt customer secrets.
1. The initial build isolation failure
On October 20, the attackers began probing Railway’s build infrastructure.
At the time, Railway used a multi-tenant design in which isolated builds could run on the same virtual machine.
At 07:28 UTC, the attacker exploited a previously unknown weakness that allowed a partial escape from filesystem isolation.
That gave the attacker access to some files on the host machine, including a credential used by build servers.
The credential was intended for a restricted set of build operations.
However, Railway’s internal Temporal service accepted it as a trusted client.
The attacker could therefore access certain stored build histories.
Some histories contained information about credentials and environment variables provided to builds.
The attacker also obtained a snapshot of Railway’s internal source repository.
This source code became valuable reconnaissance material.
It revealed internal services and potential access paths that were not necessarily visible from the public internet.
Railway detected anomalous API calls at 13:58 UTC and began its incident response.
The original credential was revoked and the initial route was restricted.
But the attacker had already obtained enough knowledge to continue.
2. The OIDC trust configuration failure
The second stage occurred on October 21.
Railway’s deployment systems could obtain short-lived cloud credentials using an OIDC-based trust relationship.
According to the company’s investigation, one cloud environment contained an incorrectly defined OIDC binding.
The attacker used this configuration to obtain temporary cloud credentials.
Those credentials enabled access to additional internal secrets, including credentials and an SSH key used by deployment infrastructure.
The attacker then reached an orchestration machine connected to Railway’s internal network.
That machine had access to systems involved in provisioning customer workloads and decrypting environment variables.
Between 04:07 and 05:21 UTC, the attacker retrieved encrypted customer data from the production database.
Between 04:42 and 07:15 UTC, the attacker used the obtained credentials to request the decryption of some of that data.
The important detail is that the root encryption key did not need to leave the cloud key management service.
A system authorized to request decryption became the attacker’s path to the information.
3. Why envelope encryption was not a complete barrier
Railway used envelope encryption to protect customer environment variables.
Each environment had its own data encryption key.
Those keys were themselves encrypted under a root key managed by a cloud key management service.
This arrangement helps limit the impact of a compromised key.
It also means the root key does not need to be stored directly on every application server.
But authorized workloads still need to decrypt customer secrets to operate.
If an attacker obtains the credentials and network access required to make legitimate decryption requests, encryption at rest alone cannot prevent exposure.
The security of the decryption interface becomes just as important as the cryptographic protection of the stored data.
Railway reports that the upper bound of environments potentially affected was approximately 100,000 workspaces, or 1.85% of the platform.
The forensic logs did not identify every individual variable that was decrypted, so the figure must not be treated as a confirmed count of stolen secrets.
4. What the attacker actually targeted
Railway’s database logs showed queries designed to identify environment variables likely to contain AI provider credentials.
The attackers prioritized names associated with AI API keys.
Other queries also matched cloud, database and payment-service credentials.
Railway found no evidence of customer database access or customer repository downloads.
However, it confirmed that linked-account tokens belonging to 1,852 users were exposed and reset them.
The financial consequence was separate from the initial intrusion.
The stolen AI keys were subsequently associated with an estimated $740,000 in unauthorized AI usage.
Railway believes some credentials may have entered relay or resale networks that provide access to AI computing services.
The company has not established whether the original intruder operated those networks or supplied credentials to others.
5. How to audit your own exposure
For teams using Railway, the question is not simply whether they received an incident notification.
The practical review should cover credentials, actual usage and downstream charges.
Start by identifying all sensitive environment variables stored in Railway before October 21.
That may include AI API keys, cloud credentials, database passwords and private registry secrets.
Rotate affected credentials and confirm that dependent applications use the replacements.
Then examine AI-provider usage logs and invoices for the relevant period.
Look for requests that do not match known deployment activity, unexpected model usage, unusual volumes, unfamiliar request patterns and charges outside the normal budget.
Review logs from other services whose credentials were stored in Railway.
Railway’s initial guidance also included auditing GitHub integrations, container registries and publicly reachable databases.
If there is suspicious activity, preserve the logs and billing records.
Railway has published a reporting form for unauthorized AI-token charges.
For OpenAI-related reimbursement requests, its November 10 report asks affected customers to open a provider support case and pass the case ID to Railway.
Absence of unexpected charges is not proof that a credential was never exposed.
But it is one of the concrete ways to determine whether financial misuse has occurred.
6. What Railway changed after the incident
Railway reports replacing its shared build design with infrastructure that gives each build a dedicated ephemeral virtual machine.
Build credentials are now intended to have narrower permissions, such as pushing only a specified container image.
The company rebuilt and hardened its CI infrastructure, introduced stronger controls for sensitive operations and revised internal service-account permissions.
It also changed its secret storage and decryption systems.
Railway now centrally logs encryption and decryption requests and restricts which services may request decryption.
These changes address the specific trust boundaries exposed during the incident.
They are not proof that no future attack is possible.
They do, however, show how the architecture was altered in response to the observed failure paths.
7. The financial boundary matters too
There is a third boundary beyond the build system and the key management service.
It exists between the company storing the API key and the AI provider charging for its use.
A stolen key can be used to create consumption on a different service.
That creates a financial impact even when the customer’s own application has not been changed.
Organizations should therefore consider usage monitoring, spending alerts and provider-supported limits alongside credential security.
Not every AI provider offers identical controls or reimbursement policies.
Railway’s report describes different refund processes across providers and commits to covering losses the providers will not refund.
This incident illustrates why customer protection must extend beyond detecting credential theft.
The engineering question
The Railway breach was not a single vulnerability that could be solved by changing one password.
It involved a chain of permissions and trust assumptions.
A build credential was accepted by a service beyond its intended purpose.
Internal code helped an attacker locate another entry point.
A misconfigured OIDC trust relationship enabled access to cloud credentials.
Those credentials led to a system authorized to decrypt customer secrets.
And the exposed AI keys could then be used to consume paid resources elsewhere.
Each boundary mattered.
A secret is not protected merely because it is encrypted. It is protected only to the extent that every system capable of decrypting or using it is adequately constrained.
The same principle applies to financial exposure.
When an API key can authorize spending, protecting it means protecting both access to information and access to money.
Sources
Railway — Detailed incident report, November 10, 2026
https://blog.railway.com/p/incident-report-october-security-incident
Railway — Initial security disclosure, October 21, 2026
https://blog.railway.com/p/security-disclosure-wednesday-october-21st
#CyberSecurity #DevOps #CloudSecurity #SoftwareEngineering