Pricing Contact Case Studies Research Talk to a Pentester ↗
POCFORGE RESEARCH 9 MIN READ Threat intel

Black October: AI Developer Platforms Breached for Customer AI Keys. What to Rotate and How to Test

Attackers went after the platforms that hold your AI keys. What to rotate now, and the six paths to test if you run a platform that stores customer secrets.

In October 2026 at least nine AI developer platforms disclosed breaches, and in almost every case the attacker went after the same thing: the environment variables where customers keep their AI provider keys. If a third-party platform holds your secrets, its security is now part of yours. Here is what happened, what to rotate, and how to test a platform that stores customer credentials.

The short version

  • What: between 6 and 30 October, Wiz counted at least nine AI developer platforms that disclosed security incidents: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank. Other platforms, including India’s Rocket.new and Comet’s hosted Opik service, disclosed key exposures in the same weeks.
  • The target: stored customer secrets, especially API keys for AI model providers. Stolen keys are used to run inference billed to the key’s owner, resold, or used to harvest model output at scale (“distillation”).
  • Root causes vary: build-infrastructure privilege escalation, stolen internal credentials, a legacy system, a third-party vendor. No investigator has tied the incidents to one actor or one vulnerability.
  • Do now: if you used any affected platform, revoke keys at the issuing provider (not just in the platform’s UI), rotate every secret that lived alongside them, and check provider billing and usage logs from early October onwards.
  • Then: treat every platform that holds your secrets as part of your attack surface, and if you run such a platform, test the paths that lead to customer secrets, not just the login page.

What happened in October

Wiz published its round-up, titled “Black October for AI Developer Platforms”, on 30 October 2026. It lists nine platforms with incidents during the month and notes one common thread across the public reports: targeted exploitation “explicitly hunting stored environment variables, with a focus on those granting AI access”. Wiz is careful to say there is no single vulnerability or dependency linking the attacks, and most investigations were still open when it wrote.

The disclosures that have the most detail so far show how varied the routes in were:

  • Railway published a preliminary report and timeline. It says the attack began with a privilege escalation in its build infrastructure on 20 October. The attacker first pulled secrets in encrypted form but could not decrypt them, then obtained credentials for Railway’s CI environment, decrypted artefacts that held further API access, and ran an unauthorised query of encrypted environment variables, a subset of which were decrypted. Railway says payload logs showed the specific API key names the attacker was searching for, and that the motive appeared to be AI provider keys for distillation. Railway puts the exposure at no more than about 1.85% of workspaces.
  • Northflank disclosed an incident on 30 October after a threat alert from Wiz. It told customers to “assume all environment variables have been decrypted” and to disable or rotate every key, and later confirmed that users had reported unauthorised use of AI API keys supplied to the platform. Northflank has not said how the attacker got in.
  • OpenCode attributed its incident to a legacy system that exposed provider keys saved in its hosted console. Reporting puts the affected group at about 1.4% of console users; keys held locally in its command-line and desktop apps were out of scope.
  • Warp suggested the root cause was a third-party vendor dependency; the exposure involved AI agent logs and telemetry rather than keys.
  • Fireworks AI, Zeabur and Lightning AI attribute their root causes to credential access. Wiz reports that Zeabur will shut down as a result of its incident.

Two further incidents in the same window show the pattern reaching beyond Wiz’s list. Rocket.new, a Surat-based AI app-building platform, told users that an attacker reached part of its production systems on 27 October and obtained the encrypted API keys of about 0.2% of users, and asked every user to revoke and replace connected third-party keys. And Comet disclosed that between 24 and 26 October an attacker used an API key from an inactive account to reach some of Comet’s own internal test workspaces on its hosted Opik service, then abused a flaw in Opik’s AI provider settings to obtain 29 of Comet’s internal OpenAI and Anthropic keys. Comet says no customer data or customer keys were accessed.

Why AI keys, and why platforms

An AI provider key is unusually easy to turn into money. Whoever holds it can run expensive model calls billed to someone else, sell access through a reseller, or harvest output at scale. Because the traffic comes from a real, paying customer’s account, it can look legitimate to the provider until the bill arrives. Wiz describes the wider practice as “LLMjacking”. In two enterprise cases it traced, compromised credentials were used for roughly 2.5 million Amazon Bedrock calls, likely more than $100,000 of usage at list price.

Platforms are an efficient place to steal those keys. A hosting, build or AI-tooling platform holds secrets for thousands of tenants in one place: environment variables, build artefacts, connector settings. Breaching the platform once can yield keys for many customers, and nothing the customer installed has to change. The Cloud Security Alliance has described this as a “platform-chain” pattern, in which an attacker reaches an inference account by going through one or more platforms that hold its credentials.

