Black October: AI Developer Platform Breaches and Industrialized LLMjacking

Key Takeaways

In October 2026, at least nine AI developer and application hosting platforms disclosed security incidents in which attackers reached stored customer secrets. Wiz Research named the period “Black October” and has since added at least three more platforms whose incidents were reported in early November [1]. The affected companies span inference providers, AI coding tools, and general-purpose platform-as-a-service (PaaS) hosts. Wiz reports that the entry points differed from case to case, but that all public reports describe attackers hunting for the same thing: stored environment variables, especially those holding AI provider API keys [1].

Taken together, the incidents point to a credential supply chain that now runs at industrial scale. Stolen keys were checked within minutes, probed quietly for days, and then used in bulk. In two Amazon Bedrock cases Wiz investigated, that bulk use came to roughly 800,000 and 1.7 million model calls and, by Wiz’s estimate, more than $100,000 in list-price usage [1]. Wiz also identified reseller operations selling discounted frontier-model access that interacted with the stolen keys. However, Wiz says it has no evidence tying those resellers directly to the platform intrusions [1].

From this evidence, CSA draws five conclusions for defenders. First, an AI key stored on a third-party platform is only as secure as that platform’s build system, key-management path, and incident response, so customers should treat every such long-lived key as one platform breach away from exposure. Second, deleting a key from the breached platform does not revoke it; only the issuing AI provider can invalidate it, and Northflank customers reported abuse within hours of the breach alert [9]. Third, restricting a key’s scope changed how abuse played out but did not prevent it. In Wiz’s Bedrock cases, a key confined to US inference profiles hit regional quota throttling for much of its traffic, while an unrestricted key with global routing ran at about 90% success, yet the restricted key still served more than a million successful calls [1][9]. Scoping therefore needs to be paired with hard spending and rate caps.

The remaining two conclusions concern motive and control. Several victims described the motive as “distillation,” meaning bulk harvesting of frontier-model outputs; that attribution is plausible but not independently established [1][10]. Finally, CSA assesses that platform operators are a main point of control. Zeabur’s post-incident report shows how long-lived plaintext admin credentials, an internet-reachable admin interface, and no detection let one intrusion expose more than three million environment-variable records [2].

Background

From Opportunistic Key Theft to a Market

Sysdig’s Threat Research Team coined the term “LLMjacking” in May 2024. It described attackers using stolen cloud credentials to reach hosted large language models and pass the cost to the victim, and it noted that reverse-proxy tooling let attackers resell that access [8]. In the two years since, CSA has followed the practice as it expanded. Early cases were opportunistic credential abuse. Later ones included IDE plugin campaigns that siphoned developer keys [15], and in October 2026, billing-account takeovers in which attackers attached their own projects to a victim’s cloud billing [12]. In each case the economics were the same. AI inference is expensive, a valid key can be used from anywhere, and the legitimate owner pays the bill.

Black October changed where the keys came from. Instead of collecting keys one developer or one public repository at a time, the attackers went after platforms that hold secrets for many customers, a shift CSA’s October 27 research note described in terms of a “concentration point” [10]. AI developer platforms make attractive targets because their purpose is to run customer workloads, and running a workload means decrypting its environment variables and injecting them at deploy or run time. Encryption at rest protects that data from someone who steals a disk. It does not protect it from an attacker who reaches the build system, the orchestration layer, or the decryption path itself [11].

The October Timeline

The table below summarizes the incidents Wiz grouped together, using the vendors’ own disclosures where this note could cite them. Fireworks AI, Andromeda, Lightning AI, Warp, and Command Code have not been cited here through primary vendor disclosures, so their rows rely on the compilations published by Wiz and by Helix, a commercial vendor whose blog post tracks the wave [1][9]. Some sources give different dates for the same incident. For example, Wiz lists Railway on October 20, while Railway’s public disclosure is dated October 21. These differences most likely reflect gaps between detection and disclosure, not conflicting accounts [1][6].

Wiz’s updated report adds NVIDIA’s Brev (activity October 4–20), Trigger.dev (November 1), and Chainstack (October 29–31), all reported in early November [1]. Their disclosures are recent and not yet detailed, so this note does not analyze them separately.

Security Analysis

Different Doors, One Objective

A central finding in Wiz’s analysis is a negative one. Wiz states that it found no single vulnerability or dependency linking the attacks [1]. The reported entry points include compromised or misused internal credentials (Fireworks, Zeabur, Lightning AI), build-infrastructure privilege escalation (Railway), a third-party vendor (Warp), and a legacy system (OpenCode) [1]. What the incidents share is what the attackers did after getting in. In Wiz’s words, all public reports highlight targeted exploitation that explicitly hunted stored environment variables, with particular interest in those that grant AI access [1]. Warp’s disclosure, which involved agent decision logs and telemetry, is a partial exception within the table above.

