“This attack was attempting to obtain AI provider API keys to perform distillation attacks.”

That line is from Railway’s preliminary incident report, published October 22. An attacker spent about a day and a half inside Railway, from October 20 to October 22, moving from the build infrastructure to CI credentials to the database of customer environment variables. Railway says up to 1.85% of its workspaces were at risk, and it told everyone to rotate.

Railway was the third one in eight days.

The advice for AI keys used to be simple. Get them out of your code and into server-side environment variables on a proper platform. The customers of these three platforms did exactly that. Their keys left anyway, because the platform was the thing that got breached.

So plan for that. Assume the place you store your keys will fall someday, and decide now what limits the damage.

Zeabur, OpenCode, Railway

Zeabur went first, on October 14 and 15. Its incident report is the most candid of the three. The attacker read 3,218,965 environment variable records and data on 321,810 accounts, and was “mainly looking for API keys they could use directly, especially keys for AI services.” The root cause, in Zeabur’s own words, was that “long-lived admin credentials were stored in plaintext.” Those tokens had never expired and hadn’t been rotated since January 2024. They most likely leaked in an earlier breach in August.

Zeabur is shutting down on December 31.

OpenCode came next, on October 17. Attackers reached provider keys that 1.4% of its Console users had stored there. TechCrunch reported developers waking up to spending alerts from OpenAI, Anthropic and Google, with charges in the hundreds of dollars and a few over a thousand. Anthropic and Google blocked the exposed keys. OpenAI worked on refunds.

Then Railway.

The n8n detail

One number in Zeabur’s report should worry anyone running workflow automation.

The attacker ran commands inside 736 n8n instances on Zeabur’s shared cluster. Zeabur checked 607 of them, and 602 had their n8n encryption key sitting in an environment variable. That key is what protects every credential n8n stores: your CRM login, your email account, your database password.

Think of a safe with the combination taped to the door. Once the environment variables were read, the safe didn’t matter.

If your team uses n8n, Make or anything similar, check where its encryption key lives this week. And yes, that applies on platforms that haven’t been breached yet.

PHP, Node.js and Python, all in one week

The other thing this week showed is speed. OpenCode’s charges piled up overnight. And three of the languages most business software runs on had a rough week of their own.

PHP shipped patches on October 21 for PHP2Shell, two critical bugs that let an unauthenticated attacker run code on the server. Wiz found them using Gemini 4 Argon and GPT-5.6 Sol, and says one researcher with frontier models did in about a week what used to take a world-class team months. Amazon’s honeypots caught an exploit attempt on October 17, four days before any patch existed, per The Hacker News.

Amazon’s CISO, CJ Moses, put it plainly: “The time from patch to working exploit is shrinking for structural reasons.”

Node.js released its October security update the same day, ten CVEs across 22.x, 24.x and 26.x. The worst is an out-of-bounds write in the bundled Brotli decoder. Node.js says an attacker who can feed Brotli data to your app’s node:zlib “can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution.” OpenAI Codex Security is among the credited reporters. This site runs on Node, and we moved it to 22.23.4 this morning.

Python’s turn came a day earlier. On October 20 the packaging maintainers told everyone to upgrade pip immediately after eight eMudhra intermediate certificates turned out to have compromised private keys. pip ships its own certificate bundle, so patching the operating system doesn’t help. Christian Heimes didn’t soften it. “Updating pip is the only reliable fix.” Then Pillow, Python’s image library, shipped 13.0.0 with three critical fixes, one of them a bug “found by Anthropic using Claude,” The Hacker News reported.

Frontier models are finding these bugs, for defenders and for whoever else is looking.

If your process for changing a production secret takes a week and two approvals, it was built for a different threat.

What I’d do Monday

I wrote a key checklist in September after Anthropic’s threat report on stolen AI keys. Keep it. This week adds a few things on top.

• Patch the runtimes this week. PHP from the October 21 release, Node.js 22.23.4 or later, pip 26.2.2, Pillow 13.0.0. Then rebuild your container images, because an old image keeps shipping the old pip.
• Write down every third party that holds one of your keys. Hosting, automation, the coding tool your developers use, the agent someone connected last month. I checked our own projects today and none run on Railway or Zeabur. I only know that because I went and looked.
• Put a spending cap on every key at the provider. When the platform falls, the cap keeps working with nobody touching it.
• One key per platform. If Railway asks you to rotate, you rotate Railway’s key and leave your mobile app alone.
• Rehearse rotation before you need it. Railway asked customers to rotate while deployments were paused, so new keys couldn’t reach running services. If changing a key at your company depends on the one person who knows where it lives, that person is your risk.

When we audit a company that already runs AI in production, keys are among the first things we look for. Where they live, who else holds them, what happens if one leaks at 3 a.m. on a Saturday. The rest of what we check is in our piece on AI code security beyond the scanner.

Start with the list of third parties. It takes an afternoon, and you’ll know where you stand before the next platform writes its incident report.

Find out who holds your AI keys