OpenCode disclosed on October 17, 2026 that an intruder reached a legacy Console system the company was already in the process of shutting down, and that third party provider keys some users had saved there, for OpenAI, Anthropic, and Google, may have been exposed. Within a day, affected users were reporting real charges: one told reporters his OpenAI key had been used for $281 and his Anthropic key for $168, another put total losses at $1,700.
Jump to what we checked in our own decommissioning process if you have ever left an old system reachable while planning to retire it.
What Happened to OpenCode's Console
OpenCode Console is the project's optional hosted service: a workspace saves its own OpenAI, Anthropic, or Google key there, and Console calls the provider on the team's behalf so individual members never need to see the key directly. OpenCode says the intrusion reached a system tied to Console that was already scheduled for decommissioning, not the open-source command-line tool itself, and not the local SQLite credential store the CLI and desktop apps use on a developer's own machine.
The company put the affected population at approximately 1.4% of Console users, specifically those who had linked an external provider key to their workspace. According to OpenCode's own notice, it emailed every affected account the morning after discovering the intrusion.
OpenCode has described the incident as related to a large-scale distillation attack, a technique for harvesting a model's responses at volume to train a separate model. It has not explained how that technique connects to a legacy-system credential exposure, what the legacy system was, or how many keys it held.
Why Third Party Provider Keys Are a Different Kind of Exposure
A leaked database password mostly threatens the data behind it. A leaked third party provider key threatens an open-ended line of credit billed to its owner, because the provider has no way to know the request came from an attacker rather than the legitimate workspace.
According to reports gathered by multiple outlets, usage against stolen keys started within roughly a day of the breach. By at least one account, unauthorized usage continued for 48 hours before affected users had fully revoked and replaced their credentials.
The mechanism OpenCode has confirmed is specific: these were not OpenCode's own API credentials. They were customer keys that customers had chosen to store on OpenCode's servers so Console could call providers on their behalf.
That decision, made individually by each workspace, is what turned a breach of one vendor's legacy infrastructure into a billing event at three completely different companies that had no direct relationship to the intrusion at all.
What We Checked in Our Own Decommissioning Process
We reviewed every system at Krova Cloud currently marked for retirement but not yet fully shut down, the exact state OpenCode's breached Console system was reportedly in. We found one staging API gateway, flagged for removal two months ago, still reachable and still holding a cached copy of a provider key from an old integration test. We revoked that key and pulled the gateway down the same day, since a system you intend to retire is still a live attack surface for as long as it keeps running.
What to Check in Your Own Provider Key Usage
- If you linked an OpenAI, Anthropic, or Google key to OpenCode Console, revoke it directly through that provider's own dashboard and issue a replacement, rather than clicking any link inside a breach notification email.
- Review your provider usage and billing history for the window since October 16, 2026, since unauthorized usage in this incident showed up as real charges within about a day.
- Audit every system in your own stack still running "pending decommission," and treat each one as a live credential exposure risk until it is actually turned off, not just scheduled to be.
- Prefer keys scoped to a single workspace or project with spend limits over keys with full account access, since a scoped key caps the blast radius of exactly this kind of exposure.
The limitation worth naming here is how much OpenCode still hasn't said. The company has not disclosed what the legacy system was, how the intruder reached it, or how the breach specifically relates to the distillation attack it blamed, and that gap makes the incident harder to learn from than it should be.
Until an actual technical writeup exists, the honest read is that a known-decommissioning system held live customer secrets for longer than it should have. That verdict doesn't depend on the unresolved parts of the story, but it also doesn't excuse them.
The Rule
A system flagged for decommissioning is not the same as a system that has stopped mattering. As long as it still holds live credentials and still answers requests, it carries the same blast radius as production, with none of the monitoring attention production usually gets. If your retirement process has a step between "scheduled for shutdown" and "actually shut down" that can last weeks, that gap is where incidents like this one happen.
Frequently Asked Questions
What exactly was exposed in the OpenCode Console breach?
Third party provider API keys, for OpenAI, Anthropic, and Google, that users had saved inside their OpenCode Console workspaces so the service could call those providers on their behalf. OpenCode says this affected approximately 1.4% of Console users, specifically those who had linked an external provider.
Were OpenCode's own CLI or desktop app credentials affected?
No. OpenCode says the breach is specific to the Console hosted service, not the open-source CLI or desktop apps, which store any provider keys a user adds locally in a SQLite database on their own machine.
How much money did affected users lose?
Individual users reported specific figures to journalists, not OpenCode itself: one reported $281 in OpenAI charges and $168 in Anthropic charges, another reported total losses of $1,700. OpenCode has not published an aggregate loss figure.
What should I do if I had a provider key linked to OpenCode Console?
Revoke the key directly through the provider's own dashboard, generate a replacement, and review your usage and billing history since October 16, 2026, for unauthorized activity, rather than relying on links inside any notification email.
I'm Rohit, founder of Krova Cloud: disposable VMs that get fully torn down the moment they're retired, not left running with live credentials while a decommissioning ticket sits in a backlog. More debugging stories at debugly.dev.
Top comments (0)