This pattern matters for defense. If one CVE or one compromised package had caused the wave, patching it would end the threat. Instead, the evidence suggests that one or more actors with a clear goal are working through the AI platform ecosystem using whatever weakness each target offers. Fireworks, OpenCode, and Warp each reported signs of what they called an “agent swarm” attack, which would fit automated, AI-assisted intrusion running at scale [1]. None of these vendors has published technical evidence for the agentic claim, so it should be treated as an operator’s assessment, not an established fact. Even so, the pace of disclosures, about one platform every three days through October, fits a campaign that is organized and possibly automated, although disclosure timing also reflects when each victim detected and announced its incident.

Zeabur as a Case Study in Platform Fragility

Zeabur’s preliminary incident report is the most detailed public account from any affected platform, and the contributing factors it lists are forms of common platform-engineering debt [2]. The attacker used a shared-cluster admin token created in January 2024 with no expiry, together with AWS keys stored in plaintext in a private configuration repository. The cluster admin interface was reachable from the public internet. Root passwords for dedicated GCP servers sat in plaintext in server initialization settings. Zeabur also acknowledged that its claim after an August 2026 incident, that all internal admin keys had been disabled or rotated, was incomplete [2].

With that access, the attacker read the settings and secrets of every service on the shared cluster, ran commands inside 865 customer database containers, signed in as root on 101 dedicated servers, and added a node to the internal network to reach the platform database [2]. The 865 databases included 736 n8n instances and 10 new-api/one-api deployments. Both are popular tools for storing third-party and AI provider credentials, and Zeabur says the attacker read credentials from them at scale. Zeabur reports that the attacker “was mainly looking for API keys they could use directly” [2]. More than 16 hours of activity raised no alerts, and the investigation began only after a user reported a problem [2]. About three days after the intrusion, Zeabur announced it would shut down, with all services ending by December 31, 2026, citing this and the August incident alongside growth limits and architectural complexity [3]. Wiz characterizes the shutdown as a result of the incident [1]. Whatever the precise weighting of those factors, the timing illustrates the business risk a secret-store breach can pose to a platform.

The LLMjacking Pipeline in Detail

Wiz’s investigation of two stolen enterprise Amazon Bedrock credentials offers the clearest public view yet of how stolen AI keys are turned into money [1]. In both cases, the key was first tested within 30 minutes of the reported vendor credential access, using a single InvokeModel call from a residential IP address. Each key then received a steady 14 to 120 calls per day from a small Go client, which Wiz reads as a single ongoing verification job. Bulk abuse came days later. In Case A, a rotating proxy pool first probed one call per model across many model families. A boto3 script then enumerated Bedrock and EC2 service quotas, and bulk traffic started 22 seconds later [1]. The table below compares the two cases.

Source: Wiz Research [1].

Several details in these cases indicate a mature operation rather than one-off fraud. Both cases used the same quota-enumeration script, “down to the version string,” which points to shared tooling [1]. Most calls had few uncached input tokens and a few hundred output tokens, which suggests the abusers were using prompt caching to save money. A long tail of calls with tens of thousands of uncached input tokens fits many separate end users behind a reseller front end [1]. In Case B, the key turned up in a reseller pool, producing thousands of failed calls from rotating hosting IPs, each active for about 15 minutes, before a checker found which model IDs worked [1].

Wiz linked the key-checking activity to two reseller operations. One, which Wiz calls “momo,” is associated with llm-routing.com. The other, “Xingjiabi,” operates xingjiabiapi.org. Both advertise discounted frontier-model access. Wiz notes that llm-routing.com accepts the USDT stablecoin [1], and Helix reports that such resellers are often paid in USDT [9]. Zeabur separately named one of the IP addresses Wiz associates with momo in its own investigation [1][2]. The archived Xingjiabi site included a “distillation behaviour detection” page that sorted customers into risk tiers, which Wiz suggests may be the reseller’s attempt to avoid triggering provider account suspensions [1]. Wiz is careful to say it has no evidence linking these resellers directly to the Black October intrusions [1]. CSA’s reading is that a resale market for stolen AI access exists and absorbs stolen keys quickly, whoever performs the initial theft.

The Distillation Question

OpenCode, Railway, and Command Code each linked their incidents to attempts to obtain AI access for model distillation, or more generally to target AI inference providers [1][5][6]. If that is accurate, part of the demand behind the wave comes from parties trying to build training data out of frontier-model outputs. That would make the stolen-key economy an issue for model-protection policy and possibly national security, not only for fraud and billing. CSA’s October 27 research note examined this possibility and recorded that some observers have questioned whether the available evidence establishes the distillation characterization, including for the OpenCode incident [10]. The token profiles Wiz observed fit high-volume general use behind resellers at least as well as they fit a focused distillation effort [1]. Defenders should not need to settle the motive question to act, because the controls that limit fraud also limit distillation, and both kinds of buyer pay for the same stolen keys.

