🚨 OpenCode Console Breach: Third-Party API Keys Potentially Exposed

OpenCode reported on 17 October 2026 that a security breach affected a subset of Console users who had external model providers connected. The company linked the incident to what it described as a large-scale distillation attack and said third-party provider API keys saved in affected Console workspaces may have been exposed after unauthorized access reached a legacy system that was being decommissioned.

The key distinction is between potential exposure and confirmed misuse. The 1.4% figure is a reported affected-user share; the material reviewed does not quantify the denominator or establish that every affected user had a key stolen, or that exposed keys were subsequently used.

• Unauthorized access reached a legacy system that was being decommissioned.
• Third-party model-provider API keys stored in affected Console workspaces may have been exposed.
• The affected group was reported as 1.4% of Console users. This is not a count of confirmed key misuse, and the reviewed material does not quantify the total user population.
• OpenCode reportedly notified affected users and was working with Anthropic, OpenAI and Google.
• Some secondary coverage describes user concerns about unexpected provider charges. Those concerns should remain labelled as user reports, not as independently confirmed company findings.

The public material reviewed does not fully explain how the claimed distillation activity relates to the legacy-system access or whether it was the cause, context or a broader description of the incident.

This is a timeline of the incident as described in the supplied sources, not an independently reconstructed forensic timeline.

An API key often acts as a bearer credential: a party holding a valid key may be able to make requests within the permissions, quotas and billing arrangements associated with it. A provider may see those requests as valid-key activity unless its telemetry reveals suspicious usage or context.

These are general consequences of credential exposure, not evidence that each outcome occurred in the OpenCode incident.

The source material does not credibly attribute the incident to a named individual or group. “Distillation attack” is the context OpenCode associated with the event; that phrase alone does not identify an attacker or prove the exact technique used to gain access to the legacy system.

Until additional evidence emerges, avoid assigning a nationality, a malware family, an unverified motive, or a definitive MITRE ATT&CK technique set. Doing so would turn a limited public disclosure into unsupported attribution.

Credentials can outlive the projects, services and systems for which they were created. Hosted workspaces, build systems, CI/CD platforms, logs and configuration records can retain secrets even after an associated service is scheduled for retirement.

A decommissioned system should not be assumed to have relinquished its credentials. Retirement needs an explicit inventory-and-revocation step, confirmation that secrets were deleted or rotated, and a record of who verified completion. This is a general security lesson, not a claim that every listed storage location was involved in this incident.

1. Verify the notification. If you received an official OpenCode notice, navigate to OpenCode and provider sites directly rather than following unexpected email links.
2. Revoke and rotate keys. Revoke potentially exposed third-party provider keys at the provider, create replacements and update only trusted integrations that still need them.
3. Review usage and billing. Inspect model/API usage, request logs, account audit events and charges from 16 October onward for unfamiliar requests, spikes or unexpected destinations.
4. Remove excess credentials. Delete unused keys and integrations. Use separate keys for applications and environments, with narrow permissions and quotas.
5. Set alerts. Enable billing and usage alerts where available; investigate changes even if the key remains valid.
6. Preserve evidence. For organisation-managed environments, retain logs and record the time each key was revoked and replaced.

• Use a dedicated secrets manager. Avoid storing long-lived provider credentials in general workspace records when a managed secret store is suitable.
• Restrict retrieval. Encrypt secrets at rest and in transit, enforce least privilege, and record every secret retrieval with a service or user identity.
• Retire credentials with the system. Maintain a credential inventory and verify revocation/rotation when legacy systems are decommissioned.
• Prefer short-lived, scoped tokens. Reduce exposure windows and limit what any one key can access.
• Segment environments. Separate production from legacy services and ensure retirement workflows include validation of access removal and secret deletion.
• Detect anomalous usage. Alert on unexpected provider regions/IPs, request bursts, unusual models, changes in usage patterns and billing spikes.

The supplied sources do not provide public IOC values for this event. Do not invent domains, IP addresses, file hashes or attacker infrastructure from this disclosure.

• The exact technical root cause and initial access vector remain unspecified in the material reviewed.
• The complete number and type of exposed provider keys are not established.
• The number of keys actually used by an unauthorised party is not established.
• The 1.4% figure should not be converted into a numerical user count without a reliable denominator.
• User concerns about charges are not equivalent to a confirmed company finding that the breach caused those charges.
• No named threat actor or definitive TTP set is supported by the supplied sources.

This assessment should be revised if OpenCode or affected providers publish further technical findings, key-use evidence, or a root-cause report.

• Cyber Security News — “OpenCode Security Breach” (18 October 2026)
• ArtificialWatch — summary of OpenCode's 17 October 2026 disclosure
• StepSecurity — incident analysis and response guidance (18 October 2026)
• Safeguard — provider API key rotation guidance (18 October 2026)

These sources are listed in the supplied research document. Claims are attributed to the reporting and vendor characterisation; the article does not imply that all details have been independently verified.

The reported incident highlights a familiar security gap: credentials saved for a legacy system can remain valuable long after the system is on a retirement path. If provider keys in affected workspaces were exposed, the immediate defensive question is not only whether the keys were accessed, but whether they were used, what permissions they carried and whether rotation has been completed.

CRL Assessment: HIGH. The potential impact of API-key exposure can be significant because valid credentials may allow usage or access within their scope. The rating reflects the need for prompt validation and credential hygiene; it does not mean every suspected key was confirmed stolen or abused.