Railway says up to 100,000 workspaces may have exposed secrets, but the figure is a ceiling

The number is a ceiling, not a victim count

Railway says no more than 1.85% of its workspaces, about 100,000, may have had some environment variables potentially compromised. That is the company’s upper bound for possible secret exposure. It is not a count of confirmed victims, accounts accessed, credentials decrypted, or people affected. Railway says the encryption design prevents one compromised key set from automatically exposing every workspace, but its preliminary report does not publish the denominator, the list of affected workspaces, or an independently audited calculation.

The latest change is a second Railway status notice, dated 24 October. Railway says providers asked it on 23 October for another batch of potentially affected keys. The batch sent to OpenAI and Anthropic also contained some replacement keys created after the incident because Railway could not filter them by creation date. Providers may therefore have revoked clean replacement keys. Railway says those revocations do not show that the replacement keys were compromised, and says customers whose keys still work do not need to repeat completed rotations.

That correction matters operationally. A provider’s revocation email is evidence that the provider disabled a key, not proof that an attacker read or used it. The incident itself is serious enough without turning a precautionary control response into a second-breach claim. The factual baseline below is Railway’s preliminary account, last checked against the company’s 24 October status notice.

What Railway says happened

Railway is a cloud platform for building and running applications. Customer projects can store environment variables, which applications use to connect to databases, model providers, source-code hosts, container registries and other services. These values function as credentials: someone who can read a usable secret may be able to act against the service that issued it, depending on its permissions and remaining validity.

The incident crossed a platform boundary. Railway reports unauthorized access to a subset of its own internal systems, followed by access to CI credentials and artifacts that held further API access. Its report then describes an unauthorized query of encrypted customer variables, with some values decrypted. This is not the same as Railway user-account takeover. Railway says individual customer accounts were not accessed. It has not ruled out access to customer source code and says it will address that question in a final forensic report.

Zoom

The timeline contains a meaningful shift. At 04:24 UTC on 21 October, Railway says encrypted secrets had been pulled but the attacker could not yet decrypt them. From 05:27 to 07:25, Railway says the attacker obtained credentials for its CI environment and decrypted artifacts containing additional API access. From 07:25 to 09:18, Railway found database evidence of an unauthorized query of encrypted environment variables, some of which were decrypted using a combination of compromised credentials. The report does not identify the exact variables, projects or services involved.

This is why “encrypted” is not the end of the analysis. Encryption can protect stored data against a reader who lacks the necessary keys. Railway’s account says the attacker later acquired or used other credentials and artifacts that enabled some decryption. The relevant control question is therefore not simply whether values were encrypted at rest. It is how the service separated data-encryption keys from the systems and identities able to retrieve or use them, and how quickly those identities could be contained. Railway has not yet published enough architecture detail to independently test that path.

Railway says it uses envelope encryption: a data-encryption key protects the secret, while a separate key-management layer protects that data key. The company says the database query alone cannot reveal which specific customer variables were decrypted. That limit is consistent with a system where database records do not themselves expose the complete key relationship. It also explains why Railway broadened notifications and provider revocations beyond a precisely enumerated list.

Incident clock: discovery is not disclosure

Railway’s own timeline starts at 13:58 UTC on 20 October, when monitoring paged its on-call engineer for abnormal latency. The company says it confirmed at 03:32 UTC on 22 October that the attacker no longer had access to internal systems. That is a 37-hour-34-minute interval, calculated from the two published timestamps. It is Railway’s reported investigation and access-removal window, not a measured dwell time from an independently established initial compromise.

Railway preliminary report and status notices. Dates and times are source-reported; all times shown in UTC.

