decrypted · 23 october 2026 · ransomware and cybercrime · vulnerabilities and patching · digital sovereignty

Railway's secrets scare: what a hosting platform holds on your behalf

Railway, a cloud platform developers use to run applications, said on Wednesday that an unauthorised third party may have read customers' stored secrets, and it has told every user to replace them. The company says its initial analysis points to a subset of users, but the instruction applies to everyone. For UK organisations hosting anything on a platform like this, the question is plain: where do your keys live, and who else can read them?

What Railway has said

Railway's own notice, dated 21 October, says it detected anomalous activity "earlier this morning" involving systems that store customer environment variables. These are the settings an application reads when it starts, and in practice they are where developers park API keys (the way one program talks to another) and database passwords. Railway says an unauthorised third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents."

Railway paused all deployments while it investigated. It also says it believes this is part of a series of attacks on platform companies aimed at compromising AI inference providers, and that it has told those providers to revoke keys. It has named no other victims, so treat the wider campaign as an unverified claim.

The mechanism, in plain English

Think of a hotel that locks your valuables in a safe but keeps the safe's key on a hook behind reception, so staff can fetch things quickly. Encryption at rest protects the safe from someone who steals the disk. It does not protect you from someone who gets into the part of the system that is allowed to open it. For a platform to hand secrets to your running application, something in its estate must be able to decrypt them, and an intruder who reaches that something gets the plaintext.

Railway's follow-up guidance for AWS users shows what the defender then faces. Create a replacement access key, deactivate the old one, and search CloudTrail, AWS's activity log, in every Region for calls such as creating users, roles or access keys. That is clean-up of someone else's incident, done on your own time.

The Secure by Design lesson

Three design decisions shrink the damage.

Short-lived credentials. A key that expires in an hour is worth little once stolen. A long-lived key pasted into a variable is worth a great deal.
Narrow scope. A key limited to one service, from one address range, cannot start servers in your cloud account.
Your own vault. Keep secrets in a store you control and fetch them at runtime, so a platform compromise yields a reference rather than the secret.

The cost is a few days of engineering and a habit of rotation. Compare that with rotating everything at once, under pressure, while your deployments are frozen. Ask for an inventory of every secret held with a third-party platform, who can rotate each, and how long that takes. Opinion, not advice.

Also this week

Arista SD-WAN console exploited. Arista's Security Advisory 0199, dated 22 October, covers VeloCloud Orchestrator On-Prem, the console that runs SD-WAN, where site links are managed from one place. It says CVE-2026-114625 (the flaw's public reference number) is known to be actively exploited. It is an SQL injection, a way of tricking a database into obeying an attacker, scored 9.9 on the CVSS zero-to-ten severity scale. The lowest role, Enterprise Read Only, is enough to start, so a stolen low-privilege login becomes an administrator. Fixes are 5.2.3.18, 6.1.3.10 and 6.4.2.12 and later, and Arista says hosted and dedicated deployments are already patched, which leaves the risk with organisations running it themselves. Arista also says the console is exposed by default. Restrict web access to administrative networks, block the two attacking addresses it lists, and review administrator activity and web access logs. BleepingComputer counts it as the fourth Arista zero-day exploited this year. Management planes should never face the internet by default.

Undersea cables get tougher law. The Record reports the government proposed on Thursday up to 14 years in prison for deliberately damaging undersea cables and pipelines, 10 for reckless damage and two for gross negligence. It would replace the Submarine Telegraph Act 1885, which allows a maximum fine of £1,000 and five years for deliberate damage. The Record puts the stakes at 99% of the UK's international data traffic and 74% of its gas supply. Matt Western, who chairs the Joint Committee on the National Security Strategy, said the legislation was written in a different age. The consultation closes on 14 January 2027. Deterrence helps, but the part you control is resilience: know which cable your connectivity depends on, and whether a second route exists.

Both stories share a theme: the infrastructure you rely on is rarely the infrastructure you control, so ask who holds the keys and where the second route is.

Sources