Black October: AI Developer Platform Breaches and Stolen Keys

AI developer platform breaches at nine vendors in October 2026 shared one target: the environment variables where customers store cloud AI keys. Wiz Research traced two of those stolen keys into roughly 2.5 million Amazon Bedrock calls worth more than $100,000 at list price, and that usage runs on the customer's account, not the vendor's.

What happened in Black October for AI developer platforms?

Black October is Wiz Research’s name for nine separate security incidents at AI developer platforms in October 2026. Its October 31 post, “Black October for AI Developer Platforms: nine incidents, more to come,” warns the count will rise.

The victims are services developers wire into their daily work: model hosting, coding agents, AI terminals and deployment platforms. Fireworks, OpenCode and Warp each reported signs of what they called an “agent swarm” attack. Andromeda described its incident as part of an “industry-wide attack.”

OpenCode and CommandCode said the goal was model “distillation”: harvesting enough frontier-model output to train a competing model. “Agent swarm” is the victims’ own phrase, quoted by Wiz, and nobody has yet published what it looks like in logs.

What is established is narrower and more useful: no single vulnerability or dependency links the incidents. There is no one bug and no one patch. There were many doors, and behind each one the attackers wanted the same thing.

Each victim named a different root cause:

• Credential access: Fireworks, Zeabur and Lightning.
• Build infrastructure: Railway cited “privilege escalation in our build infrastructure.”
• Third-party vendor dependency: Warp.
• A legacy system: OpenCode.

Lightning had already been hit in the “Mini-Shai Hulud” supply-chain campaign, a reminder of how AI tooling keeps inheriting other people’s compromises, as with the LiteLLM supply-chain poisoning. If a platform has lost credentials once, check whether it rotated every secret it held afterward.

Detail is thin. Most incidents were still under analysis when Wiz published. Only Zeabur (a full write-up) and Railway (a preliminary report with a timeline) had released anything substantive.

Zeabur’s outcome should get procurement’s attention: the company says it is shutting down because of the incident. A vendor that closes after a breach cannot tell you what it held, confirm what was rotated, or answer your regulator’s questions. For small AI vendors, exit planning is now a practical requirement, not boilerplate for the contract.

Why were stored environment variables the prize?

Across every public report, attackers hunted stored environment variables, specifically those granting access to AI models and cloud AI services. Wiz frames this as a pattern rather than one confirmed campaign, and names the Cloud Security Alliance as a notable exception among observers that have connected the incidents.

The mechanics are simple. Developer platforms ask customers to store secrets as environment variables so builds, agents and deployed apps can call outside services. A coding agent needs a model key. A hosted app needs a cloud access key.

On a multi-tenant platform, those values sit in one place an attacker can reach after a single privilege escalation or one stolen admin credential. From there, the attacker does not need to break into each customer. The customers have already stored their credentials there.

AI keys turn into money faster than most secrets. Frontier-model inference is expensive, resellers offer it at a discount, and some buyers want large volumes of model output for distillation. Wiz calls distillation a demand driver for stolen AI credentials and notes it is notably alleged against Chinese AI labs. Stolen keys have both a retail and a wholesale market.

Do not expect the cloud provider to absorb the damage. Under AWS’s shared-responsibility model, managing access keys is the customer’s job. A valid stolen key authorizes Bedrock requests without any flaw in Bedrock itself, and nothing in the reporting suggests the hosted models were compromised. This is an identity, third-party and usage-governance problem on your side of the line.

How were two stolen Bedrock keys checked, then flooded?

Wiz documented two enterprise cloud AI keys, Case A and Case B, and attributes their abuse to one of the vendor breaches. Both keys had previously been used heavily from the compromised vendor’s infrastructure. The sequence gave defenders days of warning before the expensive part.

Stage 1: a one-minute validation sweep