When	Railway reported	Why it matters
20 Oct, 13:58	Abnormal latency triggered an on-call alert.	First timestamp in Railway’s reported incident window, not a proven initial-access time.
20 Oct, 14:03 to 19:53	Potential build-infrastructure privilege escalation was investigated; pipelines were paused. A later evidence update indicated broader parallel escalation.	The first remediation assessment was superseded by new evidence.
21 Oct, 04:24 to 05:23	Encrypted customer secrets were pulled; Railway says the attacker could not yet decrypt them.	Retrieval of ciphertext is distinct from reading usable credentials.
21 Oct, 05:27 to 09:18	CI credentials and artifacts provided additional API access; an unauthorized query of encrypted environment variables followed, with a subset decrypted.	Railway could not determine which exact variables were decrypted from the query alone.
21 Oct, 09:25 or 09:35	The report timeline says vendors were notified at 09:25. Its FAQ says 09:35.	The primary report contains a ten-minute inconsistency. We retain both times.
22 Oct, 03:32	Railway says attacker access to internal systems had ended.	This is the vendor’s containment confirmation, not the end of its forensic investigation.
24 Oct, 13:57	Railway clarified that some provider revocations affected newer replacement keys sent in an over-inclusive follow-up batch.	A provider revocation does not establish that a replacement key was accessed.

The report also says Railway declared an incident at 17:03 on 20 October, while the public incident page later linked from the report starts on 21 October. These can describe different internal and public status records, but Railway has not explained the discrepancy in the report. The access window, the public disclosure, customer notification and service restoration are separate milestones, not interchangeable dates.

The scope problem: workspaces, variables and people are different units

Railway says at most 1.85% of workspaces had some variables potentially compromised, about 100,000 workspaces. It also says the number of customers it considers high risk is larger than that ceiling because the company cannot identify every variable that may have been decrypted and is applying a broader risk assessment. A workspace may contain multiple projects, services and variables; a person or company may control multiple workspaces. The published figures cannot be converted into a confirmed customer or individual count.

What the preliminary report and 24 October Railway status notice establish, and what they leave unresolved.

Question	Stated by Railway or reported elsewhere	Not established
How many workspaces?	At most 1.85%, numerically about 100,000, may have had some variables potentially compromised.	A confirmed count of affected customers, individuals, variables, or successful secret use.
Which secrets?	Some encrypted environment variables were queried and a subset decrypted, according to Railway.	The exact keys, project/service mapping, or whether a given key was read by the attacker.
Were Railway accounts taken over?	Railway says individual user accounts were not accessed.	Independent validation of Railway’s account-level finding.
Was source code accessed?	Railway says it is not ruling this out and will answer in its final forensic report.	Whether repositories, build inputs or customer source code were read or copied.
Were credentials misused?	A crypto investigator was reported as alleging about $371,000 in wallet theft across at least 19 EVM chains.	A victim-by-victim link between the transfers, a Railway variable, the incident, or an identified attacker.
Why were replacement keys revoked?	Railway says the 23 October provider batch to OpenAI and Anthropic included newer keys because filtering by creation date was unavailable.	Whether any replacement key was exposed; Railway says provider revocation is not evidence that it was.

Railway is both the affected platform and the source of the workspace ceiling, technical chronology and containment account. It says it has engaged external incident-response specialists and authorities. Those are relevant steps, but the public report does not include an external report, a customer-level dataset or an independent audit of the 1.85% calculation. The company has an obvious interest in explaining its response accurately and reassuring customers; the same self-reporting also remains the only source for several incident details. A final forensic report should make those limits easier to test.

The outside claim: a wallet drain is not yet a Railway finding

CryptoSlate reported that a crypto investigator attributed roughly $371,000 in transfers across at least 19 EVM-compatible chains to keys stored on Railway. This is a serious lead for affected wallet operators, but it is not a figure Railway confirms in its incident report. The underlying public chain transfers can show that assets moved; they do not, by themselves, prove who controlled the sending wallets, whether the signing keys were exposed through Railway, or whether the transfers were unauthorised.

The timing is concerning but not conclusive. The reported first transfer time, 19:36 UTC on 21 October, comes after Railway’s 09:25 or 09:35 UTC vendor-notification time and before the company’s 20:19 to 22:10 UTC public disclosure and credential-rotation announcements. That overlap does not establish that a given wallet key was extracted from Railway. A proper attribution needs the affected wallet owners, evidence that the relevant key was stored in the platform, and a transaction-level explanation that rules out other sources of compromise.