India-specific guidance points the same way. CERT-In advisory CIAD-2026-0049 (15 October 2026), on AI agents as attack vectors, says the weaknesses exploited in recent AI-driven incidents were conventional ones: credentials and keys exposed in code, repository history, configuration files and client apps; dormant and test APIs left reachable; payment API keys stored in plaintext and readable from application runtimes; and over-permissive cloud and backend-as-a-service roles. CERT-In also issued CIAD-2026-0053 on 23 October about a compromised LiteLLM PyPI release and Docker images that enabled credential theft, another route to the same secrets.

What to do if you used an affected platform

  1. Revoke at the issuer. Deleting a key from the platform’s dashboard does not stop a copy the attacker already has. Revoke and reissue the key at the AI provider, Git host, registry, payment gateway or cloud account that issued it.
  2. Rotate the neighbours. Treat every secret that sat in the same environment, project or secret group as exposed: database passwords, cloud credentials, registry tokens, webhook signing secrets, payment keys. Railway and Northflank both told customers to roll all environment variables, not just AI keys.
  3. Check the bills and the logs. Review AI provider usage and billing from early October, looking for unfamiliar projects, models you do not use, traffic at odd hours or from unexpected networks. Review the logs of any other service whose credentials were stored on the platform.
  4. Expect noise after rotation. Railway later explained that a batch of keys sent to providers for precautionary revocation included some replacement keys created after the incident. If a new key stops working, check the provider’s notice before assuming a fresh compromise.
  5. Limit the blast radius next time. Use one key per tool or environment, set spend limits and alerts at the provider, give each key the narrowest scope the provider allows, and keep production payment and database credentials out of general-purpose build platforms where you can.

If you run a platform that stores customer secrets

The October incidents are a useful checklist for any SaaS, PaaS or AI product that accepts customer credentials, including the many Indian start-ups building AI apps, agents and integrations on top of third-party models. A standard web application test that stops at authentication and access control will miss most of these paths. When PoCForge scopes this kind of assessment, these are the questions we test against.

1. Can a tenant change where a stored secret is sent?

The Comet incident is the clearest public example. Comet’s fix was to require the API key to be re-entered when a provider address changes, and to restrict which addresses provider requests can reach. The underlying test is simple to describe: if a user can edit the endpoint, base URL or webhook address attached to a saved credential without re-supplying the credential, they may be able to point the platform at a server they control and receive the secret in a request header. The same check applies to custom model endpoints, proxy settings, “bring your own” connector URLs and outbound webhooks. Testers should also confirm that outbound requests cannot reach internal addresses or cloud metadata services.

2. Can low-privilege or stale accounts reach secret-bearing features?

Comet’s attacker started with a key from an inactive account that had no admin rights. Test with the lowest roles, invited-but-unused members, and API keys belonging to accounts that should have been offboarded. Check whether secret values, or settings that act on them, are readable or editable through the API even when the interface hides them.

3. What can the build pipeline see?

Railway’s path ran through build infrastructure and then CI credentials. Review whether build jobs run with credentials that can read other tenants’ data or the secret store, whether one tenant’s build can affect shared builders, and whether CI artefacts or caches contain decryption material or long-lived tokens.

4. Where does decryption actually happen?

Several disclosures stress that secrets were encrypted. That only helps if the decryption keys and the services that use them are harder to reach than the ciphertext. Map which roles, services and staff tools can decrypt customer secrets, and test whether a compromise of one internal credential is enough to do so. Rocket.new’s notice, as reported, did not say whether decryption material was reached, which is exactly the question customers will ask.

5. Would you notice, and could you tell customers what was taken?

Railway noted that because keys were envelope-encrypted, a database query log alone could not show which specific keys were affected. Check that secret reads and decryptions are logged per tenant and per key, that unusual bulk reads raise an alert, and that you can produce a per-customer list of exposed secrets quickly. Northflank turned on audit logs for all customers, including free accounts, as part of its response.

6. Is the supply chain in scope?

Warp pointed to a third-party vendor dependency, and the LiteLLM release covered by CIAD-2026-0053 shows how an AI proxy library can become a credential-theft tool. Include dependency pinning, package provenance and the permissions of AI gateway components in the review.

Methodology notes and limits

This article is based on public disclosures and reporting available on 2 November 2026. Most of the investigations are still open, several vendors have not published root causes, and figures such as affected-user percentages come from the companies’ own notices. We have not had access to any affected platform’s systems, and we do not attribute the incidents to any actor. Testing of the kind described above should only be carried out on platforms you own or are explicitly authorised to assess, under an agreed scope.

Key takeaways

  • October’s breaches targeted platforms because they hold many customers’ AI keys in one place.
  • If you used an affected platform, revoke at the issuing provider, rotate everything stored alongside, and review billing from early October.
  • Use one key per tool, with spend limits and the narrowest scope available.
  • If you build a platform that stores customer secrets, test endpoint changes on saved credentials, stale and low-privilege accounts, build and CI access, decryption paths and per-key logging.
  • CERT-In’s own guidance says the weaknesses being exploited are conventional. That makes them testable.

If you would like a scoped review of how your product stores and uses customer secrets, or of your exposure to third-party platforms, talk to PoCForge.

Sources