The first unauthorized action was identical in both cases: a single InvokeModel call from a residential IP address, within 30 minutes of the reported credential access at the vendor. Each call was part of a one-minute sweep testing stolen keys across multiple organizations. The request asked for Claude Fable 5.1, failed, and fell back to Opus 5.5, which succeeded.

Stage 2: low and slow

For the following days, each key saw only 14-120 calls per day from the same small Go client, with the two keys running in lockstep about a minute apart. That fits one job checking that a batch of stolen keys still works. At that volume nobody notices on a bill. You only see it if you watch who calls Bedrock and from where.

Stage 3: model inventory and quota mapping

Case A escalated four days after validation. A rotating proxy pool ran a catalog probe across dozens of addresses, one call per model across several vendors: Amazon Nova, DeepSeek, gpt-oss, GLM, Kimi, Grok, GPT-6 Astra and older Claude models. Every call worked except Fable.

A few hours later, a boto3 script on a residential address enumerated Bedrock and EC2 quotas, and bulk traffic began 22 seconds after. Within half an hour, a second host mapped quotas and model availability across regions with more than a thousand calls in under a minute. Quotas are capacity limits, not security boundaries: the attacker read them to size the flood.

Stage 4: the flood

Case A then ran about 800,000 Bedrock calls over thirty hours, roughly 90% successful, until the key was remediated. Traffic came first from the residential address, then overnight from a Level 3 hosting address. Opus models made up three quarters of successful calls, led by Opus 5 (36%), Opus 5.5 (22%) and Opus 4.8 (10%).

Case B ran about 1.7 million calls over thirteen hours from a single Level 3 address, with more than a million successful. Usage spread across a dozen Claude models; Opus 5.5, Sonnet 4.5 and Opus 5 made up three quarters of successful calls.

The token profile points to resale. Typical calls sent a handful of uncached input tokens, the signature of prompt caching, and returned a few hundred output tokens. A long tail carried tens of thousands of uncached input tokens. Wiz reads this as resold coding-agent traffic: many end users behind a reseller, not one abuser with a script.

At list price, the two cases alone likely ran past $100,000. That is Wiz’s estimate, not a billed figure, and it surfaces late. AWS cost data typically lags actual usage by hours, so a 13-hour flood can be over before a budget alert fires. A billing dashboard is not an intrusion alarm.

Why did key scoping change the outcome?

Case B’s key was scoped more tightly, and that visibly slowed the attacker. It could invoke Bedrock only via us.* cross-region inference profiles. Case A’s policy permitted global.* profiles, the attacker routed every call through them, and only about 6% were throttled.

Cross-region inference profiles let Bedrock spread requests across AWS Regions for capacity, and a global profile offers the widest pool. When an apparent reseller pool picked up Case B seven days after validation and requested global.*, it produced thousands of failed calls over four hours, from rotating hosting addresses each active for about 15 minutes.

The restriction bought time but did not hold. Early the next morning, a checker on a shared VPN exit found the working us.* model IDs. Two hours later, a boto3 script on a Level 3 address retested global.* and us.* and enumerated Bedrock and EC2 quotas. Wiz says it matched the Case A script down to its version string: the same toolchain used against multiple victims.

Within minutes the flood began. Nearly all calls that did not succeed were throttled, because without global routing the traffic ran into the account’s regional quotas.

	Case A	Case B
Key scope	global.* profiles allowed	us.* profiles only
Validation to escalation	4 days	7 days, then 4 hours of failed global.* calls
Flood	~800,000 calls in 30 hours	~1.7 million calls in 13 hours
Successful calls	about 90% of the total	over 1 million of the total
Throttled calls	about 6%	nearly all unsuccessful calls
Top models	Opus 5, Opus 5.5, Opus 4.8	Opus 5.5, Sonnet 4.5, Opus 5

Two lessons follow. Scoping keys to approved inference profiles creates friction, and Case B’s four hours of failed global.* calls were a clear detection signal: failed calls are evidence of probing, not noise. But scoping alone did not stop more than a million successful calls. Detection and fast revocation have to sit behind it.