Railway’s preliminary report says investigators believed the attacker was seeking AI-provider API keys for model-distillation attacks. That is the company’s assessment of apparent intent, not an independently demonstrated objective. The report does not say wallet private keys were among the variables queried, nor does it establish whether any accessed credential was used outside Railway. The wallet-theft allegation and the vendor’s model-key theory should therefore remain separate lines of inquiry until evidence connects them.

What the encryption story does and does not tell customers

A platform can encrypt secrets at rest and still face a serious incident if an attacker can reach the service identities or build artifacts that allow decryption. This is not an argument against encryption. It is a reminder that secret storage has multiple control points: who can query the record, who can retrieve or unwrap the data key, what CI systems can access, how long credentials live, and whether access is individually attributable in logs.

Railway says its attackers used CI credentials to decrypt artifacts with further API access. That suggests the build system and its credentials formed part of the incident’s privilege chain. The company says it accelerated a move from third-generation isolated multi-tenant builders to fourth-generation single-tenant environments, rotated storage-bucket credentials, rebuilt internal tooling from validated source and added a mass-revocation capability. These are company-reported mitigations. The public report does not provide independent test results showing that the same escalation path is no longer possible.

For customers, the practical exposure is determined by what a stored credential could do, not only by its label. An AI API key might incur usage charges or expose a provider account. A source-control token might read repositories or create workflows. A registry token might publish or pull images. A database password might expose data or permit changes. These are conditional capabilities based on the key’s scope and the external service’s controls; Railway has not said that all these outcomes occurred.

What UK teams should take from it

The NCSC’s cloud-platform guidance says organisations should prefer workload-specific service identities, a distinct identity for each use case, high-entropy secrets where keys cannot be avoided, and a consistent process for changing them. It also recommends monitoring access to secrets for anomalies, including one identity accessing many secrets, and invalidating the previous secret when a response is triggered. That guidance does not determine whether Railway met a legal or contractual duty in this incident. It gives UK teams a practical way to assess their own dependency chain and prepare for a provider-side event.

If a UK organisation stores credentials with any hosted build or deployment provider, it should know which services those values can reach, which identities can read or unwrap them, how to revoke them outside the platform, and how to redeploy if the provider pauses builds. Teams subject to regulated or contractual incident reporting should separately assess their own notification obligations with the relevant legal and regulatory advisers. Railway’s public account does not establish that a UK-regulated customer suffered personal-data loss or that a reportable event occurred for any particular organisation.

Response order for teams using Railway

Do not assume a replacement was safe solely because it was created after 21 October, and do not assume it was compromised solely because a provider revoked it. Use the provider’s action notice and Railway’s explanation together. The two sources describe separate parts of the process: Railway supplied a broad batch, while the issuing provider decided which keys to revoke.

What would change this assessment?

A final report that identifies initial access, the systems and identities involved, the exact reason envelope encryption could not map a database query back to individual variables, the method used to calculate the 1.85% ceiling, the source-code finding, and independent incident-response conclusions would materially improve the public record. So would a clear reconciliation of the 09:25 and 09:35 vendor-notification times and a customer notification count expressed separately as workspaces, customers and individual credentials.

For the crypto allegation, the decisive evidence would be a documented chain from affected wallet owners to keys stored in Railway, plus a transaction analysis that links specific unauthorised signatures to those keys. A wallet flow chart or total-loss bar chart before that evidence exists would turn an allegation into an apparent fact, so none is included here.

The exposing question is not whether Railway has now restored builds. It is whether the company can show, with an independently reviewable forensic account, how a build-system access path reached a subset of customer secrets, how it bounded that subset, and why the replacement-key batch could not be filtered before providers were asked to revoke it.

Primary guidance and reporting used in this draft. Railway’s report is preliminary; the status notice is current as checked on 24 October 2026.

Source	What it supports
Railway preliminary report, 22 October	Timeline, access to CI credentials and artifacts, secret query and subset decryption, 1.85% ceiling, reported account/source-code status, mitigations and customer advice.
Railway status notice, 24 October	Replacement-key revocation clarification and customer next steps.
NCSC, Using a cloud platform securely	Service identities, secret management, rotation, monitoring and anomaly response guidance for customers.
CryptoSlate, 22 October	Secondary account of an investigator’s crypto-loss estimate, which remains unconfirmed by Railway and is not independently linked here.