Why Platform-Side Remediation Falls Short

The customer experience across these incidents shows a structural gap. When a platform is breached, it can rotate its own credentials, but it cannot revoke a customer’s OpenAI, Anthropic, Google, or AWS key; only the issuing provider can do that. OpenCode’s guidance told users to revoke keys at each provider, because deleting them from OpenCode would not invalidate copies already taken [10]. OpenCode said it was working with Google, OpenAI, and Anthropic, and Google suspended affected projects [5]; Helix reports that OpenAI refunded OpenCode victims [9]. Northflank customers reported unauthorized use of their AI keys [4], in multiple cases within hours of the breach alert [9]. A platform’s spend controls also cannot cap usage that happens directly against the provider, and Zeabur pointed out that changing an environment variable on its platform does not change a password already set inside a customer’s database [2]. As a result, the customer, the platform, and the AI provider each hold part of the response, and that coordination delay gives an attacker time to use stolen keys.

Recommendations

Immediate Actions

Organizations that store any secrets on the affected platforms should revoke and replace those secrets now, even if they see no sign of misuse, starting with AI provider and cloud credentials. Revocation must happen at the issuing provider, and old keys should be confirmed as invalid, not just replaced in configuration [4][5]. Teams should review AI provider usage and billing logs, and cloud audit logs, starting from the earliest possible exposure date. CSA’s earlier guidance suggests beginning the review at October 1, 2026 [11], and Zeabur advises September 1 for its dedicated-server customers [2].

Security operations teams should also search Bedrock and other inference logs for the behaviors Wiz describes. These include single validation calls from residential or hosting IPs, model-catalog probing across vendors, boto3 quota enumeration, unexpected use of global.* inference profiles, and calls from the IP addresses and autonomous systems Wiz has published [1]. Beyond AI keys, database passwords, n8n encryption keys, and GitHub App installations connected to affected platforms need to be rotated or reviewed, as Zeabur and Railway advise [2][7].

Short-Term Mitigations

Over the next one to three months, organizations should cut the number of long-lived AI keys held by third parties and limit what each remaining key can do. Key policy shaped how the abuse unfolded in Wiz’s data. A key restricted to specific inference profiles and regions was throttled by regional quotas, while an unrestricted key with global routing ran at about 90% success; the restriction slowed the abuse but did not prevent it, since the restricted key still served more than a million successful calls [1][9]. Teams should therefore issue a separate key for each service, environment, and integration. Each key should be scoped to the models the application actually uses and given hard spending and rate limits, not alert-only budgets [10][11]. Where providers support workload identity federation or short-lived tokens, these should replace static keys in pipelines and hosted workloads.

Detection should include provider-side telemetry. First calls from unfamiliar networks, calls to models the application has never used, and sudden quota enumeration are all useful alert conditions, given the behaviors Wiz documented. These alerts should reach on-call staff with authority to revoke the same day, without waiting for change approval [11].

Platform operators, whose decisions shaped the size of each incident, have their own short-term priorities, and Zeabur’s list of contributing factors offers a practical checklist for PaaS and AI hosting providers [2]. Operators should remove non-expiring administrative tokens and keep all plaintext secrets out of repositories, initialization scripts, and backups. Administrative interfaces should not be reachable from the internet. Internal and customer workloads should run in separate clusters. Alerts should fire on bulk reads of the secret store and on any access to the decryption path.

Strategic Considerations

CSA assesses that the lasting lesson of Black October is about architecture. A secret stored on a platform shares that platform’s security outcome, so the decision about where AI credentials live deserves the same care as any other trust decision. Organizations should treat AI keys as non-human identities, each with an owner, a purpose, a scope, an expiry date, and monitoring [17]. Vendor risk assessments for AI and PaaS providers should cover how secrets are stored and decrypted, how build systems are separated between tenants, what audit logs are available, and how quickly the provider notifies customers [10][11]. Self-operated AI gateways, bring-your-own-cloud deployment models, and runtime secret managers can each narrow the exposure, but they move the trust boundary rather than remove it.

Industry coordination matters as much as any single control. AI providers can shorten the window between theft and abuse by scanning for credentials exposed in breaches, revoking keys proactively when a platform announces a bulk exposure, and offering finer-grained key scoping and hard spending caps by default. CSA also encourages providers, platforms, and researchers to share indicators of reseller infrastructure. In Wiz’s two Bedrock cases, bulk abuse followed validation by four to seven days [1]. Where similar delays occur, that gap gives defenders their best chance to act, provided the provider learns about the exposure in time. Other victims saw abuse within hours, however, so revocation should not wait [9].

CSA Resource Alignment