Who resells the stolen access: “momo” and “Xingjiabi”

Wiz linked the keys to two overt LLM resale operations it calls “momo” and “Xingjiabi,” both selling discounted access to frontier models. This is the market that makes the theft pay: LLMJacking, the hijacking of cloud AI access, feeding LLM brokers who repackage it.

Wiz is explicit that it cannot definitively establish how these resellers relate to the initial compromise or the floods. It can show that both had access to the keys and tested them from their own infrastructure.

“momo” centers on one IP address whose linked infrastructure goes back to 2025. In early 2026 it hosted personal sites, including one titled “Mo’s self-built cloud drive.” From March 2026 it advertised LLM services, with sites titled “ChatGPT Team seat redemption” and “ChatGPT account-pool management.” A resale site linked to it is still active, offering discounted frontier-model access paid in USDT.

On October 8, 2026, a subdomain on that IP hosted a page titled as an ARTEX autonomous penetration testing console. That was four days before Zeabur’s timeline shows the same address targeting its infrastructure, on October 12-14, and Zeabur has named the IP publicly. In late October, the address ran API key checks on both case keys and attempted a PutAccountDataRetention call with the Case B key.

The ARTEX name will be familiar from the ARTEX AI data theft case in South Korea, where police said an autonomous pentesting framework was used in most of more than 90 breaches. Nothing published connects that case to this IP. The overlap is a name on a web page, and we do not treat it as attribution.

“Xingjiabi” runs a public discount API site. A subdomain resolved to its infrastructure from September 10, 2026. That host enumerated the Case A key, listing inference profiles and models per region and paging through every Bedrock quota, and manually tested the Case B key. Both checks came after high-volume abuse from unrelated addresses had already begun.

The site also hosted a page titled “蒸馏检测监控” (distillation behavior detection) that scored users as “high risk,” “watch” or “normal.” Wiz suggests this may show the reseller trying to avoid association with distillation, which can get accounts suspended. That monitoring protects the reseller, not the victims.

Wiz published a table of four IP addresses seen testing stolen keys between October 18 and 30. Pull the IOCs directly from the Wiz post, and keep its caveat in mind: it has no evidence tying those IPs to the Black October attacks. Shared proxy, VPN and hosting pools rotated frequently, so a match is a lead, not proof.

What should Cyprus and EU firms check now?

Start by finding out whether any of your keys lived on an affected platform, then contain before you investigate.

1. Inventory. Ask engineering, not procurement, which AI developer platforms hold your secrets. Coding agents, AI terminals and PaaS accounts are often paid for on a team card and never reach the vendor register. Check against the named victims: Fireworks, OpenCode, Warp, Railway, Zeabur, Lightning, Andromeda and CommandCode.
2. Contain. Preserve logs, then disable or rotate every cloud AI key stored on those platforms and remove it from vendor and CI configuration. Changing your password at the vendor does nothing to a key the attacker already copied.
3. Fix logging. Amazon Bedrock model-invocation logging is separate from CloudTrail and off by default. Confirm CloudTrail records Bedrock API activity in every region, including regions you never deploy to. Neither source reconstructs activity from before it was enabled, so switch both on today.
4. Hunt the timeline from October 1. Look for a lone InvokeModel call from a residential address, small daily call counts from an unfamiliar Go client, one-call-per-model bursts across many addresses, quota enumeration followed seconds later by bulk traffic, and failed global.* profile requests.
5. Investigate account-level calls you did not make. An unexpected PutAccountDataRetention or similar configuration change from an AI key is an incident, not an anomaly.
6. Scope what remains. Replace long-lived IAM user keys with short-lived role credentials where the platform supports it. Restrict permissions to the model IDs and inference profiles you use, and deny global.* unless you need it.
7. Assess data, not just spend. Establish what your applications sent through the vendor: customer data, source code, credentials, regulated financial records. That answer drives your regulatory decisions.

