What happened to AI developer platforms in October 2026?
On October 30, 2026, Wiz published a research post titled Black October for AI Developer Platforms. The report lists at least nine platforms that disclosed security incidents during the month. The list runs from Fireworks AI on October 6 to Northflank on October 30.
The nine are Fireworks AI (October 6), Andromeda (October 9), Zeabur (October 14), Lightning AI (October 15), OpenCode (October 16 to 17), Railway (October 20), Warp (October 23), CommandCode (October 28) and Northflank (October 30). They cover model serving, app hosting, build pipelines and AI coding tools.
The common thread is what the attackers wanted. Wiz says the public reports point to targeted exploitation, "explicitly hunting stored environment variables, with a focus on those granting AI access." Environment variables are the usual place where teams keep database passwords, cloud keys and model provider tokens.
The entry points were not identical. Fireworks, Zeabur and Lightning AI traced their incidents to credential access. Railway found privilege escalation in its build infrastructure. Warp pointed to a third-party vendor dependency, and OpenCode blamed a legacy system. Wiz says no single vulnerability or dependency links the incidents.
Several vendors reported indications of coordinated, automated attacks. Fireworks, OpenCode and Warp described signs of an "agent swarm." Andromeda's incident report called it part of an "industry-wide attack." OpenCode and CommandCode both attributed their incidents to an attempt at distillation.
Northflank was the most recent disclosure. Wiz alerted the hosting platform at 11:43 UTC on October 30, according to BleepingComputer. Northflank engineers reviewed the alert a minute later, patched network policy, and told customers to assume the worst.
The company's status page carried an unusually blunt instruction: "Assume all environment variables have been decrypted. Disable/rotate all keys." Northflank later said multiple customers had reported unauthorized use of AI API keys stored on the platform.
Northflank has not said how many customers were affected or how the attacker got in. BleepingComputer asked the company for details and had not received a response at publication. That gap matters, because customers cannot judge their exposure from the public record.
Why are AI API keys worth stealing?
An AI API key is a bearer credential. Whoever holds it can make model calls, and the bill goes to the account that issued it. Unlike a crypto wallet, it needs no second signature or password prompt. The key is the authorization.
That makes stolen keys a direct route to someone else's compute budget. Security researchers call the practice LLMJacking. Wiz has documented campaigns where attackers took over cloud billing accounts and ran model workloads on the victim's tab.
The economics explain the interest. Frontier models are expensive to run, and access to them is valuable to resellers. Wiz describes "a robust market for this type of credential" and identifies two operations that were using keys taken in the October breaches.
One resale site, llm-routing.com, advertised discounted access to frontier models and accepted payment in USDT, according to Wiz. Another, xingjiabiapi.org, offered access to a wide range of models. Wiz linked both to infrastructure that tested the stolen keys.
Distillation adds a second motive. A lab can train a smaller model by querying a larger one at scale, then keep the output. Railway said the attackers appeared to be after AI provider keys for exactly that purpose. OpenCode and CommandCode reached similar conclusions.
Platforms concentrate the risk. A single hosting provider may hold keys for thousands of teams, all in one database of environment variables. Breaching the platform is more efficient than phishing each customer, and the attacker inherits every tenant's spending power.
The Cloud Security Alliance describes that layer as a concentration risk. It notes that apps often route model calls through a host, a gateway, an evaluation platform and a coding tool. Each one holds working provider keys on someone else's behalf.
Environment variables also travel widely. They reach build jobs, preview deployments and background workers, and many teams reuse the same values across all three. A single leak therefore exposes more than one service.
The cost can arrive quickly. Two enterprise keys that Wiz examined produced about 2.5 million Amazon Bedrock calls and likely ran up over $100,000 in usage at list price. OpenCode users reported unauthorized charges ranging from several hundred dollars to more than $1,700 overnight, according to BleepingComputer.
What did the stolen keys look like in use?
Wiz reconstructed two cases in detail. Both keys belonged to enterprises, and both had been compromised through one of the vendor breaches. The report does not name which vendor held each key.
The first sign was a single model call from a residential IP address. It came within 30 minutes of the reported credential access. The call requested Claude Fable 5.1, failed, and fell back to Opus 5.5, which worked.
The attacker then went quiet. For several days, the key saw only 14 to 120 calls a day from a small Go client. The two keys in the study ran about a minute apart, which suggests one verification job checking that both still worked.
Four days later, a rotating proxy pool swept through a catalog of models. It tried Amazon Nova, DeepSeek, gpt-oss, GLM, Kimi, Grok, GPT-6 Astra and older Claude models. Every call worked except Fable, according to Wiz.
Then the volume started. One key made about 800,000 Bedrock calls over 30 hours, and roughly 90% succeeded. Only about 6% were throttled, because the key's policy allowed global cross-region inference profiles. Opus models dominated the traffic, led by Opus 5 at 36%.
The second key was restricted to US inference profiles. It surfaced in a reseller pool seven days after the initial validation call. After a checker found the working model IDs, the key made about 1.7 million calls in 13 hours, with more than a million successful.
Both cases used the same boto3 probe script, down to the version string, according to Wiz. Reused tooling is one of the few durable clues defenders can look for.
Wiz says the usage pattern looked like resold coding-agent traffic. Most calls carried a handful of uncached input tokens, which is typical of prompt caching, and returned a few hundred tokens. A long tail of calls carried tens of thousands of input tokens, consistent with many end users behind a reseller.
The attribution has limits. Wiz tied the keys to vendor breaches, but it could not prove that the resale operators carried out the original intrusions. The report also says it found no evidence linking those operators directly to the Black October attacks.
What the cases do show is a market. Stolen keys were tested, shared and used by more than one party. Wiz's phrasing is careful but clear: the activity is consistent with "an active resale market for these keys."
How bad were the Railway, Zeabur and Northflank breaches?
Railway gave a specific upper bound. In a preliminary report, it said at most 1.85% of all workspaces had some environment variables potentially compromised. That works out to about 100,000 workspaces, a small share of a large platform.
Railway's timeline runs from October 20 at 13:58 UTC to October 22 at 03:32 UTC. The company described "a sustained and targeted campaign to attack and breach our services." It also said the attackers were "attempting to obtain AI provider API keys to perform distillation attacks."
Railway disabled its build infrastructure during the response. It notified GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe, among others, and asked them to revoke keys. The company says the attacker did not access Railway user accounts, though it has not ruled out access to source code.
Encryption limited the damage but did not prevent it. Railway says the attacker first pulled secrets in encrypted form, then reached CI credentials that could decrypt some of them. It also warned that vendors reset more keys than were actually decrypted, so a revocation notice does not prove exposure.
Zeabur's outcome was worse. An attacker used leaked internal credentials to enter its shared cluster and some dedicated servers, then read the platform database. BleepingComputer reports that 321,810 accounts and about 3.2 million environment-variable records were exposed.
Zeabur's own report describes the root cause plainly. Long-lived admin credentials were stored in plaintext and could be used from the public internet. "The admin tokens had no expiry," the company said, and they had not been rotated since January 2024.
The intrusion reached further than the database. Attackers signed in as root to 101 GCP servers, according to BleepingComputer, and added SSH keys to 50 of them. They also attached 16 customer disk copies to their own virtual machines. Zeabur says it will shut down between December 1 and December 31, 2026.
Fireworks AI described a narrower incident. On October 6, an unauthorized party accessed environment variables used in evaluation jobs for a limited number of customer accounts. Fireworks says it found no evidence that models, datasets, training data, prompts or personal information were accessed.
OpenCode put its exposure at 1.4% of Console users. The earliest possible key exposure was October 17 at 00:30 UTC, according to the email it sent to affected users. Its co-founder said attackers had targeted the company for at least 48 hours using AI agents.
Northflank remains the open question. The platform enabled audit logs for all customers, including free users, and added secret rotation for PostgreSQL, MongoDB, MySQL, Redis, RabbitMQ and Minio. It has not published a root cause, an affected-customer count or a final timeline.
What should teams using AI APIs do now?
Start with rotation, and do it at the source. Removing a secret from a hosting platform does not invalidate the key. The key must be revoked with the provider that issued it, then replaced everywhere it was used.
Check each provider's usage and billing logs for calls you do not recognize. Look for unfamiliar model names, sudden volume, new regions or traffic from addresses you do not own. Wiz's cases began with a single test call before scaling up.
Railway recommends that every customer who signed up before October 21 rotate keys stored there. Northflank says to treat every environment variable as decrypted. Zeabur says to replace every password and key stored on its platform, even if it was already changed after the August incident.
Reduce the blast radius of the next breach. Use separate keys for each environment and service, so a staging leak cannot spend production budget. Grant the narrowest model and region access a workload needs. Set spend limits and quotas where the provider supports them.
Prefer short-lived credentials when a provider offers them. Long-lived keys are convenient, but they stay valid until someone revokes them. A stolen token that expires in an hour is far less useful to a reseller.
Watch for reconnaissance. Wiz's attackers enumerated quotas, mapped regional model availability and tested a catalog of vendors before the bulk traffic began. Alerts on new key creation, permission checks and cross-region calls can catch that stage.
Providers can also act on their side. Some OpenCode users reported that Google suspended their projects after detecting abusive activity, according to BleepingComputer, and Railway asked vendors to revoke keys en masse. A provider notice may therefore arrive before a platform confirms the scope.
Platform operators face the same lessons at larger scale. Encrypt secrets with a managed key service, avoid admin tokens without expiry, isolate build systems, and expose audit logs to every customer. Zeabur's post-mortem shows how one long-lived credential can undo a previous cleanup.
- •Rotate keys at the issuing provider, not just in the platform dashboard
- •Review model usage and billing for unfamiliar models, regions or volume
- •Use one key per environment and service, with the narrowest permissions
- •Set spend caps and alerts, and prefer short-lived credentials where offered
- •Enable audit logs and alert on key creation, quota probes and new regions
What to watch next
Railway says a final forensic report will follow. It should clarify what the attackers actually decrypted, whether source code was taken, and how the build infrastructure was breached. Those answers will matter to the roughly 100,000 workspaces in the affected group.
Northflank has not yet published a scope statement. The platform has confirmed unauthorized use of AI keys, but not the number of affected accounts or the entry point. A root-cause write-up would also show whether the attack matched the pattern Wiz described.
Zeabur's wind-down will run through December. Customers need to migrate services and rebuild any server that was compromised. The company says environment variables that customers moved to their own servers after the August incident avoided the platform database leak.
The resale market is the part to watch beyond these incidents. If stolen keys can be sold quickly, the incentive to steal them remains. Wiz linked two resale sites to stolen credentials but stopped short of tying them to the intrusions. Takedowns, payment tracing or provider-side revocation could change that calculation.
The Cloud Security Alliance has published a research note on the same pattern. It says "No vendor has publicly linked these incidents to a single actor." The organization also notes that the campaign framing so far comes from Railway alone. More independent analysis could establish whether the incidents share tooling or buyers.
For platform customers, the practical test is simple. If a provider cannot tell you which secrets were exposed, when, and how, treat every secret it held as compromised. Rotation is tedious, but it is the only response that does not depend on the vendor's investigation.