# Black October: why AI platforms became vaults for valuable keys

> Wiz identifies several AI platform incidents. We examine their shared patterns, distinct causes and why attackers seek environment variables.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/black-october-ai-platform-key-theft-2026/

**Publication status as of November 4, 2026.** [Wiz Research](https://www.wiz.io/blog/black-october-for-ai-developer-platforms) has reconciled at least **nine incident reports in October** involving AI development platforms: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode, and Northflank. Its follow-up later added Brev, Trigger.dev and Chainstack as publicly reported incidents. The most visible commonality is the search for **environment variables and model provider access keys**. This proves neither a common vulnerability nor a campaign led by a single group.

## Why does a development platform have so many capabilities

To build, test, and deploy an AI product, a platform is often provided with model API keys, registry identifiers, database secrets, and access to code repositories. An environment variable is a convenient mechanism for passing these values ​​to a build or evaluation job. Its confidentiality then depends on the isolation of jobs, the separation between clients and controls on the people or services that can read the environment. The secret is encrypted or hidden in the interface, but must become usable again at some point for the authorized job.

This architecture creates a profitable objective: stealing an AI key sometimes allows you to directly consume paid inference, resell access or query models at scale. Wiz calls this category of abuse **LLMJacking** and describes, in its telemetry, compromised keys being tested and then used at high volume. The link between two key cases used after a supplier incident is documented by Wiz; this observation should not be extended to all the incidents on the list. Motives for *distillation* are claimed or inferred in some reports, but are not an established cause for every platform.

## Different published causes

[Fireworks AI](https://fireworks.ai/security/bulletins/october-2026-security-incident) describes unauthorized use of internal credentials and access to evaluation job variables on a limited number of accounts. [Zeabur](https://dash-new.zeabur.com/blogs/october-2026-security-incident) details durable admin tokens held in plaintext, an exposed cluster interface, and secrets read from multiple layers of its infrastructure. [Railway](https://blog.railway.com/p/preliminary-report-october-security-incident) reports an escalation in its build infrastructure, followed by the reading of some encrypted and then decrypted variables. These three stories are enough to show that “AI key leak” describes a shared **result**, not an identical exploit.

Wiz also cites incidents for which public reporting remains more limited. A review article must therefore keep a mental column “directly observed”, “declared by the platform”, “reported by a third party” and “hypothesis”. The overall figures do not add up neatly: some providers count accounts, while others count workspaces, keys or jobs, and the same customer can appear in several services.

## A downstream risk chain

After reading a key, the attacker can test if it works, measure its quotas and use it from another infrastructure. Rotating a secret on the hosting platform does not revoke a key issued by the model provider. The correct answer should track the **provenance and entitlement of each secret**: who issued it, what APIs it allows, where it was stored, when it was accessed, when it was revoked, and what calls were made between those dates. High-volume paid use is a possible effect, not the only one: a key can also access data, models or compute resources depending on its scope.

To look for this class of incident, an authorized audit would test the isolation between jobs and clients, control plane privileges, how variables are decrypted for execution, and the ability to read secrets through logs, backups, or support tools. It would then separate the investigation of the platform from the investigation of the key issuers. The Railway case shows that secrets encrypted at rest remain vulnerable if the identifiers allowing them to be decrypted are obtained in the same chain.

The value of “Black October” is therefore a question of architecture and economics of the attack: AI platforms concentrate immediately monetizable access. The answer cannot be as simple as asking customers to “change the password”; it requires rotation of third-party keys, review of uses and lasting reduction in reading capacity by the host infrastructure.

**Primary sources:** [cross-sectional analysis Wiz](https://www.wiz.io/blog/black-october-for-ai-developer-platforms), [Fireworks AI bulletin](https://fireworks.ai/security/bulletins/october-2026-security-incident), [Zeabur report](https://dash-new.zeabur.com/blogs/october-2026-security-incident), [Railway report](https://blog.railway.com/p/preliminary-report-october-security-incident).