Railway's disclosure asks a harder question: who can decrypt your secrets?

Security·21 October 2026

A production API key can be encrypted on disk and still become readable during a breach. The question is who has the authority to decrypt it, and whether that authority sits inside the system being compromised.

Railway's October 21, 2026 security disclosure reports possible unauthorized access to encrypted customer environment variables, including decrypted contents for some of them. Railway recommended rotating stored variables and private registry credentials, and reviewing service logs. Its investigation was ongoing when this post was written.

The disclosure does not establish the attack path or final scope. We cannot claim that installing Seekrit would have prevented Railway's incident. We can explain a deployment design that removes upstream credentials from the hosting platform's environment store, and the conditions that make that separation meaningful.

Encryption is only part of custody

Encryption at rest protects stored bytes. If a system can also obtain the plaintext, compromising enough of that system can expose the values without breaking the encryption algorithm.

That is a general architectural distinction, not a finding about Railway's implementation. Ask it of every secrets product, including ours: what would an attacker need in addition to the stored ciphertext?

For Seekrit's ordinary secret-storage path, values are encrypted client-side. The API stores ciphertext and wrapped environment keys. Decryption happens in an authorized client, such as the CLI, an SDK, or the credential proxy. A copy of Seekrit's database alone does not supply those clients' decryption keys. The security model describes that boundary and its exceptions.

One exception matters here: third-party sync. Enabling it grants a sync connection the ability to decrypt a particular environment and push its values to a destination. If you sync to Railway, Railway holds a usable copy. Seekrit storage does not make that destination copy immune to exposure.

One token is still a credential

Moving application secrets into Seekrit and starting the app with seekrit-run is useful. Values are fetched and decrypted when the process starts, so individual provider keys need not be copied into the hosting platform's variables or baked into an image.

But the launcher needs SEEKRIT_TOKEN. A Seekrit service token contains its own private key and can decrypt the environments granted to it. If that token is stored in the same platform's environment-variable system, an attacker who obtains it can use that authority to retrieve and decrypt those secrets. The running application also receives plaintext values.

Runtime injection improves how secrets are distributed. It does not, by itself, remove the hosting platform from the credential trust boundary.

Keep the credential where the request is authenticated

For supported HTTP APIs, Seekrit's credential broker lets the application send a placeholder such as {{seekrit:OPENAI_API_KEY}}. The proxy applies the real key to a permitted outbound request. The application does not need the upstream key.

To protect against the hosting platform obtaining that key, place the proxy and its Seekrit service token in a separately controlled runtime outside that platform. A sidecar on the same host can separate two processes; it does not separate them from whoever controls the host.

The broker must have an authenticated, protected ingress. Its outbound rules must restrict destinations, methods, paths, and which secrets may be injected. A placeholder is a name, not caller authentication.

Under those conditions, a disclosure confined to the application's stored variables would not yield the upstream credential: neither that value nor a Seekrit token capable of decrypting it is there. A stolen broker-access credential can still let an attacker make permitted requests, incur costs, or obtain application data. Narrow policy and provider-side limits remain necessary. The broker and its infrastructure are trusted components too.

Make the boundary explicit before the next incident

For each production credential, identify where the value lives, where its decryption authority lives, and who can invoke it. Then choose the boundary you need. Some workloads can use runtime injection. Sensitive HTTP integrations can put credential use behind a separately hosted broker. Registry pulls and direct database connections need their own treatment; an HTTP broker does not automatically cover them.

If a credential may already have escaped, moving it does not invalidate the old copy. Rotate it at the issuing provider and follow Railway's current guidance.

Seekrit gives you a way to separate storage, decryption, and use. The benefit comes from deploying those pieces across the boundary you want to protect. For a concrete plan, read how to keep API keys outside your Railway deployment.