What we know as of 18 October 2026
This section is the part to update when a post-mortem lands. Everything here is attributed.
Confirmed by the OpenCode team
The notice, as quoted in the Hacker News thread, makes three statements. The team found unauthorized access to a legacy system it was decommissioning. Third-party provider keys, with OpenAI and Anthropic as the examples, saved in a workspace may have been exposed. Users should revoke and replace those keys through the provider dashboard[1]. The notice also tells users to review recent usage. Note the wording: "may have been exposed" is not "were stolen", and it is also not "were not used".
Several commenters say the affected system is OpenCode Console, a hosted gateway where you store your own provider keys, similar to how OpenRouter works. They say the CLI, TUI and desktop app are not affected because only the hosted service was compromised. Some users report their OpenCode Go keys were revoked with no unauthorized usage on their side. One commenter claims local .env files read by agents could also be a leak path, citing secondhand posts[1]. None of this comes from OpenCode.
Unknown
- How the attacker got in, and how long they had access.
- Whether the keys were stored encrypted, and whether the encryption keys were also reachable.
- What the keys were used for. The thread mentions a possible "distillation attack"; commenters note there is no public evidence yet linking stolen keys to one, so treat that as speculation.
- Whether workspaces created after the legacy system was retired are in scope.
The practical reading: if you never pasted a provider key into an OpenCode workspace, the notice most likely does not cover you. If you did, or you are not sure, rotate. Rotation costs ten minutes per key. A leaked key with no cap can cost far more.
Do not confuse this with CVE-2026-22812
An older, unrelated issue keeps showing up in search results for "OpenCode vulnerability". CVE-2026-22812 describes OpenCode starting an unauthenticated HTTP server that allows any local process to reach it; the NVD entry says versions before 1.0.216 are affected[2]. The CNA vector is network-reachable with user interaction required[2]. That bug is fixed by updating the client. The October 2026 incident is about keys stored on a hosted system, and updating your CLI does nothing for a key that is already stored there. If you want the wider picture of how coding-agent tooling gets attacked, our MCP server security audit covers the CVE classes that keep repeating.
Order of operations: create, deploy, delete, watch
Deleting first is the instinct, and it is the wrong order for anything running in production. A deleted key fails requests immediately. Do it in this sequence:
- Inventory. List every provider key you ever gave OpenCode, plus every key that sits in the same
.env or secret store. If a provider offers per-project keys, note which project each belongs to.
- Create the new key in the provider dashboard. Give it a name with today's date so you can tell old from new. Prefer a key scoped to one project or workspace.
- Set a spend cap on the account or project before the new key goes live (provider table below).
- Deploy the new key to every place the old one lived: local shell, CI, hosting platform, containers. Restart long-running processes, because most read the environment once at startup.
- Delete the old key. Confirm one real request succeeds on the new key first.
- Watch usage for 48 hours. Compare request counts and cost per day against your normal baseline. Any spend you cannot explain is the signal.
- Do not paste the new key back into OpenCode Console until the team publishes what happened. Use the local CLI with an environment variable instead.
Anthropic's own guidance matches this: rotate by creating new keys and deactivating old ones, and if you suspect compromise, revoke at once[3]. For a key you suspect is leaked and unused in production, skip the careful part and delete immediately.
Provider checklist: revoke, usage, cap
I opened each provider's documentation on 18 October 2026. Where a page did not state a path or feature, the cell says so instead of guessing. Dashboards move; if a link 404s, search the provider console for "API keys".
Anthropic
Delete the key from the Console API keys page, then open Billing and check the Spend limits section. A limit you set blocks requests with a 400 once reached, while the tier ceiling returns a 429 and resets on the first of the next month[4]. Tier ceilings are $500 (Start), $1,000 (Build) and $200,000 (Scale)[4]. Set yours well under that. If you run Claude Code, put it in its own workspace; the Claude Code workspace is limit-checked separately and can answer with a 429 plus a retry-after header[4].
OpenAI
Keys are per project, and the full secret is only shown once at creation, so a lost key means a new key, not a lookup[5]. Create the replacement inside a project, restrict its permissions (All, Restricted or Read Only), and set the project monthly budget with alert thresholds[6]. Because the help article contradicts itself on soft versus hard enforcement, confirm by looking for the option that makes requests fail after the limit.
Google AI Studio, OpenRouter, Groq, DeepSeek, xAI
Google is the clearest of the five: a named Monthly spend cap on the Spend page[7]. On OpenRouter, set a credit limit on the individual key so a leak cannot drain the whole balance[8]. Groq's cap is organization-wide across all keys, which means one noisy key can exhaust the budget for all your apps[9]. xAI and DeepSeek lean on prepaid balance. Prepaid is itself a cap, as long as auto top-up is off or bounded. I could not confirm DeepSeek's usage or cap pages from its public docs, so check the dashboard directly and do not assume.
Find every copy of the old key
A key you rotated in the dashboard but left in a forgotten CI secret will break a deploy on a Friday. A key you deleted but left in a shell file does nothing, but a key left in a repo is the real danger. Search first.
Local files
Run this from your home directory and your project roots. The prefixes are the ones commonly seen on each provider's keys (sk-ant-, sk-proj-, sk-or-, AIza, gsk_, xai-); I could not confirm them against the provider docs I opened, so treat a miss as "not proven absent", and also grep for the old key's last six characters if you have them.
grep -rIE "sk-ant-|sk-proj-|sk-or-|AIza[0-9A-Za-z_-]{30,}|gsk_|xai-|sk-[A-Za-z0-9]{32,}" \
~/.zshrc ~/.zprofile ~/.bashrc ~/.config ~/Projects \
--exclude-dir=node_modules --exclude-dir=.git -l 2>/dev/null
The -l flag prints file names only, so the keys do not land in your terminal scrollback. Open each file and replace the value. Also check ~/.config/opencode and any auth.json the tool wrote, and your shell history with history | grep -E "sk-|gsk_" if you ever exported a key inline.
Remote copies
- GitHub Actions:
gh secret list in each repo, plus gh secret list --org YOUR_ORG and gh secret list --env production for environment secrets. Update with gh secret set NAME.
- Git history:
git log -p -S"sk-ant-" --all finds keys committed and later removed. A key in history must be rotated even if the file is clean now.
- Hosting platforms: Vercel, Cloudflare, Fly, Railway and Docker env files each hold their own copy.
- IDE and extension settings: VS Code
settings.json, JetBrains plugin credential stores, and any MCP server config that passes a key through env.
- Teammates and shared vaults: if a key came from a shared 1Password or Bitwarden item, update the item, not just your machine.
Watching usage for 48 hours
Compromise shows up as spend you cannot map to a deploy. Pick three numbers per provider before you rotate: daily request count, daily cost, and the model mix. Then compare. Two patterns deserve a closer look. A model you do not use appearing in usage, for example a large reasoning model on a key you only use for small summaries. And usage in the hours you were asleep with no scheduled job to explain it.
Keep the old key's last-used time if the dashboard shows one, and note it. If the old key was used after you last touched OpenCode, that is evidence of exposure and worth reporting to the provider's support. Ask them to review the account for the window around 17 October and request a credit for any usage you did not make. Providers decide that case by case, and none of the pages I read promise a refund.
If you want hard guardrails on the agent side as well, a spend hook in your own tooling catches a runaway loop even when the provider cap is high. Our Claude Code spend limit guide compares provider caps in more depth, the Agent Run Cost Simulator estimates what a stuck loop costs per hour so you can pick a sane cap, and the Claude Code Spend Guard hook kit blocks runaway spend locally.
Should you stop using OpenCode?
That depends on how you used it. The reported pattern is that the exposure sits in the hosted service, not in the open-source client. If you run the CLI with keys from your own environment and never stored keys in a workspace, the notice as quoted does not describe you, though you should still run the grep above because the commenter claim about .env files is unresolved. Our OpenCode developer guide covers the tool itself; nothing in this incident changes how the local client works, as far as has been disclosed.
The durable lesson is architectural. Any hosted gateway that stores your keys is a single place where many users' credentials sit together, which makes it an attractive target. Prefer keys that are scoped, capped and disposable, so that the next notice costs you a ten-minute rotation and not a bill.
Frequently asked questions
Is the OpenCode CLI affected by the breach?
OpenCode has not said. Commenters on Hacker News say only the hosted OpenCode Console was affected and the CLI, TUI and desktop app were not[1]. That is unconfirmed. Rotate any key you stored in a workspace regardless.
Do I need to rotate keys I never saved in OpenCode?
The notice only names keys saved in workspaces. Keys that never touched OpenCode are not covered by it. Rotating on a schedule is still good practice; Anthropic suggests something like every 90 days[3].
How do I know if someone used my leaked key?
Look at your provider usage view for requests, models or hours you cannot explain, starting from 17 October. A spend cap will not tell you about misuse, but it limits the damage, so set one first.
Which providers can hard-stop spending?
Anthropic returns a 400 once your own Spend limit is reached[4], Groq blocks API access at the monthly cap[9], and Google AI Studio documents a Monthly spend cap[7]. OpenAI project budgets are soft by default but can reportedly be enforced as hard[6].
Is CVE-2026-22812 part of this incident?
No evidence says so. It is an older flaw in an unauthenticated local server in OpenCode versions before 1.0.216[2]. Update your client, but do not expect that to fix the stored-key exposure.
Sources
- Hacker News: OpenCode Hacked, user credentials leaked (OpenCode team notice quoted in thread, accessed 18 October 2026)
- NVD: CVE-2026-22812 (accessed 18 October 2026)
- Anthropic Support: API key best practices (accessed 18 October 2026)
- Anthropic docs: Rate limits and spend limits (accessed 18 October 2026)
- OpenAI Help: Where do I find my API key (accessed 18 October 2026)
- OpenAI Help: Managing projects in the API platform (accessed 18 October 2026)
- Google AI for Developers: Gemini API billing (accessed 18 October 2026)
- OpenRouter docs: API rate limits and key credit limits (accessed 18 October 2026)
- Groq docs: Spend limits (accessed 18 October 2026)
- DeepSeek API docs (accessed 18 October 2026)
- xAI docs: Billing (accessed 18 October 2026)
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.