TL;DR: Were your API keys leaked in the Railway or LiteLLM breach, and what should you do?
On 21 October 2026, two tools many AI builders rely on were hit on the same day. Railway, the app hosting platform, said an attacker may have read decrypted environment variables, which is where most of us keep API keys and database passwords. Separately, LiteLLM, the popular open source proxy for routing calls to many AI models, had a poisoned version (1.107.0) published to PyPI and Docker with a credential stealer inside. If you deploy on Railway, rotate every secret stored there. If you installed LiteLLM 1.107.0 or pulled its latest Docker image during the window, treat that machine as compromised. Then check your AI and Stripe usage for charges you didn't make.
Every bootstrapped AI product has the same soft spot: a handful of keys that can spend money. Your OpenAI or Anthropic key, your Stripe secret key, your database password. They sit in environment variables, and you rarely think about them again.
Yesterday, attackers went after exactly those keys, in two different places. There's no public evidence that the two incidents are connected. But the lesson is the same, and if you build on Railway or use LiteLLM, you have work to do today.
What happened at Railway
On Wednesday 21 October 2026, Railway published a security disclosure by Jacob Cooper. Earlier that morning, the company said, it "detected anomalous activity involving systems that store customer environment variables".
Its investigation so far shows that an unauthorised third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents". Railway believes this is part of a series of attacks on platform companies "with the aim of compromising AI inference providers", and says it has asked those upstream providers to revoke keys proactively.
Railway thinks the impact may be limited to a subset of users, but it recommends that every user rotate all environment variables, API keys and private registry credentials, and review logs for unusual activity. It will email the customers it confirms were affected.
The incident also took the platform offline for building. According to the Railway status page, problems started around 07:24 UTC on 21 October. All new builds were paused in every region, including EU West, and the dashboard, API and support site were down or degraded for hours. Railway also rotated all storage bucket credentials and signed some users out. As of 03:00 UTC on 22 October, builds were still paused. That's the painful part: you can change your keys now, but you can't redeploy your app to pick up the new ones until builds return.
Overnight Railway published 13 step-by-step guides. They cover checking for unexpected usage on OpenAI, Anthropic, OpenRouter, Grok and Stripe; rotating PostgreSQL, MySQL, MongoDB and Redis credentials; and checking GitHub, AWS and Google Cloud for strange access.
What happened at LiteLLM
LiteLLM lets you call more than 100 models through one interface, and many indie hackers run it as their AI gateway. On the same day, LiteLLM's incident report says its release pipeline was compromised and version 1.107.0 was pushed to PyPI and Docker with compiled malware inside.
- PyPI: all seven litellm==1.107.0 wheels were poisoned and live from 11:39 to 13:23 UTC.
- Docker Hub: the v1.107.0, latest, main-latest and main-stable tags pointed to the infected image from 11:46 to 14:20 UTC. On GitHub's registry they were pulled by 13:51 UTC.
- Safe versions: LiteLLM says all earlier versions are safe and tells open source users to pin 1.106.2. Customers on its private enterprise registry weren't affected.
The malware runs every time Python starts in the infected environment, including when you run pip. According to the security researchers who reported it in GitHub issue #47826 and to Aikido's analysis, it grabs saved browser passwords, SSH keys, cloud credentials, .env files, the environment variables of running processes and config files of AI coding tools such as Claude Code, Cursor, Codex CLI and Gemini CLI. If the proxy's database is reachable, it dumps every upstream provider key LiteLLM stores. A second component was built to check for new commands from the attacker every hour, though Wiz says that stage was never seen active.
And the stolen keys were used quickly. Wiz Research reported that about 4.5 hours after the theft, the attacker started testing stolen AWS credentials from CI runners and Kubernetes nodes. Each one was checked, then used to list the AI models available on Amazon Bedrock. Wiz calls the pattern consistent with "LLMjacking": using someone else's cloud account to run AI models on their bill.
How the attacker got in
LiteLLM's explanation is a warning for every small team that ships fast with AI coding tools. After a previous incident in March, the company had hardened its releases: a private release repo, trusted publishing, immutable Docker tags, signed images. The attacker got around all of it with stolen tokens.
LiteLLM says the attacker held the GitHub CLI login tokens of three engineers. One belonged to an organisation owner, and the attacker used it to switch off branch protection and push a change that let the release workflow build from a lookalike repository: Berri-AI/litellm instead of BerriAI/litellm. A second engineer's account approved the production release. A third deleted the workflow records afterwards.
Where did the tokens come from? LiteLLM found an unexpected user account in an internal LiteLLM deployment that was exposed to the public internet. It believes the attacker read the tokens from that deployment's logs. LiteLLM also says it has observed "specific situations in which Claude Code will embed a user's GitHub CLI OAuth token into a response body", so when response bodies are logged, those tokens can end up in LiteLLM logs. How the attacker first got into the deployment isn't confirmed yet; LiteLLM suspects a recently patched vulnerability.
Read that twice if you route your coding agent through a proxy that keeps full logs. Your logs can turn into a key store.
The two incidents side by side
Sources: Railway security disclosure and status page; LiteLLM incident report (21-22 Oct 2026).
It wasn't a quiet day elsewhere either. TechCrunch listed critical PHP vulnerabilities, four high-severity Node.js fixes, a compromised Indian certificate authority and the TiDB Cloud breach announced on Monday, and noted that those issues were unrelated to each other. If you run a WordPress or PHP site, our post on the emergency PHP patch covers what to update.
Why this keeps happening to AI builders
AI keys are now worth stealing. A leaked OpenAI, Anthropic or Bedrock credential can be resold or burned on someone else's bill within hours, and agents and proxies collect many of those keys in one place. Railway itself says the attacks it saw were aimed at AI inference providers.
This isn't the first warning this month. The OpenCode breach exposed saved OpenAI, Anthropic and Google keys, and the Rank Math PRO malware showed how a trusted plugin update can carry a backdoor. The pattern is clear: the tools that save a small team the most time also hold the most secrets.
There's also a dependency lesson. When a platform pauses builds for a day, you can't ship a fix, rotate a key or redeploy. We saw a similar single-provider problem in the Revolut outage caused by a Google Cloud failure. You don't need a second host for everything, but you do need a plan for a day without your main one.
The European angle
- GDPR's 72-hour clock (Adopted). If leaked database credentials were used to reach customer data, that's a personal data breach. Under Article 33 of the GDPR, you as the controller must notify your data protection authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to put people at risk. Write down what you checked and when, even if you find nothing. Our step-by-step GDPR compliance guide explains who does what.
- Your hosting provider is your processor. Under the same article, a processor must tell the controller about a breach without undue delay. Railway says it will email the customers it confirms were affected; watch your inbox and keep that email.
- Cyber Resilience Act reporting (Adopted). If you sell software that customers install, such as an app, plugin or desktop tool, the EU's Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities since 11 September 2026. Its main obligations apply from 11 December 2027. A poisoned dependency inside your product is exactly the kind of event it was written for.
- EU region doesn't mean EU-only risk. Railway's builds were paused in EU West too. Hosting your app in Amsterdam doesn't protect secrets stored in a provider's central systems.
What to rotate, and how to check it
Sources: Railway's recovery guides (22 Oct 2026) and the LiteLLM incident report.
What this means for you
- Rotate first, investigate second. If you're on Railway, replace every secret stored there today, starting with keys that can spend money: AI providers and Stripe. Set the new values now and redeploy as soon as builds return.
- Check LiteLLM versions everywhere. Run pip show litellm on servers, CI runners and laptops. If you find 1.107.0, don't just reinstall: LiteLLM says to delete the malicious files first, or better, rebuild the environment from scratch on 1.106.2. Then rotate everything that machine could reach.
- Stop pulling by latest. Pin Docker images and packages to a version number or digest, so a poisoned release can't slide into your next deploy.
- Put a ceiling on every key. Spending limits and alerts turn a stolen AI key from an unlimited bill into a capped one. Give each service its own key so you can revoke one without breaking everything.
- Clean your logs. If your AI proxy or agent logs full requests and responses, check them for tokens and keys, and limit who and what can read them. Never expose an internal proxy to the public internet without authentication.
- Write it down. Note what you rotated, what you checked and what you found. It's your GDPR record and your playbook for the next incident. Our guide on building security into a startup helps you turn it into a routine.
For the rest of the month's incidents, our cybersecurity news for October 2026 page keeps track, and the AI news for October 2026 roundup covers the model and tool launches.
Are you getting customers from AI search yet?
More and more traffic is coming from Perplexity, ChatGPT, Grok and other AI tools.
👉 Rank on ChatGPT
FAQ: Railway and LiteLLM breaches
Was Railway hacked?
Railway said on 21 October 2026 that an unauthorised third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. It believes the impact may be limited to a subset of users but advises all users to rotate their environment variables, API keys and registry credentials.
Are Railway builds working again?
As of 03:00 UTC on 22 October 2026, Railway's status page said builds remained paused. Railway plans to bring them back in stages, starting with Enterprise workspaces. Check status.railway.com for the latest.
Which LiteLLM version is compromised?
Version 1.107.0. All seven PyPI wheels were poisoned between 11:39 and 13:23 UTC on 21 October 2026, and the v1.107.0, latest, main-latest and main-stable Docker tags pointed to an infected image between 11:46 and 14:20 UTC. LiteLLM says earlier versions are safe and recommends pinning 1.106.2.
How do I know if I'm affected by the LiteLLM malware?
Run pip show litellm. If any environment ran 1.107.0, or a container ran the affected image, LiteLLM says to treat it as compromised. Files named cook.pth or sitecustomize.py in site-packages confirm it, but not finding them doesn't prove the machine is clean.
Are the Railway and LiteLLM incidents connected?
Nobody has said so. They happened on the same day and both put API keys at risk, but neither company has linked them. Railway says the attack it saw was part of a series targeting platform companies to compromise AI inference providers.
Do I have to report a leaked API key under GDPR?
A leaked key on its own isn't automatically a personal data breach. If the key or database credentials were used to access personal data, GDPR Article 33 requires the controller to notify the data protection authority within 72 hours where feasible, unless the breach is unlikely to put people at risk. Document your checks either way.
About the Author
Violetta Bonenkamp, also known as MeanCEO, is an experienced startup founder with an impressive educational background including an MBA and four other higher education degrees. She has over 20 years of work experience across multiple countries, including 5 years as a solopreneur and serial entrepreneur. Throughout her startup experience she has applied for multiple startup grants at the EU level, in the Netherlands and Malta, and her startups received quite a few of those. She’s been living, studying and working in many countries around the globe and her extensive multicultural experience has influenced her immensely.
