FR
live

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.

A wall-mounted metal key cabinet with rows of labeled hooks, one hook empty with its slot catching a single amber glint, the rest of the cabinet in anthracite grey.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

MALFEX hides a shellcode loader inside an npm native addon that is still live

On October 17, 2026, SafeDep, Checkmarx and CloudSEK document the MALFEX campaign, which has been publishing npm packages since August 2023 whose nine-line JavaScript files load a DLL that injects shellcode into a Windows process. If your Windows machines install npm dependencies with native addons, audit your dependency trees and treat affected hosts as compromised.

Attackers exploit a root command-injection flaw in the SiteGuard WAF

On 18 October 2026, JPCERT/CC and vendor e-guardian confirmed that CVE-2026-106931, an OS command injection in the statistics feature of SiteGuard Server Edition, is being exploited in the wild. Preserve diagnostic evidence before patching: remediation can erase the attacker’s traces.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss