OpenCode Hack: What We Know About the Console Breach

OpenCode confirmed a breach affecting some users of its hosted Console. The public announcement leaves a central question unanswered: how did the attackers get access?

The confirmed scope and the separately disclosed software vulnerabilities deserve a closer look. Sources were checked on October 20, 2026.

What OpenCode confirmed

In its October 17 announcement, OpenCode said the breach affected 1.4% of Console users, specifically a subset with external providers linked. It said affected users had been notified by email and that it was working with Anthropic, OpenAI and Google. OpenCode's announcement.

Dax, who works on OpenCode, clarified that the incident concerned Console. He said credentials used directly in the local OpenCode application do not come to the company. That distinction narrows the reported incident; it does not make every local installation immune to other vulnerabilities. Dax's clarification.

OpenCode described the incident as related to a large-scale distillation attack. Distillation involves using a model's responses or reasoning to reproduce capabilities in another model. That describes a use for model access, without identifying the mechanism used to compromise Console. OpenCode's statement, Anthropic's explanation of distillation attacks.

We could not find a public root-cause report identifying the Console entry point in the sources reviewed. Calling the intrusion sophisticated, attributing it to a particular code flaw, or saying a specific security product would have prevented it would go beyond that evidence.

Were there serious vulnerabilities in OpenCode's code?

Yes. Researchers documented separate vulnerabilities with concrete mechanisms and fixes:

The first issue is documented in OpenCode's security advisory and Datadog's research. The second is documented by Pillar Security.

These reports justify updating affected installations. Neither report establishes that its vulnerability caused the hosted Console breach. A coordinated attack can also exploit an ordinary software bug; sophistication and an underlying vulnerability are compatible explanations, but we do not yet have evidence to select one here.

Why the distinction between Console and local OpenCode matters

OpenCode's current Console documentation describes a gateway that stores connected provider credentials and lets workspace members use the models without seeing those credentials. The external provider bills the customer for that usage. This helps explain why the announcement singles out Console users with linked providers. The documentation describes the product's current design; it does not document the attacker's route into the affected system. Console provider documentation.

Dax's clarification distinguishes that hosted arrangement from credentials used directly in the local application. Treating every OpenCode user as affected would erase that distinction. Equally, the separate local-software vulnerability reports still matter to people running the affected configurations. Dax's clarification.

What a fuller incident report needs to explain

The missing detail is the path from initial access to the affected provider credentials. A technical account would need to identify the compromised component, the permissions the attacker obtained, and how those permissions enabled the exposure or use of keys.

That would help distinguish a flaw in application code from compromised infrastructure credentials, a configuration problem or another route. These are possibilities to investigate, not findings about this incident. The announcement does not establish whether keys were stored in plaintext, whether encryption was bypassed through legitimate decryption access, or whether a known OpenCode vulnerability played any role.

For now, the supported account is narrower: OpenCode disclosed a hosted Console breach affecting a subset of users with linked providers. Its statement connects the incident to a distillation campaign but leaves the intrusion mechanism unexplained. OpenCode's announcement.

---

A general security note: Be selective about services you trust with API keys, use dedicated credentials with the narrowest supported permissions, and monitor provider-side usage. If a provider or service identifies a key as exposed, revoke it at the issuer and replace it through a trusted path. These are general precautions and recovery steps, not evidence that they would have prevented this breach. API key guidance.

At Nextbase, our Unkey integration handles keys issued for access to an application's own API. That is a separate role from safeguarding customer-supplied provider credentials; we cannot claim it would have prevented this incident.