OpenCode Called It a Distillation Attack. User Keys Leaked

On 17 October 2026 at 18:08 UTC, OpenCode confirmed that its servers had been breached. Its official statement described an incident on the night before. OpenCode called it a large-scale distillation attack, and said the impact fell on 1.4% of OpenCode Console users. The company emailed every affected user on the morning of 18 October.

The victims were not code and not repositories. The victims were users' own API keys. If you ever connected an OpenAI, Anthropic, or Google account to OpenCode Console, the key you stored there may have been copied by someone else. OpenCode itself told users to revoke and replace it through the provider's dashboard, not to delete it inside OpenCode.

That last point is the one people forget, and it is the one that decides whether your bill stops or keeps running.

The timeline: 14:35 to 18:08 UTC

What became public started on the user side, not from OpenCode's own team. The sequence shows they knew about the incident several hours after the leak began.

The customer email was titled Action Required: Potential provider key breach. In it, the company said an unauthorised party accessed a legacy system they were decommissioning. Third-party provider keys stored in the user's workspace were said to have possibly been exposed.

Look at the last row of the table. On 18 October, OpenCode's own status page did not show the incident. That means someone checking the status page, the most natural way to confirm a service is safe, learned nothing from it.

Why an API key is a different target from code

A typical server leak means files leak: source code, databases, internal credentials. What breaks is the system that owns those files.

OpenCode has a different structure. The Console is the layer between a developer and a model provider. The user's API keys sit in that layer, because the tool has to send requests to OpenAI, Anthropic, or Google on that person's behalf. Once the key lives on someone else's server, that server becomes a vault, and the contents of that vault do not belong to the vault's owner.

That is why the damage is disproportionate to the size of the incident.

Look at the third row. A leaked API key can be used from any machine in the world, and the cost lands directly on a bill belonging to someone who does not know. A key deleted inside OpenCode is revoked nowhere. That is why OpenCode explicitly asked users to revoke at the provider's dashboard.

What a distillation attack actually means

The phrase OpenCode used, a distillation attack, is not a technical term for breaking into a server. It is the term for copying a model's capability.

Distillation works in a simple way. If you have access to a large model's outputs, you can generate thousands of questions and collect the answers. You can also collect the model's reasoning traces, then train a smaller model to imitate them. The capability moves without ever copying the original weights.

That is exactly why a leaked API key is such a specific target. What a distiller needs at scale is not access to OpenCode's servers, and not exfiltration from a model provider. What is needed is one thing: a large number of API calls, paid for by someone else.

The irony is worth sitting with. Distillation is a legal, industry-recognised way to move capability. DeepSeek shipped six models distilled from R1 under the MIT licence. Its release notes explicitly allow API outputs to be used for fine-tuning and distillation. What is not legal is distilling on someone else's bill.

Pull the stolen keys from someone else's API at scale, and OpenCode calls it a distillation attack. The word is accurate, and the word explains the motive: this was not data theft, it was capability theft.

What you should do right now

If you never connected API keys to OpenCode Console, there is nothing to do. OpenCode states this directly: if you did not get an email, you were not impacted. One thing is still worth checking yourself, though: usage on your provider accounts since 16 October.

If you were connected, the order matters.

• Revoke the key in the provider's dashboard. OpenAI, Anthropic, and Google each have a page for this. Deleting the key inside OpenCode does not stop anyone else using it.
• Issue a new key with a spend limit that matches your real usage, so a second breach does not run up an unbounded bill.
• Review usage history since 16 October 2026. Look for spikes you do not recognise, especially overnight, because that is the pattern users reported.
• Check other applications using that key. A leaked key works from anywhere, not just through OpenCode.
• Keep the billing records. For a dispute with a provider, a usage history showing an abnormal spike is far stronger evidence than a claim on its own.

Refunds were described as under way, and as of 19 October 2026 no complete public reimbursement policy had been published. So do not wait for money back before revoking the key.

Analysis: what is still unanswered, and why you should not panic

Several important questions have no public answer, and readers deserve to have that stated plainly. Here is what is known.

• No root cause has been published. OpenCode says the incident is ongoing and that it cannot share more details. There is no post-mortem, no intrusion timeline, and no list of the data that was accessed.
• No attribution. No group has claimed the attack, and no pattern ties it to any particular country. Only the stated motive exists, and that is distillation.
• The scale named is 1.4% of Console users. That figure comes from OpenCode and has not been independently audited. What is clear is that this is not everyone running the OpenCode CLI on a laptop, and not all users. Keys configured locally on your own machine were not identified as part of the compromised system.
• The compromised system was a legacy system that was in the process of being decommissioned. That is the sentence worth remembering. Systems being decommissioned are where security forgets to look. Nobody owns them, nobody audits them, and nobody patches them. That is not a technical accident, it is a pattern.

That last point is the important one. This incident did not happen because AI is dangerous. It happened because a server was left behind, and a server that has been left behind does not care that you are keeping money in it.

The good news is one thing. A revoked API key stops working immediately, and model providers block revocation within minutes. What is lost is not the key, it is the money. And the money can be reclaimed with evidence.

There is one angle rarely discussed, and it explains why the distillation motive makes economic sense. Distillation needs volume. A single leaked key gives access to a single account, with limits and costs. Thousands of keys leaking from one server give access to thousands of accounts at once, at no compute cost of their own. The attacker pays exactly one thing: the time to write the script that collects outputs. A scale like that is unreachable by training a model yourself, because training cost dominates the entire bill and cannot be squeezed lower.

The second row is the one that matters most to you as a user. Legitimate distillation leaves a tidy trace: usage is recorded, and the bill lands on the account you pay for. Distillation through leaked keys leaves a messy one, and that messiness is exactly what makes it detectable. Which is why checking your usage history is not an optional step. It is the only way you can find out on your own that your key is being used by someone else.

The good news is one thing. A revoked API key stops working immediately, and model providers block revocation within minutes. What is lost is not the key, it is the money. And the money can be reclaimed with evidence.

The bigger pattern: the AI agent as credential holder

There is something more interesting here than one incident, and that is why this is worth reading as an explanation rather than as news.

OpenCode is not the first case, and the mechanism repeats. On 12 January 2026, CVE-2026-22812 was published with a CVSS score of 8.8. Before version 1.0.216, OpenCode automatically started an unauthenticated HTTP server. That server let any local process run arbitrary shell commands with the user's privileges. Any website could reach it too, through permissive CORS.

In September 2026, CVE-2026-88899, scored 9.8, covered a path in the Worktree.remove component that was not validated. A payload could make directories be deleted recursively. A third finding followed on 10 September 2026, about the x-opencode-directory header on the proxy endpoint, which let file operations happen outside the project root.

Those three findings are not the same problem. What they share is an architecture. An AI coding tool sits between the developer and the model provider. The tool holds the credential, then executes what it is told. That is where the real authority lives.

Nine months later the same configuration leaked not through an open local port but through a server being decommissioned. Both times the reason was a credential holder carrying more trust than it had earned.

And that is the practical reason this matters to anyone who is not a security professional. Every time you paste an API key into a third-party tool, you are putting money in someone else's house. OpenCode is not a special case. OpenCode is just the case that happened to blow up in public, with a number you can count and a bill you can show to a bank.

There is one question nobody outside can answer, and that matters too. We do not know whether anything else was taken. User prompts, pieces of code, repository names, all of it has value to somebody. Nobody knows, and that gap in what we know is itself part of the risk.

As of 19 October 2026, there is still no official answer on how long the access lasted. Two things are clear. The keys have to be revoked at the provider, and until they are, the bill keeps running.