This note is one of several CSA research notes on this wave of platform breaches, and it builds directly on earlier work. CSA’s Inference Providers as the Prize: Platform-Chain Campaigns Against AI Serving (October 23, 2026) examined the campaign against inference providers as it was unfolding [16]. Harvesting Keys for Distillation: Attacks on AI Credential Platforms (October 27, 2026) described the shift from collecting keys from individual developers to attacking platforms that hold many customers’ keys, using the Fireworks AI and OpenCode incidents [10]. This note extends that analysis across the full set of October incidents and adds Zeabur’s root-cause evidence. Black October Reaches PaaS: Northflank, Secret Stores, and AI Key Resale (November 2, 2026) analyzed why encryption at rest does not protect platform secret stores and first summarized Wiz’s Bedrock case studies [11]. The detection and key-policy guidance here is consistent with that note and adds the cross-incident pattern and the platform-operator perspective.

CSA’s Cloud Billing Hijacking as LLMjacking (October 21, 2026) covers a related LLMjacking technique in which attackers take over victims’ billing accounts instead of stealing their keys [12]. Together, the two notes show that LLMjacking actors now pursue both secrets and billing authority, so defenders should cover both credential stores and billing IAM. CSA’s earlier LLMjacking Evolved: Stolen Compute as Offensive AI Infrastructure traces how stolen inference access is repurposed for offensive operations as well as fraud. That background helps explain why the resale market Wiz documented could serve uses beyond cost theft [13]. Poisoned AI IDE Plugins: Developer API Key Theft documents the earlier developer-tooling phase of AI key theft [15], and CSA’s Defining Non-Human Identity provides the identity framing recommended above for AI keys [17].

Within CSA’s control frameworks, the AI Controls Matrix (AICM) v1.1 provides the control vocabulary for the recommendations above [14]. Its Identity and Access Management domain covers credential lifecycle, least privilege, and non-human identity governance, which address the long-lived, over-scoped keys behind both the platform intrusions and the Bedrock abuse. Its Cryptography, Encryption and Key Management domain applies to the decryption-path exposure seen at Railway and Northflank. Its Supply Chain Management, Transparency and Accountability domain gives organizations a basis for assessing the secrets architecture of AI and PaaS vendors. Its Logging and Monitoring domain supports the provider-side telemetry needed to spot the validation, probing, and quota-enumeration behaviors Wiz documented.

References

[1] Wiz Research (B. Read and R. McCarthy). “Black October for AI Developer Platforms.” Wiz Blog, October 30, 2026 (updated November 2026).

[2] Zeabur (Y. Lin). “October 2026 Security Incident.” Zeabur Blog, October 19, 2026.

[3] Zeabur. “Zeabur Is Shutting Down.” Zeabur Blog, October 17, 2026.

[4] L. Abrams. “Northflank security breach leads to abuse of customers’ AI API keys.” BleepingComputer, October 31, 2026.

[5] B. Toulas. “OpenCode hack exposes API keys amid AI distillation attacks.” BleepingComputer, October 19, 2026.

[6] J. Cooper. “Security Disclosure: Wednesday, October 21st.” Railway Blog, October 21, 2026.

[7] Railway. “October 21 Security Incident.” Railway Changelog, October 23, 2026.

[8] A. Brucato, Sysdig Threat Research Team. “LLMjacking: Stolen Cloud Credentials Used in New AI Attack.” Sysdig Blog, May 6, 2024.

[9] Helix. “Black October: Nine AI Platforms Breached in One Month.” Helix Blog, October 31, 2026.

[10] Cloud Security Alliance AI Safety Initiative. “Harvesting Keys for Distillation: Attacks on AI Credential Platforms.” CSA Lab Space, October 27, 2026.

[11] Cloud Security Alliance AI Safety Initiative. “Black October Reaches PaaS: Northflank, Secret Stores, and AI Key Resale.” CSA Lab Space, November 2, 2026.

[12] Cloud Security Alliance AI Safety Initiative. “Cloud Billing Hijacking as LLMjacking: Security Implications and Guidance.” CSA Lab Space, October 21, 2026.

[13] Cloud Security Alliance AI Safety Initiative. “LLMjacking Evolved: Stolen Compute as Offensive AI Infrastructure.” CSA Lab Space, June 26, 2026.

[14] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, June 22, 2026.

[15] Cloud Security Alliance AI Safety Initiative. “Poisoned AI IDE Plugins: Developer API Key Theft.” CSA Lab Space, June 18, 2026.

[16] Cloud Security Alliance AI Safety Initiative. “Inference Providers as the Prize: Platform-Chain Campaigns Against AI Serving.” CSA Lab Space, October 23, 2026.

[17] Cloud Security Alliance Identity and Access Management Working Group. “Defining Non-Human Identity.” Cloud Security Alliance, June 10, 2026.