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
After removing the attacker’s access on October 22 at 03:32 UTC, Railway continued coordinating credential revocations with other companies. 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. It has not published the complete exploit details or a final forensic report.
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.
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.
