deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

OpenCode breach may have exposed OpenAI and Anthropic keys for 1.4% of Console users

OpenCode says unauthorized access to a legacy system may have exposed OpenAI and Anthropic keys stored in Console workspaces, and has told the 1.4% of affected users to revoke them.

OpenCode breach may have exposed OpenAI and Anthropic keys for 1.4% of Console users

OpenCode discloses breach tied to a legacy system

OpenCode has told users of its hosted Console product that third-party API keys stored in their workspaces, including OpenAI and Anthropic credentials, may have been exposed to an intruder. According to a report on dev.to, affected users received an email on October 17 with the subject line "Action Required: Potential provider key breach," which said OpenCode had identified unauthorized access to a legacy system it was in the process of decommissioning.

Security researcher Matt Johansen publicized the email on X at 15:30 UTC that day, and OpenCode confirmed the incident on X at 18:08 UTC, describing it as a breach connected to what it called a large-scale distillation attack. The company put the impact at 1.4% of Console users, limited to those who had linked external providers to a workspace. Per dev.to's summary, OpenCode says it emailed everyone affected, so anyone who did not receive the message was not part of the incident.

What OpenCode has confirmed and what it hasn't

Collected by dev.to, OpenCode's statements so far say the breach hit a legacy system already slated for retirement; that third-party provider keys saved in a workspace may have been exposed, with OpenAI and Anthropic named as examples; that it is working with Anthropic, OpenAI and Google on remediation; and that the incident is still ongoing, so it cannot share further details.

What is missing: how many accounts 1.4% represents, how the attacker got in, how long the access lasted, and whether every stored key was actually taken. dev.to notes that OfficeChai has observed no technical details have been released, and that Runtime Wire argues the 1.4% figure does not by itself measure either exposure or loss. Crypto Briefing reports that some affected users describe bills running into the hundreds of dollars, which are user reports rather than company figures, and it is unclear how those charges will be handled. OpenCode co-founder Dax Raad posted at 18:41 UTC that his personal accounts were also being attacked.

The distillation label

OpenCode chose the term. The dev.to post points to Anthropic's own writing on the topic: distillation means training a less capable model on the outputs of a stronger one, and an October 12 Anthropic post said distillers have relied on proxy networks spanning enormous numbers of fraudulent accounts. The dev.to author offers a hypothesis that OpenCode has not confirmed: a stolen provider key is essentially free frontier-model output billed to somebody else, which would explain both the label and the reported charges. Until a post-mortem lands, that remains informed speculation.

Workspace keys, not local CLI keys

The scope appears limited to keys saved in hosted workspaces. OpenCode's Console documentation, as described by dev.to, lets a workspace connect provider accounts a team already pays for and stores the credential centrally so members can use the models without handling the raw key. That is the standard gateway trade-off: teammates never see secrets, but the gateway holds a live key that bills the team's card, and every system that ever touched it, including one on its way out, becomes part of the attack surface. OpenCode's CLI separately stores keys added locally on a user's own machine; the company has said nothing about those in this incident.

Steps for affected users

OpenCode's email asks recipients to revoke and replace keys through each provider's dashboard, update any applications using them, and review recent usage for unexpected activity. dev.to adds operational detail: Anthropic's guidance says a possibly compromised key should be revoked immediately; for Gemini, Google's documentation says to create the replacement in AI Studio first, then disable the leaked key; and a dead key can be verified because providers return HTTP 401 for revoked credentials. The post also recommends auditing usage back to at least October 16, and further back if provider logs allow, since OpenCode has not said how long the intrusion lasted. Anyone who did not receive the email but stored keys in a workspace anyway can rotate them in a few minutes while the investigation is open.

Why it matters

This is a concrete credential-exposure incident at a tool many developers trust with billable API keys, and it exposes the weak point of the gateway model: a system slated for decommissioning was still holding live credentials. For the affected 1.4%, the exposure is potentially a direct cost, with user-reported charges already in the hundreds of dollars and no word yet on reimbursement. The broader lesson applies to any console that asks you to paste a provider key: give each service its own key, put a spending ceiling on it, restrict it to the narrowest API scope the provider offers, and know what normal usage looks like per key, because a request to review usage for unexpected activity only works if you have a baseline to compare against. The distillation framing also hints at a motive that goes beyond simple key resale, though OpenCode has yet to publish the details that would settle it.

  • #security
  • #api-keys
  • #opencode
  • #ai-coding-tools
  • #developer-tools

Related posts