Railway's security disclosure says some customers' environment variables may have been decrypted, and it tells every user to rotate what they store there, including AI keys. An outside account's post frames the same incident as an attack aimed at AI inference providers, but Railway's own wording is more cautious than that.
In a post on X, @IntCyberDigest says hackers may have obtained customers' decrypted environment variables, that Railway paused deployments, and that the company believes AI inference providers are the real target. The post's screenshot shows the opening of Railway's own disclosure, "Security Disclosure: Wednesday October 21st." The screenshot matches the text on Railway's blog.

Image credit: @IntCyberDigest on X
What Railway's disclosure actually says
Railway says an unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents." Environment variables can hold API keys and database or registry credentials. On the AI side, Railway writes, "We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." That sentence describes what Railway believes the wider campaign is aimed at. It does not say AI providers were the target of this breach, and it does not say any provider was compromised.

Image credit: @IntCyberDigest on X
The same disclosure adds that "our initial analysis suggests the impact may be limited to a subset of users."
What Railway has already reset
Railway did some of the rotation itself. Its bucket guide says the company "performed the reset rather than asking you to." The S3 access keys for every storage bucket were invalidated and regenerated. GitHub tokens Railway held for accounts and services were also invalidated, and the GitHub tokens stored as registry credentials were removed from Railway. Those registry tokens still work on GitHub until you revoke them yourself, and you must reconnect GitHub to restore deploys.
Railway paused all deployments when it published the disclosure, so new credentials can only reach your services after builds resume. Some changes still need action from you. Services that read bucket credentials need a redeploy, because, as the guide puts it, "containers read variables only at startup." Private registry credentials require the Pro plan.
Railway's status page also says it "invalidated all Railway API tokens" in an update timed 04:17 UTC on 22 October. If you use an API token to integrate with Railway's public API, it will stop working, and you need to create a new one. Railway says it will contact affected customers directly by email, so check your inbox as well as your provider consoles.
What to check for OpenAI keys
Railway's OpenAI guide tells users to "revoke any API key that may have been exposed, review usage for requests you didn't make," and redeploy with a new key. In practice, that means:
Delete any key that may have been exposed in the project's API keys page, then create a replacement and update the variable on Railway.
Open Usage, select the affected project, and group by API key. Compare token volume, request counts and model mix against your normal traffic during the exposure window.
Review Billing for spend in the period and any credit grants that were used.
Check audit logs, if enabled, and member lists for key creation or changes you did not make.
Railway also publishes guides for Anthropic, Grok and OpenRouter; for those keys, use each provider's own console to review usage.
Railway's status page shows builds returning first for Enterprise workspaces, with Pro, Hobby and Free to follow in stages, as announced in its 04:00 UTC update on 22 October.





0 comments
No approved comments yet. You can start the conversation.
Leave a comment