October 17, 2026: OpenCode disclosed a breach of its hosted Console product, saying unauthorized access to "a legacy system that we were in the process of decommissioning" exposed external AI-provider API keys for about 1.4% of Console users — specifically, users who had linked outside accounts such as OpenAI or Anthropic. OpenCode also described the incident, without further technical explanation, as a "large scale distillation attack." No top-tier security outlet had covered the incident at the time of this writing; what follows draws on OpenCode's own disclosure plus secondary tech-press pickup, with uncertain details clearly flagged. Canonical record: opencode-console-breach2026. Primary source: OpenCode's own statement on X.
OpenCode is an open-source AI coding agent — the kind of terminal-based assistant developers point at a codebase to write, review, or refactor code, similar in spirit to Claude Code or Cursor's agent mode. It's maintained by Anomaly Innovations, the team behind the SST serverless framework, and has built a sizable following among developers who want an agent they can run locally, inspect, and extend rather than a closed hosted product. Most of that tool runs on your own machine and talks directly to whichever AI provider you configure with your own key. Console is the separate, hosted layer on top: an account system where users can link OpenAI, Anthropic, or Google credentials once so OpenCode can call those providers on their behalf without juggling raw keys in a local config file every time. That hosted layer is what got breached — not, as far as current disclosures show, the open-source CLI itself or the codebases anyone was running it against.
That distinction is the first thing to get right when a tool like this shows up in a breach headline. "OpenCode was hacked" invites an assumption that every install, every local session, every repository someone pointed the agent at is now suspect. Nothing in OpenCode's disclosure supports that reading. The exposure is scoped to a specific hosted feature — stored third-party credentials — used by a specific subset of a specific product tier.
What happened
OpenCode's account posted the disclosure on the morning of October 17, 2026, saying the breach occurred "last night" and that affected users had already been emailed. The company's language was notably compact for a security incident of this kind: a reference to a legacy, soon-to-be-decommissioned system; a claim that only Console users who had linked an external provider were in scope; and the unexplained "distillation attack" label. Secondary coverage — a dev.to write-up, officechai, Startup Fortune, and a short mention on Notebookcheck — repeated OpenCode's own framing rather than adding independent forensic detail.
Multiple users reported on social media that they saw unauthorized spend on their own OpenAI and Anthropic accounts after the breach, with figures cited in the low hundreds of dollars per account in some posts. Those numbers are individual, user-reported claims, not a company-confirmed total, and BreachHistory is not treating them as verified. OpenCode said it was working with the affected providers on remediation; one secondary report claims Anthropic revoked the exposed keys on its end, which would be a normal containment step for a provider notified of leaked credentials.
Verified vs. unverified
As with most breach disclosures made via a short social media post rather than a formal incident report, it's worth separating what OpenCode itself said from what is circulating around it:
- Confirmed (by OpenCode): unauthorized access to a legacy backend system; exposure of external provider API keys stored by Console accounts; roughly 1.4% of Console users affected; affected users notified by email.
- Unverified / unexplained: what "large scale distillation attack" actually describes technically; whether Google credentials were exposed alongside OpenAI and Anthropic (most but not all secondary reports include Google); the exact dollar amount of fraudulent usage; whether any data beyond API keys — prompts, source code snippets, account metadata — left the legacy system.
No CVE has been assigned to this breach, and as of this writing OpenCode has not published a formal post-mortem of the kind security teams typically expect after a credential-exposure incident — a timeline, root-cause analysis, and list of remediation steps beyond "we're working with providers." That gap matters less for assigning blame and more for anyone trying to size their own risk: without a scope confirmation beyond "1.4% of Console users," an individual has no way to check whether they personally were in the affected set other than watching for OpenCode's own notification email.
Not OpenCode's first security headache — but a different kind
It's worth being precise about what this breach is not, because OpenCode (maintained by Anomaly Innovations, the team behind the SST serverless framework) has had three unrelated, already-patched vulnerabilities disclosed against the open-source tool itself over the past year:
- GHSA-vxw4-wv6m-9hhh / CVE-2026-22812 (patched in 1.0.216) — OpenCode ran an unauthenticated local HTTP server that, under the right conditions, let any local process or a malicious website execute arbitrary shell commands as the user.
- GHSA-c83v-7274-4vgp / CVE-2026-22813 (patched in 1.1.10) — a malicious website could abuse a URL-override feature in OpenCode's local web UI to chain cross-site scripting into remote code execution.
- GHSA-632h-h47v-g4x4 (patched in 1.18.22, no CVE assigned) — a cross-site request could trick an npm-based OpenCode install into fetching and installing arbitrary packages during a self-upgrade check.
Those three are vulnerabilities in the tool, reported by independent researchers, fixed, and with no evidence of exploitation in the wild. The Console breach is a different category entirely: unauthorized access to OpenCode's own backend infrastructure, not a flaw a user's local install exposed. Conflating the two would overstate what's known about the October 17 incident and understate how routine (if still serious) the earlier RCE reports were as the kind of thing security researchers responsibly disclose against any locally-running dev tool with a web UI.
Why AI coding agents keep ending up in this column
OpenCode's breach lands in the middle of a pattern BreachHistory has tracked across the current wave of AI developer tooling: the agent itself may be fine, but the credentials and infrastructure wrapped around it are a growing target. Our guide to securing AI agents flags exactly this class of risk — any tool that stores or proxies a provider API key on your behalf inherits that key's blast radius the moment its own backend is compromised. Our MCP server security breakdown covers the adjacent trust-boundary problem for agents that call out to external tools rather than external model providers, and our broader look at what's actually changed in the AI era argues this is now a mainstream threat model, not an edge case.
It's also not the only AI-adjacent company in the catalog this year dealing with infrastructure compromise rather than a classic data dump. Hugging Face disclosed an intrusion where AI agents were used to attack an AI platform, and the Shai-Hulud npm worm that hit keyv and 400+ other packages in August specifically targeted credentials reachable through popular AI dev tools — OpenCode has been named in some vulnerability-tracking writeups as among the tools in that worm's target list, though BreachHistory has not independently confirmed any direct link between Shai-Hulud and the October 17 Console breach, and treats that connection as unestablished pending clearer reporting. The mechanism rhymes with Brevo's September API-key compromise, where a stolen Cloudflare credential — not a flaw in Brevo's product — became the entry point. In both cases, the lesson for defenders is the same: a long-lived credential sitting in the wrong system is a breach waiting on a decommissioning schedule.
Who is at risk
OpenCode Console users who linked an external AI provider account. If you connected OpenAI, Anthropic, or Google credentials to a Console workspace, you fall inside the population OpenCode says it notified. If you received that email, treat the keys as burned regardless of whether you've noticed unusual activity yet.
OpenCode Console users who did not link an external provider. OpenCode's own scoping statement excludes you from the described exposure. That doesn't mean ignore your account entirely — review login history and connected integrations as routine hygiene whenever any product you use discloses a breach, even a narrowly scoped one.
Users of the open-source OpenCode CLI who never touched Console. Nothing in OpenCode's disclosure or the secondary coverage describes this breach reaching the local tool, your codebase, or keys you configured directly with a provider outside of Console. The three GHSA advisories above are the relevant history for the CLI itself, and all three are patched.
Anyone whose API usage dashboards show unexplained spend. Independent of whether you can trace it to this specific breach, unexpected charges on an OpenAI or Anthropic account are reason enough to rotate the key immediately and review usage logs for the request patterns and timestamps involved.
What to do
- Rotate every provider key you ever linked to OpenCode Console — OpenAI, Anthropic, and Google alike, even if you're not certain which were exposed. Revoking and reissuing is cheap; leaving a possibly-compromised key live is not.
- Check your provider billing/usage dashboards for spend or request volume you don't recognize, going back at least to mid-October. OpenAI and Anthropic both expose per-key usage breakdowns for exactly this kind of review.
- Set hard spend limits on any provider account you use with third-party tools generally, not just OpenCode — a capped budget turns a stolen key into a bounded nuisance instead of an open-ended bill.
- Re-link Console carefully, if at all — consider whether you need the hosted Console layer versus configuring the open-source CLI directly with your own provider keys, which keeps one fewer party in possession of your credentials.
- Ignore unsolicited "key recovery" or "refund" messages referencing this breach. Every credential-exposure incident spawns copycat phishing; OpenCode's own email to affected users is the only notification you should trust, and even that should be read without clicking embedded links you can't verify independently.
- Keep the open-source CLI updated. The three unrelated GHSA advisories above are all patched in current releases — if you're running an OpenCode build from before January or September 2026, you're carrying fixed vulnerabilities forward for no reason.
Open questions
Several things remain unresolved as of this writing, and BreachHistory will revisit this record if OpenCode publishes more detail:
- What "large scale distillation attack" technically means in the context of a legacy-system compromise — the term is unusual enough, and unexplained enough, that readers should not assume it maps cleanly onto a familiar attack category.
- Whether Google-linked credentials were part of the exposure, which most but not all secondary sources assert.
- An absolute user count rather than a percentage, and any accounting of confirmed fraudulent provider spend rather than individual user-reported figures.
- Whether OpenCode will publish a formal post-mortem, which would be the normal next step for a company handling developer trust after a credential breach.
How this compares to other 2026 credential-exposure incidents
Strip away the "AI" framing and OpenCode's breach fits a pattern BreachHistory has catalogued repeatedly in 2026: a secret sitting in a system nobody was watching closely becomes the whole incident. Brevo's September breach traced back to a long-lived Cloudflare API key hardcoded in application source; Klue's OAuth-token compromise fed a downstream Salesforce data theft through a trusted-app integration nobody had re-audited. OpenCode's version of the same story is a "legacy system... in the process of decommissioning" — software engineering's version of a door that was already half-closed but not yet locked, holding exactly the kind of credential that matters most: keys to other companies' paid AI APIs, billed directly to the user who linked them.
The common failure mode across all of these is organizational, not purely technical: decommissioning schedules, key rotation policies, and audit coverage for "legacy" or "about to be retired" systems routinely lag behind the urgency applied to production systems still being actively developed. Attackers know this. A system flagged internally as low-priority because it's being shut down anyway is, from an attacker's perspective, often the least-monitored door in the building for exactly as long as it takes someone to get around to actually turning it off.
Regulatory and legal outlook
Unlike a consumer data breach involving names, addresses, or government IDs, a stored-API-key exposure doesn't map cleanly onto most existing breach-notification statutes, which were largely written with personal information in mind rather than business-to-business API credentials. That doesn't mean there's no exposure for OpenCode: depending on jurisdiction and the terms of service Console users agreed to, a credential breach that led to confirmed financial loss (unauthorized provider spend) could still trigger contractual notification obligations or, if enough affected users pursue it, small-claims or class-action activity over the unreimbursed charges some have reported. None of that has materialized publicly as of this writing, and it would depend heavily on whether OpenCode offers to cover verified fraudulent spend rather than leaving affected users to dispute charges with their AI provider directly.
Canonical record and sources
BreachHistory catalog row: /opencode/opencode-console-breach2026 — recordsAffected: 0 pending an absolute headcount (OpenCode has published a percentage, not a count); companyConfirmed: true for the breach itself, with the mechanism and full scope still unconfirmed in prose.
Sources used for this article: OpenCode's disclosure on X; dev.to write-up; officechai; Notebookcheck; GitHub security advisories GHSA-vxw4-wv6m-9hhh, GHSA-c83v-7274-4vgp, and GHSA-632h-h47v-g4x4 for the unrelated, already-patched CLI vulnerabilities referenced above.
BreachHistory will update the canonical record if OpenCode publishes a formal incident report, a confirmed user count, or an explanation of the "distillation attack" language — until then, treat the percentage-based scope as the most reliable number in circulation, and everything downstream of it as reported-but-unverified.