Railway breach: which keys and passwords to change now

Your developer says “we host the app on Railway” or “we use an AI tool called OpenCode”, and then you see the news: those companies lost customers’ secrets. Do you need to change anything? What? In what order?

Short answer: if your developer used any of the three tools below, the passwords and keys stored in them should be treated as stolen and replaced. Deleting them from the tool is not enough. If your website is a normal WordPress site on ordinary hosting, you are most likely not affected, but one question to your developer settles it.

What happened, in plain English

Three separate incidents hit tools that developers use behind the scenes, all within days of each other in October 2026.

Railway is a platform where developers run websites, apps and databases. Its own preliminary report says unusual activity began on 20 October 2026 and that on 21 October an attacker pulled encrypted secrets, got hold of internal credentials and decrypted some customers’ stored settings. Railway says at most about 1.85 percent of workspaces may have had settings compromised, but it told every customer to change their secrets anyway. The report also says Railway has not ruled out that customers’ source code was accessed.

OpenCode is an AI coding tool. According to TechCrunch, attackers broke into an older part of its online console, where some users had saved the keys that let them use AI services. About 1.4 percent of console users were affected, and OpenCode emailed them. Developers reported unauthorised charges on their OpenAI, Anthropic and Google accounts, some in the hundreds of dollars and a few over $1,000.

LiteLLM is a tool that sits between a business’s software and AI services. According to CSO Online, on 21 October 2026 a booby-trapped version, 1.107.0, was published. It was built to steal cloud passwords, AI keys and the secrets used to publish software, and to let the attacker come back later. The poisoned files were online for about two hours before removal.

What is a “key”, and why does it matter?

A key (often called an API key or a secret) is a long password that one piece of software uses to talk to another. Your developer’s code uses one to take card payments, one to send email, one to reach the database, one to call an AI service.

Unlike your own password, nobody types it. It sits in a settings file, often called environment variables, so the code can read it. That is exactly what was exposed.

Anyone holding a key can act as your software, with no login page, no two-factor code and no alert. That is why the OpenCode victims saw bills appear overnight: the thief simply used the stolen key.

Does this affect me?

Probably not if:

• Your site is WordPress, WooCommerce or similar on ordinary shared or managed hosting.
• Your developer has never mentioned Railway, OpenCode or LiteLLM.

Possibly yes if:

• A developer built something custom: a web app, a customer portal, a booking system, a chatbot.
• Your developer uses AI coding tools, or your product calls an AI service.
• You are not sure what your site runs on.

You do not need to guess. Send your developer or agency this message:

“Did we use Railway, OpenCode or LiteLLM for anything, including test versions? If yes, which passwords, keys and database logins were stored there, and have all of them been replaced at the source?”

“Replaced at the source” is the important part. If a key was stored in Railway, removing it from Railway does nothing: the thief already has a copy. The key must be cancelled where it was issued, for example in the payment, email or AI company’s own dashboard, and a new one created.

What to ask your developer to change, in order

Ask for the list to be done most-dangerous first. In general terms:

1. Anything that touches money. Payment keys and any key that can send money or refunds.
2. Anything that touches customer data. Database logins and storage keys.
3. Anything that can run up a bill. AI service keys, cloud account keys, email-sending keys.
4. Anything that controls your code. Logins that connect to your code store and the systems that publish your site.
5. Then the rest. Everything else that lived in the same settings.

Two more requests worth making:

• A written list of what was changed and when. If the developer cannot tell you, assume it was not done.
• A check that nothing was used by someone else. Ask them to look at each provider’s usage and login history from 20 October 2026 onwards for activity nobody on your team recognises.

If a database was open to the whole internet, Railway’s own advice includes closing that access. That is a question for your developer, not a setting for you to change.

If the AI tools bill you

Several of the OpenCode victims found out from a bill. Do two things now, even if you think you are safe:

• Check your AI and cloud billing pages for charges you do not recognise. Contact the provider first if you find some, and keep the dates. Railway itself suggests going to the AI provider first for fraudulent spend.
• Ask for a spending limit on each account, as a safety net. It is not a replacement for changing the key, because a stolen key can still be abused up to that limit.

What nobody knows yet

Be careful with any article that claims to know more than this:

• Railway says it cannot tell exactly which settings were decrypted, so it asked everyone to change them. It has also not ruled out access to source code. Its final report is pending.
• OpenCode has not said how the attackers got in. It described the attack as an AI “distillation” effort, but TechCrunch notes some people doubt that claim.
• For LiteLLM, how the attackers first got access to the publishing process is not established. Security experts warn that finding no signs of a break-in does not prove a system is clean.

We will not guess. If this changes, we will update this page.

The lesson for the next time

You cannot stop a tool vendor from being breached. You can make sure a breach costs you little:

• Know where your keys live. One short written list: what each key does and who can change it.
• Keep keys few and narrow. A key that can only do one job does less damage when stolen.
• Never put a key in your site’s visible code. Scanners find those within hours.
• Have a way to change them quickly. Replacing a key should take an hour, not a week.

Our Black October explainer covers this month’s other attacks, and our UpdraftPlus guide shows another case where stolen keys gave attackers a way in.

Want us to check yours?

• Free: run the website security checker. It looks at your site from the outside and flags a password or secret key sitting in the page code that every visitor downloads, which should be treated as already stolen.
• Done for you: our website security service can go through your site, tell you what is exposed and help your developer put things right, one careful change at a time.

Then reach us:

• Email hello@wpfoss.com
• WhatsApp +254 118 271 160
• Tell us what you need

If your developer has confirmed they used one of these tools, say so in your first line and we will start there.

Sources and further reading

• Railway: Preliminary report on the 21 October security incident
• BleepingComputer: Railway warns devs to rotate secrets after potential breach
• TechCrunch: Hackers hit AI coding tool OpenCode, running up charges on users’ AI accounts
• CSO Online: LiteLLM release pipeline hacked to distribute credential-stealing malware