OpenCode says a breach of a legacy system may have exposed artificial-intelligence provider keys linked by a subset of its users, putting the focus on credentials that customers stored in workspaces rather than on a confirmed compromise of every account.

What OpenCode disclosed

OpenCode said in an official statement posted on Oct. 17 that a large-scale “distillation attack” breached a legacy system. The company said 1.4% of Console users were affected, specifically a subset whose accounts had external provider keys linked. It also said keys stored in workspaces may have been exposed. Those points come from OpenCode’s own account of the incident, not from an independently published forensic audit; the company statement is therefore the primary source for the scope and the description of the suspected cause.

OpenCode said the incident was ongoing and that it was coordinating with Anthropic, OpenAI and Google. The statement did not establish an attacker’s identity, provide a count of exposed keys, or publish a total for any resulting losses. It also did not establish that every linked key was accessed or used. Those omissions matter because a disclosure that a credential “may have been exposed” is materially different from a finding that a credential was copied, tested, or used for unauthorized requests.

The company’s wording also leaves the causal framing attributed to it. “Distillation attack” is OpenCode’s description of the event; the supplied reporting does not provide independent confirmation of that characterization. The same caution applies to the 1.4% figure. It is a company-reported proportion, not an independently audited measurement. The Notebookcheck report, published Oct. 17 and updated Oct. 18, says it relied on OpenCode’s official post and email material alongside user reports, rather than presenting separate forensic evidence.

The stated scope and its limits

The most useful way to read the disclosure is as a set of nested conditions. OpenCode did not say that all Console users were affected. It described 1.4% of users as affected, then narrowed that group to users with external provider keys linked. Within that context, it said keys in workspaces may have been exposed. The sequence does not support the broader claim that all OpenCode users, all linked accounts, or all stored keys were compromised.

Nor does the disclosure support a confirmed loss total. A key can be exposed without the available evidence proving that it was subsequently used. Conversely, a user can observe an unfamiliar charge without the available evidence proving that OpenCode’s incident caused it. Keeping those propositions separate is essential while the incident is described as ongoing.

Recent AI and International coverage has included model releases, workplace research, commercial partnerships and policy disputes. This story is different in kind: it is a live security disclosure involving a software system and credentials that users connected to outside AI providers. That distinction makes the evidence hierarchy especially important. The primary statement establishes what OpenCode says happened; independent coverage helps document the public response, but repetition of the company’s account is not independent confirmation of the breach’s scope or cause.

There is also a time dimension. OpenCode’s statement was dated Oct. 17, while Notebookcheck’s article was updated on Oct. 18. An ongoing incident can produce additional facts, revised scope estimates or further guidance. At the point covered by the supplied sources, no later independently verified key count, attacker attribution, or aggregate financial-loss figure is established.

Why linked provider keys matter

External provider keys are credentials that let a connected service make requests to a provider on a user’s behalf. In a normal setup, linking one can make an outside model or API available inside another product. The security consequence is straightforward: if such a credential is exposed and remains valid, an unauthorized party may be able to attempt requests that the provider associates with the key’s owner. That is a risk explanation, not a finding that such use occurred in this incident.

The workspace detail is similarly important but limited. OpenCode said keys in workspaces may have been exposed; it did not say that every workspace contained a key, that every key was readable, or that every exposed key was exploited. “May have been exposed” should therefore be treated as a reason to take precautionary action, not as proof of universal compromise.

It is also important not to turn provider coordination into a claim about provider findings. OpenCode said it was working with Anthropic, OpenAI and Google. That indicates coordination reported by OpenCode; it does not, on the supplied evidence, show that any of those companies independently confirmed the breach, identified misuse, or published a provider-side loss assessment.

What is known about the reported charges

Notebookcheck described users reporting unauthorized AI charges after the disclosure. The supplied notes identify two examples: one user self-reported roughly $400 in charges, while another reported about €200. These are anecdotes, not an aggregate total and not independently verified loss figures. They show why users were concerned; they do not show how many people were affected, how much money was lost overall, or that each report came from a compromised OpenCode key.

The distinction between an observation and an attribution is particularly important here. An unfamiliar bill may be consistent with unauthorized key use, but the sources supplied do not establish a complete chain from the legacy-system breach to either anecdote. Notebookcheck’s use of Reddit and official communications gives readers evidence about what was being reported publicly, not an audited incident ledger. The safest description is therefore that some users reported possible unauthorized charges, while the aggregate financial impact remains unknown.

There is no verified attacker identity in the supplied material. There is no independently established number of keys exposed, no confirmed number of requests made with them, and no public total for charges tied to the incident. Those details define the boundary between a company disclosure and a completed forensic account.

That boundary should guide headlines and social posts as well. “OpenCode says a legacy breach may have exposed linked keys” accurately reflects the evidence. “All users were hacked,” “the attacker stole every key,” or “the breach caused hundreds of thousands in losses” would go beyond it. Even the word “confirmed” needs care: OpenCode confirmed that it was disclosing an incident, while the supplied independent report did not independently confirm the company’s scope or causal explanation.

What affected users can do now

The reported guidance is precautionary: revoke or rotate linked provider keys and review usage. A user who linked a third-party credential should identify the affected provider, invalidate the old key where the provider allows it, create a replacement if continued access is needed, and update legitimate integrations. A team should make that change through its normal ownership and access process so that a replacement credential is not left in an old workspace or shared configuration.

Reviewing provider usage and billing is the second part of the response. Look for unfamiliar requests, timing that does not match normal activity, or charges that cannot be explained by the account’s users. Preserve relevant records while avoiding publication of the key itself. If an unfamiliar charge appears, contact the relevant provider through its normal support or billing channel; the supplied sources do not specify a refund process or guarantee an outcome.

These steps do not establish that a user’s key was compromised. They reduce exposure while OpenCode’s incident remains ongoing. Because the company said it was coordinating with Anthropic, OpenAI and Google, users should also watch for further first-party updates from OpenCode or the relevant provider. This article does not replace provider instructions, and it is not investment, legal or financial advice.

For readers assessing future updates, three questions are useful: Has OpenCode revised the 1.4% estimate? Has it published evidence or a more specific account of what the legacy system exposed? Has any provider independently reported confirmed misuse or a related billing determination? Until those questions are answered by authoritative sources, the responsible position is to treat the incident as a credible company-reported risk with important facts still unresolved.

FAQs

Were all OpenCode users affected?

No. OpenCode said 1.4% of Console users were affected, and described that group as a subset with external provider keys linked. The percentage and scope are company claims, not independently audited findings.

Does the disclosure prove that every linked key was stolen?

No. OpenCode said keys stored in workspaces may have been exposed. The supplied evidence does not establish that every key was accessed, copied, or used.

Are the reported charges a confirmed total loss?

No. The roughly $400 and €200 figures were self-reported examples cited in coverage. They are anecdotal and do not establish an aggregate or verified loss.

Who did the attack?

The supplied sources do not establish an attacker’s identity. OpenCode’s “distillation attack” description is company-attributed, not independently confirmed in the evidence provided.

What should a user with a linked key do?

Revoke or rotate the key and review the relevant provider’s usage and billing, following provider and account-owner procedures. Avoid sharing the credential while investigating.

References