---
title: "OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them"
description: "OpenCode says a breach of a legacy Console system exposed provider keys for 1.4% of Console users. What is confirmed, who is affected, and how to rotate keys."
url: "https://anomity.ai/blog/opencode-console-breach-ai-provider-keys-rotation/"
source: html
---

OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them

Contents

- What happened
- Timeline
- Who is affected
- Confirmed, reported and unknown
- Why a stolen provider key is worth so much
- How to check and rotate exposed keys
- Hardening after the incident
- How Anomity helps
- Sources
- Frequently asked questions

0%

8 min read

Share

- X.com

- LinkedIn

- Email

- Copy URL

- Copy markdown

[← Back to blog](https://anomity.ai/blog/)

- Home

- Blog

- OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them

![Anomity robot illustrating OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them]

Advisory High

# OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them

Anomity Research
Anomity Threat Research
·
Oct 18, 2026
·
8 min read

Share: Copied

LLM Gateways & Proxies · High · OpenCode Console breach, disclosed October 17, 2026 (no CVE or GHSA) · Oct 18, 2026

Affected OpenCode Console workspaces that had external AI providers linked (bring-your-own-key). OpenCode puts the affected share at 1.4% of Console users and says it emailed all of them on October 17, 2026. Keys used only in the local OpenCode app are not stored by OpenCode, per the company.

On **October 17, 2026**, OpenCode disclosed that a breach the night before had exposed AI provider keys belonging to some users of **OpenCode Console**, its optional hosted service. Affected users were told that keys for providers such as OpenAI and Anthropic, saved in their Console workspace, may have been exposed. Several reported charges on those accounts before the disclosure was public.

This advisory is built from OpenCode's own statements on X and its Console documentation, posts from OpenCode's Dax Raad and Anthropic's Lydia Hallie, and reporting by Cyera, Cybersecurity News and CellCog, cross-checked against each other. Where a detail comes only from user reports, we say so. It is a separate incident from the local-server flaw covered in [our GHSA-632h-h47v-g4x4 advisory](https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/).

## What happened

OpenCode's public statement opens with the line below. It goes on to say that all affected users were emailed that morning, that anyone who did not get an email was not impacted, and that the affected group was "a subset of users who had external providers linked." It adds that the incident is ongoing, so it cannot share more details, and that it is working with Anthropic, OpenAI and Google to remediate.

> We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users OpenCode on X, October 17, 2026

The email to affected users, titled "Action Required: Potential provider key breach" and shared publicly by recipients, adds the cause. OpenCode says it identified **unauthorized access to a legacy system** it was in the process of decommissioning, and that third-party provider keys saved in the user's workspace **may have been exposed**. It asks recipients to revoke and replace those keys through each provider's dashboard, update applications that use them, and review recent usage.

The wording matters. The notice describes possible exposure, not confirmed theft of every key. User reports of overnight charges, and Anthropic's revocation of keys, show that at least some keys were used.

## Timeline

When (UTC) Event Source

Night of Oct 16 Breach of a legacy Console system, per OpenCode OpenCode statement and email

Morning of Oct 17 OpenCode emails affected Console users: "Action Required: Potential provider key breach" OpenCode; notice shared by recipients

Oct 17, 14:14 The notice is posted to the r/opencode community CellCog

Oct 17, 14:35 A developer reports OpenAI, Anthropic and Google spend alerts overnight; Google suspended his project for suspicious activity CellCog, quoting the developer on X

Oct 17, 17:56 OpenCode posts its public statement on X OpenCode on X (original post)

Oct 17, 18:08 Statement edited to its current text: 1.4% of Console users, working with Anthropic, OpenAI and Google OpenCode on X (edit history)

Oct 17, 21:04 Anthropic's Lydia Hallie says Anthropic has revoked Claude API keys it believes were affected Lydia Hallie on X

Oct 17, 21:38 Dax Raad clarifies that this is OpenCode Console, not OpenCode itself, and that local keys never come to the company Dax Raad on X

Oct 17-18 Cyera, CellCog and Cybersecurity News publish analyses; OpenCode says the incident is ongoing Cyera; CellCog; Cybersecurity News

## Who is affected

The exposure sits in one feature. OpenCode Console lets a workspace connect **provider accounts it already pays for**, Anthropic, OpenAI, Google, OpenRouter and many others, by pasting the provider's API key. Per OpenCode's documentation, Console **stores that credential** and serves the provider through its own gateway, so workspace members use the models without ever seeing the key. That design is convenient for teams and it is also why a breach of Console's systems reaches the raw provider keys.

- Affected: Console users who had external providers linked and received OpenCode's email. OpenCode names OpenAI and Anthropic keys in the notice and says it is working with Google too. Treat every provider key ever saved in a Console workspace, catalog or custom, as in scope.
- Not named: developers who use only the local OpenCode CLI or desktop app with their own keys. Per Dax Raad, those keys never reach OpenCode. OpenCode's docs place them on the machine in ~/.local/share/opencode/auth.json .
- Unknown: the absolute number of users or keys, how the keys were stored, how long the attacker had access, and whether OpenCode's own Console API keys were touched. OpenCode has not published a Console user total, so 1.4% cannot be turned into a headcount.

## Confirmed, reported and unknown

Claim Status

A legacy system being decommissioned was accessed Confirmed by OpenCode's notice

Provider keys saved in Console workspaces may have been exposed Confirmed by OpenCode's notice

1.4% of Console users affected; no email means not affected OpenCode's statement

Anthropic revoked Claude API keys it believes were affected Stated by Anthropic's Lydia Hallie

Keys were used for unauthorized charges Reported by individual users, with self-reported amounts from hundreds to more than a thousand dollars

Keys were used for model distillation OpenCode's description, with no technical detail

How the attacker got in, how keys were stored, number of keys Not published

## Why a stolen provider key is worth so much

A provider API key is a bearer credential with a billing account attached. Whoever holds it can run inference at the owner's expense, and depending on the provider and scope, may also reach files, stored responses or fine-tuned models tied to the account. This is the pattern we describe in [LLMjacking and stolen-key cost abuse](https://anomity.ai/blog/llmjacking-stolen-key-cost-abuse/): no exploit, just valid credentials and ordinary API traffic.

The distillation framing adds a motive. Model providers try to block unauthorized distillation by catching fraudulent accounts. A real customer's key carries a verified identity, an existing payment method and a normal usage history, so its traffic looks legitimate and the cost falls on someone else. That is a plausible reading of why OpenCode used the term and why the three providers are involved, but OpenCode has not confirmed it.

## How to check and rotate exposed keys

Work in this order. The goal is that every key that ever sat in a Console workspace is dead, and every system that used it has a replacement.

- Find the scope. Ask developers directly whether they received OpenCode's notice, rather than waiting for it to be forwarded to security. List the Console workspaces tied to corporate email addresses or corporate cards, and the providers linked to each. If you have no Console use at all, your exposure from this incident is likely nil.
- Revoke at the provider, not in Console. Open each provider's own console directly, not through a link in an email, since breach notices are popular phishing templates. Revoke the key on the provider's API keys page and create a new one: OpenAI, Anthropic, Google (AI Studio or the Cloud credentials page, depending on how the key was created), OpenRouter, and any catalog or custom provider you linked. You do not need Console access to do this.
- Move every consumer. A key linked in Console often also runs a CI job, an internal app or another coding agent. For keys named in OpenCode's notice, revoke first and fix what breaks. For keys you are rotating as a precaution, issue the replacement, move consumers to it, then revoke the old one.
- Read provider usage from October 16 onward. Look for unfamiliar models, regions, volumes or hours. Console's own usage reports only count traffic routed through Console, so direct use of a stolen key appears only on the provider's side. Report unexpected charges to each provider's support with dates and the key identifier, and keep OpenCode's notice as evidence.
- Set spend limits and alerts on every provider account and project. A cap does not stop theft, but it bounds the bill while rotation finishes. One user's Google project was suspended automatically for suspicious activity, which is the kind of brake worth having everywhere.
- Clean up Console. Remove providers a workspace no longer needs, replace the credential on the ones it does, rotate OpenCode Console API keys used by your own tools, and reset OpenCode account passwords as a precaution.

## Hardening after the incident

- One key per tool, per project. Give every tool that holds a provider key its own key with its own cap. When one copy leaks, the blast radius is one tool, and the owner is obvious.
- Know who owns each key. Keys tend to start on one developer's account and spread into several tools. Unowned keys are the ones nobody rotates.
- Count every copy. Every hosted service that stores your raw provider key is another place it can leak from, including tools you have stopped using. This one leaked from a system OpenCode was already shutting down.
- Prefer credentials a third party never holds. Where a provider offers OAuth sign-in or short-lived credentials for a tool, use them instead of pasting a long-lived key into another company's database.
- Treat AI tools as non-human identities. Apply the same ownership, rotation and least-privilege rules as any service account. Our guide to secrets management for AI agents covers the practices, and securing LLM gateways and proxies covers the gateway layer that Console's bring-your-own-key feature is an instance of.
- Rehearse the rotation. Time how long it takes to revoke and replace every key for one provider. The AI agent incident response playbook explains why pausing a tool is not the same as revoking its credentials.

## How Anomity helps

To be clear about the limit first: Anomity does not see inside OpenCode Console. The keys in this breach were stored on OpenCode's servers, and no endpoint sensor can list them. What Anomity gives you is the endpoint half of the response.

**Find where OpenCode runs.** The Endpoint Sensor inventories the OpenCode CLI and OpenCode Desktop on every managed machine, with versions. That is the list of developers to ask about Console, and it is more reliable than a survey.

**See what OpenCode is wired to.** The sensor reads OpenCode's global and project config files and surfaces the MCP servers, permission rules and plugins declared there, so you know what else a developer's OpenCode setup can reach.

**Find the local copies of provider keys.** Secrets found in AI tool configs, including OpenAI, Anthropic, Google and OpenRouter key formats, are flagged with their values redacted on the endpoint. During a rotation, that shows where plaintext keys still sit on the fleet, so the replacement reaches every copy and not just the one in Console. Findings route to SIEM, Slack, email or Jira, and changes land in a 90-day audit trail, which is how you confirm the old keys are gone.

**Watch the browser path.** The Browser Sensor detects secrets pasted or typed into AI web services. Pasting a raw provider key into a hosted AI tool is exactly the step that put these keys in Console, and organizations can add their own domains to the list the Browser Sensor watches.

## Sources

- OpenCode on X, statement of October 17, 2026 (posted 17:56 UTC, edited 18:08 UTC).
- OpenCode customer notice "Action Required: Potential provider key breach", as shared by recipients and quoted by Cybersecurity News and CellCog.
- OpenCode documentation: Console Providers and BYOK pages, and the Providers page for local credential storage.
- Dax Raad (OpenCode) on X, October 17, 2026, on Console versus local keys.
- Lydia Hallie (Anthropic) on X, October 17, 2026, on revoked Claude API keys.
- Cyera, "OpenCode Breach: What Happened and How to Rotate Exposed AI API Keys", October 17, 2026.
- Cybersecurity News, "OpenCode Security Breach Exposes Third-Party API Keys of its Console Users", October 18, 2026.
- CellCog, "OpenCode Breach: Provider API Keys Exposed, What to Do", October 17, 2026.

OpenCode says the incident is ongoing, and we will update this advisory as it publishes more. Until then, rotate first and investigate second. To see which machines in your fleet run OpenCode and where AI provider keys sit in plaintext, [book a 30-minute demo](https://anomity.ai/#early-access).

Share: Copied

## Frequently asked questions

Was every OpenCode user affected by the breach?
No. OpenCode says the breach affected 1.4% of OpenCode Console users, a subset who had external providers linked to a Console workspace, and that it emailed all of them on the morning of October 17, 2026. Its guidance is that if you did not get the email, you were not impacted. OpenCode Console is the optional hosted service on top of the open-source agent, so the 1.4% is a share of Console users, not of everyone who runs OpenCode. OpenCode has not published how many people that is.

Were keys I configured in the local OpenCode CLI exposed?
Nothing published so far says so. OpenCode's Dax Raad stated that this concerns OpenCode Console, not OpenCode itself, and that keys used in the local app never come to the company. OpenCode's documentation says keys added with the /connect command are stored on the developer's machine in ~/.local/share/opencode/auth.json. Those keys have their own risks, any process running as the developer can read that file, but they were not in the system OpenCode says was breached. If the same key was also saved in Console, it was exposed through Console and must be rotated.

What is a distillation attack, and why would it need stolen keys?
Distillation is training one model on the outputs of another. Done without permission, it means sending very large volumes of prompts to a strong model and keeping the answers. Model providers try to stop it by catching fraudulent accounts, and Anthropic has written about distillers running networks of such accounts. A real customer's API key sidesteps that check, and the bill lands on the customer. OpenCode used the term but has not explained how the breach and the distillation activity are connected, so treat that link as OpenCode's description rather than an established technical account.

Is deleting the key from OpenCode Console enough?
No. Removing or replacing a key in Console stops Console from using it, but anyone who already copied the key can keep calling the provider directly. Revoke the key on the provider's own API keys page, which kills it everywhere. Console usage reports and budgets also only count traffic that flows through Console, so a stolen key used directly against the provider never shows up there. The provider's usage and billing pages are the place to look for misuse.

Is this the same issue as the OpenCode GHSA-632h-h47v-g4x4 advisory?
No. GHSA-632h-h47v-g4x4, published September 24, 2026, was a flaw in the local opencode serve server that let a web page make it install an attacker's npm package, fixed in OpenCode 1.18.22. The October 17 breach is an incident on OpenCode's hosted Console service and involves provider keys stored server-side. They have different causes and different fixes, though both point at the same lesson: an AI coding tool's trust boundary includes every place it keeps a credential.

How does Anomity help with this?
Anomity cannot see inside an OpenCode Console workspace, because those keys live on OpenCode's servers. What the Endpoint Sensor does show is every managed machine with the OpenCode CLI or OpenCode Desktop installed and its version, which gives you the list of people to ask whether they linked provider keys in Console. It also reads OpenCode's global and project config files for MCP servers, permissions and plugins, and flags plaintext provider keys it finds in AI tool configs, including OpenAI, Anthropic, Google and OpenRouter key formats, with values redacted on the endpoint, so a rotation can reach every local copy. Findings route to SIEM, Slack, email or Jira and are kept in a 90-day audit trail.

## Related posts

[Advisory High ### Mass Scanning and SSRF Campaign Against Exposed LLM Infrastructure - GreyNoise 2025-2026 GreyNoise's Ollama honeypots logged 91,403 attack sessions (Oct 2025-Jan 2026) probing 73+ LLM endpoints and abusing model-pull SSRF. 80,469 in 11 days. Anomity Research · Jan 8, 2026 · GreyNoise LLM honeypot campaign (Oct 2025 - Jan 2026)](https://anomity.ai/blog/llm-infra-mass-scanning-ssrf-campaign-2025-2026/)

[Advisory High ### LiteLLM api_base SSRF Leaks Upstream Provider Keys - CVE-2024-6587 CVE-2024-6587 is a CVSS 7.5 SSRF in LiteLLM through 1.38.10: a caller-set api_base made the proxy forward the provider key. Fixed in 1.44.8. Anomity Research · Aug 30, 2024 · CVE-2024-6587 (GHSA-g26j-5385-hhw3)](https://anomity.ai/blog/litellm-ssrf-api-base-key-leak-cve-2024-6587/)

[Advisory High ### OpenCode Server Cross-Site Upgrade Installs Attacker Packages - GHSA-632h-h47v-g4x4 A web page could make OpenCode's local server install an attacker's npm package via a cross-site form. No DNS rebinding needed. Fixed in 1.18.22. Anomity Research · Oct 2, 2026 · GHSA-632h-h47v-g4x4 (CVSS 7.5, no CVE)](https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them",
  "description": "OpenCode says a breach of a legacy Console system exposed provider keys for 1.4% of Console users. What is confirmed, who is affected, and how to rotate keys.",
  "datePublished": "2026-10-18",
  "dateModified": "2026-10-18",
  "author": {
    "@type": "Organization",
    "name": "Anomity",
    "url": "https://anomity.ai/",
    "sameAs": [
      "https://www.linkedin.com/company/anomity",
      "https://github.com/Anomity-ai",
      "https://www.wikidata.org/wiki/Q140763940"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "name": "Anomity",
    "url": "https://anomity.ai/",
    "sameAs": [
      "https://www.linkedin.com/company/anomity",
      "https://github.com/Anomity-ai",
      "https://www.wikidata.org/wiki/Q140763940"
    ],
    "logo": {
      "@type": "ImageObject",
      "url": "https://anomity.ai/anomity-logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://anomity.ai/blog/opencode-console-breach-ai-provider-keys-rotation/",
    "relatedLink": [
      "https://anomity.ai/blog/llm-infra-mass-scanning-ssrf-campaign-2025-2026/",
      "https://anomity.ai/blog/litellm-ssrf-api-base-key-leak-cve-2024-6587/",
      "https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/"
    ]
  },
  "image": {
    "@type": "ImageObject",
    "url": "https://anomity.ai/assets/blog/covers/prompt-injection.jpg",
    "width": 1200,
    "height": 630
  },
  "articleSection": "LLM Gateways & Proxies",
  "wordCount": 1661,
  "timeRequired": "PT8M",
  "inLanguage": "en",
  "url": "https://anomity.ai/blog/opencode-console-breach-ai-provider-keys-rotation/",
  "keywords": "OpenCode breach API keys, OpenCode Console breach, disclosed October 17, 2026 (no CVE or GHSA), OpenCode, OpenCode Console, API Key Rotation, LLMjacking, Distillation Attack, BYOK, AI Provider Keys, Secrets Exposure, AI Agent Security"
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was every OpenCode user affected by the breach?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. OpenCode says the breach affected 1.4% of OpenCode Console users, a subset who had external providers linked to a Console workspace, and that it emailed all of them on the morning of October 17, 2026. Its guidance is that if you did not get the email, you were not impacted. OpenCode Console is the optional hosted service on top of the open-source agent, so the 1.4% is a share of Console users, not of everyone who runs OpenCode. OpenCode has not published how many people that is."
      }
    },
    {
      "@type": "Question",
      "name": "Were keys I configured in the local OpenCode CLI exposed?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nothing published so far says so. OpenCode's Dax Raad stated that this concerns OpenCode Console, not OpenCode itself, and that keys used in the local app never come to the company. OpenCode's documentation says keys added with the /connect command are stored on the developer's machine in ~/.local/share/opencode/auth.json. Those keys have their own risks, any process running as the developer can read that file, but they were not in the system OpenCode says was breached. If the same key was also saved in Console, it was exposed through Console and must be rotated."
      }
    },
    {
      "@type": "Question",
      "name": "What is a distillation attack, and why would it need stolen keys?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Distillation is training one model on the outputs of another. Done without permission, it means sending very large volumes of prompts to a strong model and keeping the answers. Model providers try to stop it by catching fraudulent accounts, and Anthropic has written about distillers running networks of such accounts. A real customer's API key sidesteps that check, and the bill lands on the customer. OpenCode used the term but has not explained how the breach and the distillation activity are connected, so treat that link as OpenCode's description rather than an established technical account."
      }
    },
    {
      "@type": "Question",
      "name": "Is deleting the key from OpenCode Console enough?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Removing or replacing a key in Console stops Console from using it, but anyone who already copied the key can keep calling the provider directly. Revoke the key on the provider's own API keys page, which kills it everywhere. Console usage reports and budgets also only count traffic that flows through Console, so a stolen key used directly against the provider never shows up there. The provider's usage and billing pages are the place to look for misuse."
      }
    },
    {
      "@type": "Question",
      "name": "Is this the same issue as the OpenCode GHSA-632h-h47v-g4x4 advisory?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. GHSA-632h-h47v-g4x4, published September 24, 2026, was a flaw in the local opencode serve server that let a web page make it install an attacker's npm package, fixed in OpenCode 1.18.22. The October 17 breach is an incident on OpenCode's hosted Console service and involves provider keys stored server-side. They have different causes and different fixes, though both point at the same lesson: an AI coding tool's trust boundary includes every place it keeps a credential."
      }
    },
    {
      "@type": "Question",
      "name": "How does Anomity help with this?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Anomity cannot see inside an OpenCode Console workspace, because those keys live on OpenCode's servers. What the Endpoint Sensor does show is every managed machine with the OpenCode CLI or OpenCode Desktop installed and its version, which gives you the list of people to ask whether they linked provider keys in Console. It also reads OpenCode's global and project config files for MCP servers, permissions and plugins, and flags plaintext provider keys it finds in AI tool configs, including OpenAI, Anthropic, Google and OpenRouter key formats, with values redacted on the endpoint, so a rotation can reach every local copy. Findings route to SIEM, Slack, email or Jira and are kept in a 90-day audit trail."
      }
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://anomity.ai/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://anomity.ai/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "OpenCode Console Breach - Exposed AI Provider Keys and How to Rotate Them",
      "item": "https://anomity.ai/blog/opencode-console-breach-ai-provider-keys-rotation/"
    }
  ]
}
```
