Railway says some developers had newly replaced API keys revoked because those keys were accidentally included in a precautionary list sent to AI providers. Its October 24 clarification separates an alarming symptom from its cause: another invalid key did not, by itself, mean an attacker had stolen the replacement. The underlying October incident did expose some stored secrets, so users who have not completed the original rotation still need to act. [1]
A replacement key caught in the next batch
Railway’s detailed November 10 report says customer-data access had ended by October 21 at 09:25 UTC. Builds began returning in phases on October 22 at 03:32 UTC, while Railway continued coordinating credential revocations with other companies. [4] On October 23, AI providers requested another batch of potentially affected keys. Railway supplied that batch to OpenAI and Anthropic, but says it could not filter keys by the time they had been added to the platform. Newer keys were included inadvertently.
That meant a developer could replace a credential after the intrusion, then see the replacement stop working too. Railway’s explanation is an overbroad response list, rather than evidence that the new key had been compromised. In the October 24 notice, it said it was not then under attack. The notice was marked resolved on October 25 at 06:26 UTC; that administrative status does not erase the original exposure.
For a key actually revoked by its provider, Railway’s instruction is to create a replacement, update the corresponding Railway environment variable, and redeploy the services that use it. If keys still work and the earlier rotation is complete, this clarification does not require repeating it. A provider’s notice and its account console are the place to verify what happened to a specific credential.
How encrypted variables became readable
The preliminary report, published October 22, describes a more serious sequence behind the original rotations. Environment variables are configuration values that applications use at runtime; some contain API keys, database passwords or container-registry credentials. An application can keep running normally while a copied credential gives someone access to a connected service. [2]
Railway’s timeline begins with abnormal latency on October 20. Engineers investigated possible privilege escalation in the build infrastructure, halted build pipelines and deployed mitigations. Later that day, additional evidence showed that the attacker could expand access across multiple parts of the system. The first apparent fix had not removed every route in.
Early on October 21, investigators found the attacker had pulled encrypted secrets but initially could not decrypt them. The important turn came next: access to credentials for Railway’s continuous integration (CI) environment enabled the attacker to decrypt artifacts holding additional API access. The company then found evidence of an unauthorized query of encrypted environment variables; a combination of compromised credentials allowed a subset to be decrypted.
Encryption therefore mattered, but the protection depended on keeping the supporting credentials separate from the stolen data. Railway says the database query alone cannot identify exactly which keys in an affected project or service were decrypted. At the time of that preliminary report, it had not published the complete exploit details or a final forensic report; the November 10 follow-up below adds the detailed access chain.
Three different meanings of “affected”
Railway puts the preliminary upper bound at 1.85% of workspaces—about 100,000—with some variables potentially compromised. That is a workspace estimate, not a count of people, and it does not establish that every secret in each workspace was read.
The precautionary response was broader. Railway sent some providers all keys for their service that it held, including keys not known to be compromised. It also contacted customers considered at higher risk. Receiving a revocation notice, being included in a risk notification, and having confirmed credential exposure are consequently different findings. The later replacement-key problem is another reason not to infer theft from revocation alone.
Railway attributes the intruder’s interest to AI-provider and platform credentials, potentially for model distillation. That remains the company’s preliminary interpretation of the attacker’s intent. The report does not establish that a particular model was copied, and it leaves possible source-code access unresolved.
Restored deployments do not retire an old secret
Railway says existing customer deployments stayed online while new builds and deployments were paused. Its main incident page later reported builds, deployments, the API and dashboard operating normally. Service restoration and credential recovery are separate jobs. [3]
If sensitive credentials were stored on Railway before October 21 and have not been rotated, follow the original precaution: revoke the old credentials at the services that issued them, create replacements, update the affected variables, and redeploy dependent services. Merely changing a value inside Railway does not revoke a copied key at its provider. Review connected-service activity, GitHub audit logs and app permissions, and registry logs for unexpected use; Railway also recommends removing public database access.
The LiteLLM startup-hook compromise illustrates a different route to exposed developer secrets: code running locally, rather than an intrusion into hosting infrastructure. In either case, recovering the application does not make an old credential safe. For Railway users, the immediate distinction is whether the original rotation remains unfinished or a replacement was subsequently revoked as a precaution.
Chainalysis faced a similar split during a separate incident: reopening KYT did not remove the need to rotate applicable API keys and verify integrations.
November 10 report: how the separate access routes joined up
Railway’s detailed November 10 report gives a more specific account than the preliminary report cited above. A partial escape from build filesystem isolation exposed a build credential. Temporal, the service coordinating build tasks, also trusted that credential; its stored build histories exposed additional information and helped the attacker retrieve Railway’s internal repository. The report says 353 build histories were read. This was Railway’s own codebase; the company says it found no indication of customer repository downloads.
A separate, incorrectly configured cloud identity trust relationship then enabled access to short-lived cloud credentials. From there, the attacker obtained credentials and a network path to stored encrypted variables, plus access that allowed some variables to be decrypted. The failure crossed several permission boundaries: encrypted database contents alone were not the complete route. Railway now says each build receives a dedicated virtual machine and a narrowly scoped image-push credential, while decryption access is restricted to the secrets service.
The report keeps 1.85%—about 100,000 workspaces—as an upper bound for possible variable decryption, not a confirmed count of people or individual secrets. Separately, it identifies linked-account tokens belonging to 1,852 users, says those tokens were reset, and estimates about $740,000 in unauthorized use of stolen keys. Customers should use the report’s refund process or their usual Railway support route for disputed charges; a refund request does not replace revoking an exposed credential.
The newer report dates the end of customer-data access to October 21 around 09:25 UTC, revising the preliminary report’s chronology. The October 22 03:32 UTC milestone was the beginning of phased build restoration, not the revised end of attacker access. The replacement-key revocations remained a later precautionary response. Railway still describes external specialist forensic work as ongoing. [4]
References
- Railway. “Clarification: Recent Oct 24 API key revocations are precautionary.” October 24, 2026, 13:57 UTC; status updated October 25. Accessed October 25, 2026. Official clarification.
- Jacob Cooper and Angelo Saraceno. “Preliminary Report: Oct 21st Security Incident.” Railway, October 22, 2026. Preliminary incident report.
- Railway. “Railway Platform Outage.” Operational recovery update October 23, 2026, 22:06 UTC. Accessed October 25, 2026. Incident status and recovery guidance.
- Jacob Cooper, Angelo Saraceno, Sarah Bedell, Luca Casonato. “Incident Report: October 21st Security Attack.” Railway, November 10, 2026, updated 18:02 UTC; accessed November 13, 2026. Detailed incident report.
