On Oct. 21, Railway told customers that an unauthorized third party may have accessed their encrypted environment variables and, for some of them, the decrypted contents. For a lot of developers, the second half of that sentence raised the obvious question: if the secrets were encrypted, how could anyone read them? Railway has not answered that for its own incident, and this article does not guess. What can be explained is the general design, which Railway itself has documented: secrets are protected while they sit in storage, and every platform has to turn them back into usable values before your code can run.
Where it stands: Railway’s security notice reached its status page at 21:59 UTC on Oct. 21 (5:59 p.m. ET), telling users to “revoke all environment variables stored in Railway, including API keys and private registry credentials, and review your service logs for unusual activity.” The company says it will email customers once it confirms which accounts were affected. It has not published an attack method, a count of affected accounts, or an account of how decrypted values were obtained.
What Railway said, and what it left open
The disclosure, signed by Jacob Cooper, says Railway detected “anomalous activity involving systems that store customer environment variables.” The key passage separates two things: “an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.”
Read carefully, that describes a stored, scrambled form of the data and, for a portion of customers, the readable form. Railway adds that the impact “may be limited to a subset of users,” but it still asks everyone to act.
The gap is the “how.” Railway has not said which systems were reached or what let the attacker see real values. Anything you read online claiming to know is speculation unless Railway or another named investigator says it. Our news explainer on the Railway security incident tracks what the company has confirmed.
How encrypted environment variables work on a platform like Railway
Railway described its design in an April 2024 engineering post. Configuration values such as API keys and database passwords are stored as service variables, which are “automatically injected into deployments at runtime.” Because they often hold sensitive data, Railway wrote, “they get encrypted prior to storage in our Postgres database.”
That post also explained a move to envelope encryption. Instead of encrypting every value with one master key in Google Cloud’s key management service, Railway wrote that it would “generate one DEK per Environment” (a data encryption key for each production or staging environment) and use it for that environment’s values. The data key itself is wrapped by the cloud key service. Railway listed the security benefit as limiting damage: a brute-force attack on one environment “won’t compromise data for any others.”
Railway’s current documentation fills in the other half. “Variables are made available at runtime as environment variables,” the docs say, and they are also supplied during builds and to CLI commands such as railway run and railway shell.
Put those together and the shape is simple. Encryption guards the copy in the database. Delivery requires decryption. There is no way for a hosted app to use a database password it cannot read, so at some point the platform has to produce the plain value and hand it over.
Where a secret is readable, stage by stage
The table below is a general model of runtime secrets on any hosting platform. It is not a reconstruction of what happened at Railway.
| Stage | Form of the secret | Who can read it |
|---|---|---|
| Stored in the platform database | Encrypted | Only someone who also holds the decryption keys |
| Prepared for a build or deploy | Decrypted by platform services | The systems that inject variables |
| Inside your running app | Plain environment variable | Your code, its dependencies, anything it logs |
| At the issuing provider | A live credential | Whoever presents a copy |
The last row is the one that matters most after a breach. Encryption on the host does nothing to the key’s power at OpenAI, AWS, Stripe or your database server. A copied value keeps working until the company that issued it revokes it.
The model also explains why the wording “encrypted” and “decrypted contents” can both appear in one notice. Properly encrypted data on its own is generally of little use to an intruder. Access to the services or keys that perform decryption is a different matter.
Sealed and “sensitive” variables: a real upgrade with limits
Railway offers sealed variables. In its words, “When a variable is sealed, its value is provided to builds and deployments but is never visible in the UI nor can it be retrieved via the API.” The docs list constraints too: “Sealed variables cannot be un-sealed,” and “Sealed variable values are not provided when using railway variables or railway run via the CLI.”
That narrows who can pull a value out through the dashboard, the API or a teammate’s laptop. It does not change the fact that your service still receives the plain value when it starts.
Vercel uses a similar split. In its separate April 2026 incident, which Vercel closed on Oct. 16 and which no source connects to Railway, the company said the exposed values were “non-sensitive environment variables stored on Vercel (those that decrypt to plaintext).” Its advice afterward was to “take advantage of the sensitive environment variables feature so that secret values are protected from being read in the future.”
When the key sits next to the lock
Encryption only helps if the key is kept somewhere the attacker cannot reach. Zeabur’s report on its own October breach, a separate case, shows what happens otherwise. Of the n8n automation instances it checked, Zeabur said “602 (of the 607 we checked) had their encryption key set in an environment variable, so the third-party credentials in n8n were effectively leaked in plaintext.” Our Zeabur breach report covers that incident in full.
Fireworks AI, in its own separate bulletin this month, made the point about the other end of the chain: “Removing a stored secret alone does not invalidate the underlying credential.” Deleting a variable from a dashboard is housekeeping. Revocation happens at the provider.
What actually protects you after a platform notice
Railway’s own instruction is to “immediately roll all environment variables, including any API keys, stored in Railway,” plus private registry credentials, and to check logs. In practice that means:
- Create a new credential at the issuing service, deploy it, then revoke or disable the old one there. Re-saving the same value on the platform changes nothing.
- Seal the replacement on Railway, or mark it sensitive on Vercel, so fewer people and tools can read it back.
- Give every service its own key, so one leak does not force a fleet-wide rotation and its use is easy to trace.
- Set spend limits and expirations where the provider supports them.
- Review the provider’s usage logs for calls, models or regions you do not use.
- Keep secrets out of build output, crash reports and debug logs, which are plain text by nature.
Our rotation checklist for Railway users goes provider by provider, and this guide covers how to look for signs a secret was used.
Anthropic’s help center states the trade-off plainly: when you upload a key to a cloud or CI/CD platform, “you are giving the developer of that tool access to your Claude Console account.” The same article still says to “always add your API key as an encrypted secret.” Encryption is the starting point, not the whole plan.
Railway’s 2024 post said the envelope-encryption migration meant converting “over 3 million existing variables to the new system.” That work changed how those values are stored; each of them still has to be decrypted before a deployment can use it.
Frequently Asked Questions
Are encrypted environment variables safe from hackers?
Encryption protects the stored copy of a variable. The value still has to be decrypted before a build or a running app can use it, so anyone who reaches the systems or keys that do that decryption may be able to read it. Encryption lowers risk; it does not remove the need to rotate after a breach.
Did Railway store secrets in plaintext?
Railway has not said that. Its 2024 engineering post says variables are encrypted before they are stored in its Postgres database. In its October 21 notice Railway said a third party may have accessed encrypted variables and, for some, obtained the decrypted contents. It has not explained how.
What is a sealed variable on Railway?
A sealed variable is still delivered to builds and deployments, but Railway says its value is never shown in the dashboard and cannot be retrieved through the API. Sealing cannot be undone, and sealed values are not handed to the railway variables or railway run CLI commands.
If I delete a leaked secret from my hosting platform, is it safe?
No. Deleting the stored copy does not switch off the credential itself. Fireworks AI made the same point in its own incident bulletin. Revoke or disable the key with the company that issued it, then put the replacement into your platform.
Should I still encrypt secrets after this?
Yes. Anthropic tells users of third-party platforms to add API keys as encrypted secrets. Treat encryption as the floor, and add sealed or sensitive variables, one key per service, spend limits and a tested rotation plan on top.
Sources
- Security Disclosure: Wednesday October 21st — Railway (Jacob Cooper), October 21, 2026
- Railway Platform Outage — Railway status page, October 21-22, 2026 (live page)
- Upgrading 3 Million Variables to Envelope Encryption — Railway engineering blog, April 16, 2024
- Variables | Railway Docs — Railway documentation, undated docs page (fetched October 21, 2026)
- Vercel April 2026 security incident — Vercel Knowledge Base, October 16, 2026 (last update)
- Zeabur October 2026 security incident (preliminary report) — Zeabur (Yuanlin Lin), October 19, 2026
- Fireworks October 2026 security incident — Fireworks AI security bulletin, October 9, 2026 (updated October 10)
- API key best practices: keep your keys safe and secure — Anthropic (Claude Help Center), undated help article (fetched October 21, 2026)
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.