The OpenCode breach may have exposed third-party AI provider API keys belonging to approximately 1.4 per cent of OpenCode Console users. OpenCode disclosed the incident on 17 October 2026 and urged affected customers to revoke and rotate their credentials.
The company linked the security incident to what it called a large-scale distillation attack. Users have reported unauthorised activity and unexpected charges on connected provider accounts, making rapid credential replacement particularly important.
What happened in the OpenCode breach
OpenCode said the breach occurred overnight from 16 to 17 October 2026. According to information contained in customer emails, an unauthorised party accessed a legacy Console system that was already in the process of being decommissioned.
That system reportedly contained API keys saved within user workspaces. These credentials enabled OpenCode Console users to connect the hosted coding agent platform to external AI model providers.
OpenCode said approximately 1.4 per cent of Console users were affected. The potentially exposed population was not the entire user base, but a subset of Console customers who had linked external providers and stored the relevant credentials in their workspaces.
Reports consistently identify Anthropic and OpenAI credentials as potentially affected. Several secondary reports also name Google, although OpenCode has not yet published a detailed incident report that confirms the exact provider-by-provider scope. The company has said it is working with Anthropic, OpenAI and Google on remediation.
Legacy system held sensitive credentials
The reported point of access was a legacy system being decommissioned, rather than a newly disclosed vulnerability in a current release of the OpenCode coding agent. OpenCode has not identified any affected software version or published details of a vulnerability that customers could patch.
The security concern instead centres on provider API keys stored in Console workspaces. If an attacker obtains one of these keys, they may be able to submit requests directly to the associated provider and consume the account holder’s quota or credit.
This provides a plausible explanation for the unauthorised usage and unexpected spending reported by users after the OpenCode breach. Provider-side records may show the resulting queries and charges even if the activity did not originate from the legitimate customer.
OpenCode breach timeline and notifications
The incident began on 16 October 2026 and continued overnight into 17 October. OpenCode contacted affected users on the morning of 17 October, advising them that provider credentials saved in their workspaces might have been exposed.
Later on 17 October, OpenCode publicly acknowledged the breach through its account on X. The company stated that the event was connected to a large-scale distillation attack, affected about 1.4 per cent of Console users and remained under investigation.
Reports published that day provided further information from the customer notification. They described the compromised environment as a legacy system under decommissioning and documented user accounts of unauthorised provider usage and charges.
As of the disclosure, the key events were:
- 16 October 2026: The original security incident began.
- Overnight from 16 to 17 October: The breach occurred within the legacy Console environment.
- 17 October, morning: OpenCode emailed users it had identified as affected.
- 17 October: OpenCode publicly confirmed the incident and its estimate that 1.4 per cent of Console users were affected.
- 17 October: Reports documented unexpected spending on connected provider accounts.
No full technical postmortem or public advisory page was available at the time of disclosure. OpenCode had also not released a detailed explanation of how the attacker entered the legacy system, how long access persisted or whether every potentially exposed key was extracted.
How the distillation attack relates to the breach
OpenCode described the event as related to a large-scale distillation attack. In an AI context, model distillation can involve collecting outputs from one model to help train or reproduce the behaviour of another model.
At scale, that process can require a substantial number of billable model queries. Media coverage has connected the campaign to the use of stored API keys to access models operated by Anthropic, OpenAI and, according to some reports, Google.
However, OpenCode has not publicly explained the precise causal relationship between the distillation activity and the compromise of its legacy system. It is therefore unclear whether stealing keys was the attacker’s original objective, whether the system was compromised specifically to support model harvesting, or whether the credentials were discovered after initial access.
The OpenCode breach is not currently associated with a published proof of concept. It is an incident involving unauthorised system access and possible credential theft, rather than a documented product flaw for which exploit code or a security patch has been released.
Current exploitation and available evidence
There is evidence of in-the-wild credential misuse. Multiple users reported unauthorised activity and charges on their connected provider accounts, indicating that at least some potentially exposed keys may have been used before they were revoked.
No threat actor has been publicly identified or attributed. OpenCode has not released IP addresses, domains, file hashes, file paths or other conventional indicators of compromise connected to the incident.
For affected organisations, provider billing and usage records are consequently the most relevant source of evidence. Warning signs may include sudden increases in token consumption, requests involving unfamiliar models, activity at unusual times or spending that cannot be matched to an authorised project.
The absence of published indicators also means organisations cannot rely on a simple blocklist to determine whether they were affected. OpenCode’s targeted email notification, workspace records and provider-side audit data are more useful for establishing exposure.
Why the OpenCode breach matters
The immediate risks are financial loss and unauthorised consumption of AI services. A stolen key could allow an attacker to generate significant charges until the credential is disabled, its quota is exhausted or provider controls stop the activity.
UK organisations using OpenCode Console may also need to establish which workspace owned each affected key, what permissions it carried and whether it was reused elsewhere. Reusing the same credential across developer tools can extend the impact beyond the compromised Console environment.
Actions for OpenCode Console users
OpenCode advised affected users to revoke and rotate their provider API keys and review usage. Organisations that received a notification, or cannot confirm whether keys were held in the legacy system, should prioritise the following event-specific actions:
- Revoke potentially exposed keys at the relevant provider, rather than only deleting them from OpenCode.
- Create replacement credentials and update authorised applications without reusing the old key.
- Review provider usage, billing and audit logs from 16 October 2026 onwards.
- Investigate unexpected model requests, quota consumption or charges and report disputed activity to the provider.
- Check whether exposed credentials were copied into other tools, scripts or environments.
- Apply provider-side scopes, spending caps and usage alerts where those controls are available.
Rotation should be treated as necessary even where no suspicious spending is visible. Until OpenCode publishes a fuller postmortem, affected users cannot assume that an unused key was not accessed or copied during the OpenCode breach.
Originally reported by Notebookcheck.
