An OpenCode Console breach exposes OpenAI, Anthropic, and Google API keys for 1.4% of users
On the night of 16–17 October 2026, an intruder reached a legacy OpenCode Console system that was being decommissioned, exposing the OpenAI, Anthropic, and Google API keys of 1.4% of the service’s users. Revoke and reissue those keys at each provider, then audit your billing since 16 October.
16 October 2026, overnight. An intruder reaches a legacy system in OpenCode Console, which was already being decommissioned. 17 October 2026, in the morning. Anomaly Innovations emails the affected accounts: 1.4% of Console users, whose OpenAI, Anthropic, and Google API keys may have been exposed. Why it matters: the vendor ties the intrusion to a “large-scale distillation attack” — and a stolen provider key is not a password, it is a billing account left open for a third party’s free inference.
A breach in a system they were retiring
OpenCode is an open-source coding agent that runs in the terminal, as a desktop app, and inside IDEs. It is model-agnostic: developers plug in their own Anthropic, OpenAI, or Google keys and switch between them. Console is the optional hosted layer — a workspace shares models, sets budgets, and connects the team’s providers.
That layer is what was hit. In its statement on X on 17 October 2026, the vendor said a third party had accessed a legacy system the team was “in the process of retiring.” The provider keys stored in affected workspaces — including OpenAI and Anthropic keys — may have been exposed. Users who did not receive an email are not affected, the company said, and the 1.4% figure refers to Console users, not the entire OpenCode base.
What is missing is exactly what matters: OpenCode has not said how the intruder got in, how long they stayed, how the keys were stored, or whether they were actually used. The statement draws a declared link to a distillation operation, not a complete technical account. The safe posture is to treat any potentially exposed key as compromised, not “possibly compromised.”
Provider keys, not passwords
The asset is not a login session; it is a provider API key. The distinction changes the response. A password is reset in the affected tool; an API key is revoked at the provider — because anyone who copied it can keep using it directly, even after it is deleted from OpenCode.
A stolen key has three consequences:
- Billing. An attacker can run workloads on the owner’s account and drive up the bill. Several users report charges they never made.
- Access. Depending on scope, a key can also reach uploaded files, stored prompts, and fine-tuned models attached to the account.
- Distillation. Model outputs harvested at scale train another model, without authorization.
A stolen AI key also behaves differently from a stolen password in one practical way: it is rarely unique to one tool. The same OpenAI or Anthropic key a developer pasted into Console is often also hard-coded into a CI job, an internal app, or a second coding agent. That reuse is why rotation is painful and why attackers move fast — one leaked key opens several doors at once, and none of them appears in a login audit log. The blast radius is measured in billing, data access, and model output, not in session hijacking. It is also why the standard playbook — force a password reset, rotate the session token — does not apply: the credential lives with a third party, and only that third party can revoke it.
That third point explains the vendor’s wording. In September 2026, Anthropic described campaigns by China-based labs that pulled roughly 190 million exchanges from Claude, partly through illegally harvested API keys. A leaked key feeds that market directly, where it is consumed fast and at scale. Nobody has publicly attributed the OpenCode attack yet.
What to do now
The remediation sequence, for any Console user — whether or not they got the email:
- Revoke at the provider. Go to each provider’s dashboard (OpenAI, Anthropic, Google, OpenRouter, and others) and revoke the keys there. Do not use links from an email: notices like this are classic phishing bait.
- Reissue and redeploy. Create new keys and update every app, CI pipeline, or agent that used them. Confirm the old key is dead before moving on.
- Audit billing. Review usage and billing from 16 October onward: consumption spikes, unfamiliar models, activity at odd hours. Set spend limits and alerts on every provider account.
- Tighten scope. Scope keys per project or per user so the next leak stays small. Reset the OpenCode password and regenerate any Console keys while you are at it.
Cyera, which published the most operational analysis of the incident, stresses one point: deleting a key from OpenCode does not stop someone who already copied it. You have to act at the source, at the provider. A Console budget only covers spend that flows through OpenCode; it does not block direct use of a stolen key against the provider.
A structural problem, not an isolated incident
The OpenCode breach merely exposes a wider gap: in two years, AI coding agents have become decentralized key vaults. Cursor, Copilot, Claude Code, Codex, and their rivals all store provider keys somewhere — a local file, a secrets manager, or a hosted layer like Console. Every extra hosted layer adds attack surface: a forgotten legacy system, a misconfigured bucket, or a poorly scoped service account is enough.
The worrying precedent is not theoretical. In 2026, a leak tied to the DeepSeek ecosystem already exposed API keys and passwords found in public web data — proof that poorly stored secrets eventually circulate. The contrast with a classic npm campaign like MALFEX is instructive: there, the attacker published malicious packages to distribute code; here, all it takes is to harvest credentials a third party already stored. The yield is higher, and the detection risk lower.
For a CISO, the consequence is direct: the inventory of inference keys must join the inventory of service credentials. It is no longer enough to monitor passwords and cloud tokens; the OpenAI, Anthropic, Google, and OpenRouter keys your developers scatter across tools are full financial and access assets. A key that burns $10,000 of inference overnight is no less serious than a compromised SSH login.
Verdict
If your developers use OpenCode, ask them whether they received an email, then revoke and reissue the affected provider keys at each provider — not just inside Console. If your teams use personal keys without governance, treat this incident as the signal it is: every AI coding tool your developers connect holds credentials and can reach data. Give it the same ownership, rotation, and least-privilege rules as a service account. The lesson of OpenCode is not that a startup got breached; it is that the attack surface of inference keys is already being exploited at industrial scale.
References
- OpenCode — official statement (X, 17 October 2026)
- Cyber Security News — OpenCode Security Breach Exposes Third-Party API Keys (18 October 2026)
- Cyera — OpenCode Breach: What Happened and How to Rotate Exposed AI API Keys (17 October 2026)
- The Hacker News — OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys (19 October 2026)