OpenCode has disclosed a security breach. In a public statement the company said the incident happened last night and was related to a large scale distillation attack that impacted 1.4% of OpenCode Console users. Affected users were notified by email the following morning. The post was shared on Hacker News and links to the company's own account.
What happened
The company reported a breach overnight and put a figure on the blast radius: 1.4% of OpenCode Console users were impacted. It said all of those users were notified by email that morning.
We had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users
The company also said it is working with Anthropic, OpenAI, and Google to remediate. No further technical detail has been published.
How it was done
The mechanism has not been explained. The only description given so far is that the breach was related to a large scale distillation attack, and the company stated that the incident is ongoing so it cannot share more details at this point.
That means anyone reading this should treat the method as unknown. The useful response is not to model the specific technique, but to assume credentials held in or used by a developer console could be exposed and to work from there.
What to check
If your teams use a hosted coding console or route model traffic through one, these are reasonable things to verify today.
Confirm whether your accounts were notified
Search your corporate mail gateway for messages from the vendor domain to your engineering and billing addresses, including quarantined mail. Check shared inboxes and aliases used for signups, not just individual accounts. An unread notice sitting in a role mailbox is a common gap.
Rotate provider API keys used by the console
In each model provider dashboard, issue new keys, update your secret store, then delete the old ones rather than leaving them disabled. Confirm the old key identifiers no longer appear in request logs after the cutover.
Review usage and billing for anomalies
Pull per key usage by day and by model from each provider console and compare against your own request counts. Look for sustained high volume calls, unfamiliar models, or traffic outside your deployment regions and working hours.
Audit console session and member access
Open the organisation members and sessions pages, revoke active sessions, and remove accounts that no longer need access. Flag any member added recently that no one can account for, and enforce multi factor authentication where it is available.
Find keys that live outside the secret store
Run a secret scanner such as gitleaks or trufflehog across repositories, container images and CI configuration. Grep build logs for key prefixes. Any hit means rotation alone is not enough, the storage path needs fixing too.
Watch for follow on phishing
Breach notices attract imitation. Tell staff to reach the vendor through a bookmarked URL rather than links in mail, and add detection rules for lookalike sender domains in your mail filter.