Black October - Nine AI Developer Platforms, No Single Flaw → Environment Variables as the Target → Plaintext Credentials at Zeabur → Separately, 2.5 Million Calls on Stolen Bedrock Keys
Between October 6 and October 30, 2026, at least nine AI developer platforms reported security incidents: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank. Wiz gathered them in a report titled Black October and says no single vulnerability or dependency links them, and most are still under analysis. The recurring target is stored environment variables, especially keys that grant access to AI models. Stolen keys of that kind feed LLMjacking, where someone else's cloud account pays for model use. This page is a composite, and the two halves should not be read as one attacker. The platform half follows Zeabur, whose preliminary report is the fullest public record. The downstream half follows two Amazon Bedrock abuse cases that Wiz attributes to one of these vendor breaches without naming it. At Zeabur, a cluster admin token that never expired, stored in plaintext in a private repository, helped open a shared cluster, and the attacker went on to read 3,218,965 environment variable records from the platform database. Zeabur will shut down on December 31, 2026, which it calls an operational decision. Northflank, the latest case, told customers on October 30 to assume all environment variables were decrypted, and has not published how the attacker got in.
Disclosure: this page draws heavily on research published by Wiz, and Wiz also responded to the Northflank incident. The site's author works at Wiz. Every source is linked so you can read it directly.
📄 Wiz - Black October for AI Developer Platforms ↗ 📄 Zeabur - October 2026 security incident (preliminary report) ↗ 📄 Railway - Security disclosure ↗ 📄 BleepingComputer - Northflank ↗Zeabur's report has an unusually complete paper trail. A shared cluster admin token was created in January 2024 with no expiry, and on January 20, 2026 it was written in plaintext to a private configuration repository. An August incident then exposed a GitHub App private key. Zeabur replaced that key on August 31 without rotating the credentials in the repository, and its October report corrects its own August statement that all internal admin keys had been dealt with.
How the attacker obtained the credentials is unconfirmed. Zeabur's leading hypothesis links them to the August key, and it says that link remains unproven.
Written to repository: January 20, 2026, in plaintext
August rotation: GitHub App key replaced; repository credentials missed
How obtained: unconfirmed; hypothesis ties it to the August key
The first use of a Zeabur AWS key came at 01:36 UTC on October 14, and the first shared cluster access with an admin token followed at 01:40. Two conditions made that token usable from anywhere: it had no expiry, and the admin interface was reachable from the public internet. Zeabur also records unauthenticated API access from a later-abused address on October 10, and failed SSH attempts against three dedicated servers on October 13.
01:40 UTC October 14: first shared cluster access with an admin token
Why it worked: no expiry, and a public admin interface
At 12:39 UTC the attacker read the settings and secrets of services on the shared cluster. Zeabur confirms the content was read in regions with complete read logs and cannot confirm the rest. From 13:40 until 17:04 commands ran inside database containers: Zeabur counts 865 services, 736 of them PostgreSQL databases belonging to n8n deployments, and says not every command succeeded and that it cannot fully confirm what data was obtained.
The concentration of secrets is the point of attacking a platform. On a shared cluster every customer's API keys live behind one control plane, so one admin credential reaches all of them in a single read.
13:40 to 17:04 UTC: commands inside database containers
Scope: 9 regions partly confirmed; 865 database services, not every command succeeded
Unknown: what data was taken from those databases
A second path ran through Google Cloud. Root passwords sat in plaintext in GCP dedicated server initialization settings, and Zeabur assesses that the attacker used an old GCP key to read them. Zeabur records root sign-ins to 101 servers belonging to 92 users, attacker SSH keys added to 50 of them, five new virtual machines, and 16 copies of customer disks attached.
Zeabur found those root passwords on September 3, during a run of root sign-ins from an unknown source that reached about 98 servers on September 5 alone. The weakness was not fixed before October, and Zeabur cannot confirm whether the September activity was the same attacker.
Read with: an old GCP key, by Zeabur's assessment
Result: root sign-ins to 101 servers, SSH keys on 50
Also: 5 virtual machines created, 16 customer disk copies attached
The two paths met on October 15. A compromised GCP server was used to add a node to the internal network at 15:30 UTC, which allowed a connection to the platform database. Around the same time, about 53 production secrets were read between 14:52 and 16:51, a backup access key was read at 15:04, and a user database backup was downloaded through a presigned URL at 15:42.
The platform database was read between 16:10 and 16:47: 3,218,965 environment variable records and 321,810 accounts, both confirmed. The attacker also called the API as two impersonated accounts, one of them a Zeabur employee's. Zeabur's last observed attacker activity was at 21:05 UTC on October 15. Projects that had moved their variables off Zeabur after August were outside this read.
15:42 UTC: user database backup downloaded by presigned URL
16:10 to 16:47 UTC: platform database read
Confirmed: 3,218,965 environment variable records, 321,810 accounts
Wiz's list shows how little the entry points have in common. Fireworks AI, Zeabur and Lightning AI cite credential access. Railway believes access came through privilege escalation in its build infrastructure, Warp suggests a third-party vendor dependency, and OpenCode points to a legacy system. OpenCode and CommandCode attribute their incidents to attempted distillation, meaning training a cheaper model on a stronger model's outputs.
Railway detected anomalous activity on October 21 on systems that store customer environment variables, said a third party may have obtained decrypted contents for some of them, and paused all deployments. It notified upstream AI providers to revoke keys proactively. Northflank received an alert from Wiz at 11:43 UTC on October 30, later confirmed that customers had reported unauthorized use of AI API keys, and has not said how the attacker got in or how many customers are affected.
Build infrastructure: Railway
Vendor dependency: Warp (suggested)
Stated motive: distillation, per OpenCode and CommandCode
Undisclosed: Northflank's entry point and customer count
Wiz attributes two Bedrock abuse cases to one of these vendor breaches and does not name which. In both, the first unauthorized activity came within 30 minutes of the reported credential access: a single InvokeModel call from a residential address, in a one-minute sweep across multiple organizations. The call requested Claude Fable 5.1, failed, and fell back to Opus 5.5, which succeeded.
After that, each key saw 14 to 120 calls a day from the same small Go client, with calls on the two keys running about a minute apart. Low-volume validation like this is easy to lose in normal traffic. Wiz does not establish a direct link between its listed indicators and the wider Black October incidents.
First call: one InvokeModel from a residential address
Follow-up: 14 to 120 calls a day from one Go client
Linked to: one vendor breach, not named by Wiz
In Case A, four days after validation, a rotating proxy pool tried one call per model. A few hours later a boto3 script enumerated Bedrock and EC2 quotas, and bulk traffic began 22 seconds after that. Over about 30 hours the key carried roughly 800,000 calls, about 90% of them successful. Its policy allowed global.* cross-region inference profiles.
Case B's key was limited to us.* profiles. Seven days after validation it appeared in an apparent reseller pool, where thousands of calls failed because the pool requested global.*. A checker then found working model IDs, and over about 13 hours one Level 3 address made about 1.7 million calls, more than a million of them successful. The same script ran in both cases, down to the version string, and Wiz says the two likely ran up over $100,000 at list price. The restriction cost the abusers a few hours and did not stop them.
Case B: about 1.7 million calls over about 13 hours, 1 million+ successful
Enumeration to flood: 22 seconds in Case A
Cost: likely over $100,000 at list price, per Wiz
Wiz found two operations touching these keys. One, which it calls momo, had access to both keys, and its infrastructure includes a site advertising discounted frontier-model access for USDT. The same address hosted a console titled ARTEX on October 8, the name of the framework on the Storm-0940 and VAPOR PANDA pages, though Wiz does not connect them. Zeabur later named that address in its own compromise, and that overlap does not show Zeabur's keys are the ones in these cases. The other, Xingjiabi, enumerated the Case A key and tested the Case B key after the abuse had started.
Wiz could not tie either operator to the floods. It reads their checks as evidence of an active resale market, and one snapshot showed a page scoring users for distillation behavior, possibly to avoid account suspensions.
Xingjiabi: 38.246.114.118, enumerated the Case A key
Attempted: PutAccountDataRetention with the Case B key
Limit: neither operator tied to the floods by Wiz
🛡 How to Defend Against This Chain
us.* profiles caused thousands of failed calls and a detectable delay. Set budget alerts and quotas low enough that abuse hits a ceiling, and give each workload its own key so that one theft does not spread.InvokeModel from a new network, catalog probing with one call per model, and quota enumeration, particularly when bulk traffic follows seconds later. Review billing as a security signal too. If you used any of the named platforms, rotate stored keys now and check provider usage logs.