What happened
Railway said the attacker began creating accounts on October 18, 2026, gained initial access on October 20 and was fully evicted by 09:24 UTC on October 21. On November 10, 2026, Railway published a full incident report that quantified the scope and financial impact of the October attack. An erroneously defined OIDC binding yielded short-lived cloud credentials, which led to an SSH key and a longer-lived credential capable of decrypting environment variables. The attacker also obtained Railway’s internal monorepo after escaping build isolation, then used the code view to probe additional routes.
Railway said at most 1.85% of workspaces, about 100,000, could have had environment variables decrypted; this is an upper bound, not a confirmed victim count. The attacker read 353 build histories and the decrypted data included linked-account tokens for 1,852 users. Railway estimated unauthorised spend on stolen keys at approximately $740,000. Railway reported no indication that customer Git repositories were downloaded or customer databases accessed.
Railway said the activity involved abliterated models and a harness similar to ARTEX, citing Wiz, but did not identify an exact framework version. No underlying model name or version was identified in the cited sources. The cited sources did not identify the operator’s prompts, permissions, safeguards or orchestration settings. Railway’s logs showed the attacker used the tooling to probe multiple routes, scan source code for escalation paths and prioritise AI-provider keys in database queries. Attribution posture: Railway did not name an actor and said it had not established whether the original attacker operated or supplied credentials to later resale services. The cited source did not publish the specific indicators described as Public indicators of compromise.
Why this matters now
The November post-mortem turns an earlier precautionary rotation notice into a confirmed downstream credential and fraud investigation. Environment variables commonly hold AI, cloud, database, payment and deployment credentials; replacing a value inside Railway is insufficient unless the old credential is revoked at its issuing provider, dependent workloads are redeployed and provider logs show that unauthorised use has stopped.
The quantified impact also changes third-party risk. Railway identified linked-account tokens, provider-specific fraudulent charges and a build-and-CI path that exposed internal source code and decryption capability. Enterprises using developer platforms should treat secret stores, build systems, OIDC bindings and orchestration machines as one connected trust chain rather than separate technical services.
The decision for security leaders
Assign one accountable owner to reconcile Railway’s notification, internal secret inventories and provider-side telemetry. The work must cover AI keys, cloud credentials, database access, payment services, registry credentials, OAuth tokens and bring-your-own-key agent tokens. A credential is not contained until the issuer has revoked it and the dependent workload is operating with a replacement.
Bring finance, legal, privacy and procurement into the response. The newly quantified fraudulent usage creates reimbursement and loss-accounting questions, while the upper-bound workspace figure does not identify every exposed variable. Supplier assurance should therefore document both confirmed impact and the limits of Railway’s logging rather than treating an absence of notification as proof of no exposure.
Evidence of closure
- Secret register shows replacement values, revocation timestamps and redeployment status.
- Provider audit logs show no unauthorised use after rotation.
- Finance reconciliation records disputed charges, refunds and accepted residual loss.
- Customer notices and account records confirm affected OAuth and BYOK tokens were reset.
The Security.io assessment
Railway’s report is unusually detailed and supports high confidence in the attack path, containment timeline and stated upper bounds. It does not establish that every workspace in the upper-bound population lost a secret, nor that customer databases or repositories were accessed. The material enterprise fact is narrower and still serious: customer-held secrets were decrypted, some tokens were reset and subsequent fraudulent usage was observed.
Railway said public IOCs remain withheld pending law-enforcement approval. Customers must therefore rely on their own provider audit logs, billing records, secret-rotation evidence and workload redeployment history. The AI element is supported as observed tooling and targeting behaviour, but the exact models, framework version and operator configuration remain unidentified; the available evidence does not establish capabilities beyond the observed mechanics.
Questions for the morning meeting
- Which production credentials were entrusted to Railway?
- Can finance distinguish legitimate AI consumption from fraudulent token usage?
- Do vendor contracts assign refund and notification duties for stolen customer secrets?