What we find when we test AI integrations

In our engagements, the AI key in a platform environment variable is rarely narrowly scoped. More often it is an IAM user access key created during a proof of concept, granted broad Bedrock permissions on all resources, never rotated, and owned by a developer who has since moved teams.

The same key frequently sits in two or three places: the coding agent, a CI pipeline and a hosted demo app. Rotating it in one place breaks the others, so nobody rotates it. Wiz’s Case A is that key. Case B is what the same key looks like after someone spent an hour on its policy.

For every AI credential in your estate, can you name its owner, every place it is stored, which models and profiles it can call, and how fast you could revoke it at 2 a.m.? Any “not sure” is your exposure. An AI supply chain security audit builds that inventory, and an AWS penetration test maps what a stolen key could reach beyond Bedrock.

What do DORA, NIS2 and GDPR expect after an AI vendor breach?

For regulated Cyprus firms, a breached AI vendor is a third-party risk event first, and possibly a reportable incident second.

DORA has applied since January 17, 2025. Banks, payment institutions, EMIs, investment firms and other covered entities must manage ICT third-party risk and report major ICT-related incidents to their competent authority, in Cyprus usually CySEC or the Central Bank of Cyprus.

A coding agent holding production cloud credentials is an ICT third-party service, whether or not it appears in your register of information. If it does not, that gap is a finding in itself. DORA’s classification and reporting rules are separate from NIS2’s notification timetable, so firms in scope of both should not assume one report covers the other.

NIS2 entities face the same supplier-security question from a different angle: did you assess the security of the vendors holding your keys, and can you show the evidence?

GDPR is a separate assessment. A personal-data breach generally requires notifying the Commissioner for Personal Data Protection without undue delay and, where feasible, within 72 hours, unless it is unlikely to risk people’s rights and freedoms.

A stolen AI key alone does not prove personal data was breached. Prompts containing customer records, outputs stored by the vendor, or systems reachable from the key can change that. Decide on evidence, and record the reasoning either way.

What is still unknown

You will be making these calls with gaps. No victim has defined an “agent swarm” technically. Wiz does not name which vendor leaked the Case A and Case B keys. Most of the nine incidents lack published root-cause detail, and Wiz expects more victims. Treat your first assessment as provisional and revisit it as vendor reports land.

Our NIS2 and DORA compliance readiness work covers this overlap: which AI vendors belong in the register, what evidence you need from them, and how a vendor incident flows into your own reporting.

FAQ

What is Black October for AI developer platforms?

It is Wiz Research's name for nine separate security incidents at AI developer platforms in October 2026. The attacks used different entry points but all targeted stored environment variables holding AI and cloud AI credentials.

Which AI developer platforms were breached in October 2026?

Platforms named in public reporting include Fireworks, OpenCode, Warp, Railway, Zeabur, Lightning, Andromeda and CommandCode. Wiz counts nine incidents and expects more.

What is LLMJacking?

LLMJacking is the theft and abuse of cloud AI credentials to run model inference at the victim's expense. Stolen access is often resold through discount LLM broker sites, which makes the theft easy to monetize.

How much did the Amazon Bedrock key abuse cost?

Wiz estimates the two documented cases alone likely exceeded $100,000 at list price, from about 800,000 and 1.7 million Bedrock calls over 30 and 13 hours respectively.

Why is Zeabur shutting down?

Zeabur says it is closing its business as a result of its October 2026 security incident, which it has described in a full public write-up.

How can companies detect stolen cloud AI credentials?

Enable Bedrock model-invocation logging and confirm CloudTrail coverage in every region, then hunt for lone InvokeModel calls from residential IPs, low daily call counts from unfamiliar clients, quota enumeration and failed cross-region profile requests.

If your developers have stored cloud keys with coding agents or AI platforms, we can show you what those keys reach before someone else does. See our AI supply chain security audit.