Threat
OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys
First reported thehackernews.com
Page published · Page updated
Earliest dated coverage: 19 Oct 2026 · First observed: 19 Oct 2026 · Latest dated coverage: 19 Oct 2026
Coverage timeline
Single-source incident — one report is available.
Why it matters
OpenCode Console customers notified of the breach should revoke and replace their stored provider keys to prevent unauthorized use of their AI-provider accounts.
OpenCode reported that an intruder accessed a legacy system on October 16, potentially exposing OpenAI, Anthropic, and Google API keys stored in its hosted Console service. The company identified 1.4% of Console users as affected and emailed them on October 17 to revoke and replace their linked provider keys.
Summary
OpenCode reported that an intruder reached a legacy system on the night of October 16, 2026, potentially exposing third-party AI provider keys saved in OpenCode Console. The company identified 1.4% of Console users as affected, all with an external provider linked, and emailed them on the morning of October 17 under the subject “Action Required: Potential provider key breach.” The absolute number of affected users and keys was not disclosed.[0]
The exposure boundary is the optional hosted Console service, where workspaces can save OpenAI, Anthropic, or Google credentials for shared model access. According to the report and its quotation of co-founder Dax Raad, provider keys added locally to the OpenCode command-line and desktop applications remain on the user's machine and do not reach OpenCode. A potentially exposed Console key requires revocation at its issuing provider: deleting it from Console or relying on a Console budget does not invalidate or constrain a copied credential used directly against the provider.[0]
OpenCode had not confirmed that any key was copied or used. The article relays users' allegations of unauthorized charges through other publications, but those allegations do not establish company-confirmed misuse attributable to this breach. OpenCode described the incident as related to a large-scale distillation attack without identifying an actor or explaining the connection. On October 18, Raad reported continuing attack attempts and system hardening.[0]
The supplied evidence does not establish a technical exploit chain, a specific software vulnerability, or a versioned fix. Incident-specific facts come from one news report quoting OpenCode and secondary accounts; the separately supplied OpenAI document provides general security-response guidance rather than independent confirmation of the breach. The grounded response priority is provider-side credential revocation and investigation of provider usage, not an assumed client-software patch.[0][14]
Disclosure timeline
| Date | Event |
|---|---|
| 2026-10-16 | An intruder reportedly reached an OpenCode legacy system during the night, potentially exposing provider keys saved in Console. The report says OpenCode had not disclosed when the unauthorized access began.[0] |
| 2026-10-17 | OpenCode emailed affected users in the morning with the subject “Action Required: Potential provider key breach,” directing them to revoke and replace their provider keys.[0] |
| 2026-10-17 | In a later public post, OpenCode said users who had not received the email were not affected. It described the incident as ongoing, reported cooperation with Anthropic, OpenAI, and Google, and asserted a relationship to a large-scale distillation attack.[0] |
| 2026-10-18 | Co-founder Dax Raad said attackers had been attempting to access OpenCode's systems continuously for the preceding 48 hours and that the systems were being hardened.[0] |
How it works
The documented credential-exposure boundary is Console's hosted storage and use of customer-supplied provider keys. Console uses a workspace's saved key to call the external model provider without revealing the key to team members. The report connects unauthorized access to a legacy system with possible exposure of these hosted credentials, but does not identify the compromised component, access vector, storage protections, or a demonstrated extraction method.[0]
The potential downstream abuse mechanism is bearer-credential reuse, not a confirmed post-compromise sequence. A holder of a copied provider key can submit billable requests against the owner's account until the provider revokes it. Such requests can bypass Console entirely, so deleting the Console copy does not revoke the credential and Console's gateway-level budget cannot cap that direct usage. OpenCode had not confirmed that this reuse occurred.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| OpenCode Console hosted service | Potential exposure of externally issued AI provider keys saved in Console workspaces. OpenCode identified 1.4% of Console users as affected, all with an outside provider linked. The report distinguishes this scope from provider keys stored locally by the command-line and desktop applications; it gives no affected software-version range. | No versioned patch or completed remediation is identified in the supplied report. OpenCode directed affected users to revoke and replace keys with their providers, while its co-founder reported ongoing hardening on October 18.[0] |
Key takeaways
- Distinguish hosted Console credentials from locally stored OpenCode application credentials. The reported exposure concerns keys saved in Console, and OpenCode used a targeted notification email to identify its affected user cohort.[0]
- Credential containment must occur at the issuing provider. Console-side deletion and budget settings do not neutralize a copied key used outside the Console gateway.[0]
- Treat attribution, distillation purpose, and downstream misuse as unresolved. The supplied report contains no named attacker, actionable attacker indicators, or disclosed initial-access mechanism, and distinguishes possible exposure from confirmed copying or use.[0]
Defensive actions
- For provider keys identified as potentially exposed through Console, revoke each old key in the issuing provider's dashboard and create a replacement.: The key remains a usable bearer credential until the provider revokes it. Removing it from Console alone does not invalidate a copy held elsewhere.[0]
- Update every application and script that used a revoked key to use its replacement.: The incident-specific response instructions include updating all consumers of the old credential after revocation and replacement.[0]
- Review usage and billing in the affected provider accounts for unauthorized requests, going back at least to October 16.: The report identifies October 16 as the night of legacy-system access but says OpenCode had not disclosed when unauthorized access began. Provider-side review is necessary because requests made with a copied key need not pass through Console.[0]
- Configure spending limits or alerts at the AI provider rather than relying solely on a Console budget.: Console only sees requests traversing its gateway and cannot cap direct use of a copied provider key. Provider-side controls address the billing boundary relevant to this incident.[0]
- Give each tool its own provider key when replacing credentials.: The report recommends separate keys to reduce the damage from a copied credential and make its use easier to trace.[0]
- Contact OpenAI Support promptly if compromise or unauthorized use of an OpenAI key is suspected.: The supplied OpenAI security guide explicitly directs users who suspect account or API-key compromise to contact support right away. This is provider response guidance, not confirmation that an OpenAI key was abused in this incident.[14]