OpenCode Key Leak Triggers Massive API Fraud; 'Distillation Attack' Claim Met with Skepticism

OpenCode's legacy system suffered unauthorized access, resulting in the leakage of API keys for 1.4% of users and triggering multiple high-value fraudulent billing incidents. Anthropic, OpenAI, and Google have urgently revoked some of these compromised keys.

The keys were stored in plaintext within a decommissioned system, lacking least-privilege controls and rotation mechanisms. Attackers exploited the leaked keys to bypass quota limits and execute high-frequency calls. Cloud providers' risk control strategies showed delayed responses to anomalous token consumption.

This article is suitable for SREs/platform engineers, AI infrastructure leads, and security maintainers of open-source projects.

Just this past weekend, while the tech community was celebrating the release of the new DeepSeek-v4.1-Flash-1017 model, a group of developers was shocked by sudden, massive API bills!

In the dead of night, with no high-concurrency tasks running and no stress tests being performed, accounts linked to large language model (LLM) API keys were being aggressively drained of their token quotas by strangers. Once attackers obtained the keys, they ruthlessly continued targeting premium users.

Some developers lost $400 in their sleep; others had their quotas exhausted within hours, causing their Google Cloud production accounts to trigger anti-fraud protocols and suffer complete shutdowns. Victims woke up to face staggering daily bills exceeding $1,700.

Caption: OpenAI spending exceeded $700 in a single day.

Caption: An affected user's OpenCode dashboard shows that their monthly quota has been fully consumed.

This security incident, which quickly gained traction on Reddit, X, and Hacker News, pointed the finger at OpenCode, the popular open-source AI coding tool with over 210,000 GitHub stars.

OpenCode subsequently admitted that a legacy system currently being decommissioned had suffered unauthorized access, affecting 1.4% of cloud Console users. Third-party model API keys stored there may have been leaked. Anthropic, OpenAI, and Google were drawn into the cleanup efforts, with some keys urgently revoked.

OpenCode acknowledged that the incident affected 1.4% of Console users and linked it to a "large-scale model distillation attack." Anthropic, OpenAI, and Google were subsequently involved in remediation, with some keys facing emergency revocation.

But more troubling than the leak itself is that the attacks are continuing.

On October 18 local time, OpenCode co-founder Dax Raad revealed that hackers had been attempting to breach their systems for the past 48 hours. The team worked through the night investigating and hardening defenses, only to encounter another awkward situation: the cutting-edge AI models used for analyzing the attacks began refusing to cooperate due to cybersecurity restrictions halfway through the process. The situation only improved after they gained access to OpenAI Daybreak Blue.

Even more dramatic, Dax’s personal account also became a target. He lamented helplessly on X: "My personal account is now under attack as well. AI-driven hacking is creating a whole new world."

This scene bears a striking resemblance to the investigation experience following Hugging Face's intrusion by an AI Agent a few months ago.

However, more controversial than the ongoing attacks is OpenCode's explanation of the incident. By linking the event to a "large-scale model distillation attack," the official statement sparked skepticism among developers and AI researchers: Why use "model distillation" to explain a security breach where cloud systems were compromised and users' paid API keys potentially leaked?

API Bills Skyrocket

Unlike data breaches in the traditional internet era that merely stole account passwords or dumped user lists, in workflows built around Large Language Models (LLMs), the theft of an API Key is equivalent to handing over an unlimited credit card linked directly to the developer's bank account.

Developers who first publicly shared their experiences on social media documented a harrowing nighttime hemorrhage of funds.

One developer posted backend monitoring logs showing that during a short overnight window, their Anthropic account generated an abnormal bill of up to $400 without any authorization from the owner. Call logs indicated that attackers were making high-frequency concurrent requests to models like Claude 3.5 Sonnet in a short period until rate limits were triggered.

But this was just the beginning. As more victims flooded communities to compare notes, the upper limit of stolen amounts was rapidly updated:

• Another developer using OpenAI models shared their bill, showing an abnormal compute peak exceeding $700 in a single day, with their quota violently drained in an extremely short time;

• A user who had configured Vertex AI credentials on Google Cloud reported that their cloud service API costs surged by over $1,000 within hours. The spike in calls not only exhausted their entire prepaid quota but also directly triggered Google's automated security risk control mechanisms for fraud and abuse, resulting in a system-level emergency suspension of their associated Google Cloud production engineering account;

• The most severely affected victims saw their unauthorized daily call amounts ultimately settle at a painful sum exceeding $1,700.

All victims were looking for common ground among themselves. They had not committed keys to public GitHub repositories, nor had they run any suspicious malicious scripts locally.

The only commonality was: They all used OpenCode, and to synchronize programming environments across devices or collaborate with team members, they hosted their third-party API keys from Anthropic, OpenAI, Google, as well as DeepSeek, Zhipu, and others, in OpenCode's cloud console—OpenCode Console.

Unlike using OpenCode directly on local machines, the Console allows developers to store third-party model API keys in the cloud, centrally manage model calls, and share them with team members without exposing the raw keys to everyone.

On the flip side of this convenience, the credentials for calling paid models became centralized in OpenCode's hands.

These API keys are essentially credentials for accessing paid model services. Without effective source restrictions, call quotas, or spending alerts, once a key is leaked, attackers could bypass OpenCode and send requests directly to model providers like Anthropic and OpenAI.

Hackers do not need to compromise the developer's computer or log into the victim's OpenCode account. As long as they obtain this string of characters remotely, and the requests are not intercepted by the provider's security mechanisms, they can continuously drain the original user's paid quota.

"Model Distillation Attack"? Developers Are Not Buying It

As panic spread the day after the incident, OpenCode officially broke its silence, sending urgent alert emails to affected users and publishing an official statement on the social media platform X.

In the statement, officials acknowledged the existence of a security vulnerability and disclosed that affected users accounted for 1.4% of their total OpenCode Console user base. However, what truly ignited public opinion was the official characterization of the incident's nature—OpenCode claimed the event was related to a "Large-scale Distillation Attack targeting frontier models."

So-called "model distillation" refers to attackers constructing complex prompts in bulk to call industry-leading models (such as Claude 3.5 Sonnet, GPT-4o) to generate massive amounts of high-quality Q&A data, then using these outputs from advanced models as training sets to fine-tune or distill their own low-cost open-source models.

OpenCode's PR rhetoric attempted to convey a subtext to the outside world: This was a highly technical, adversarial scientific theft targeting the cutting edge of AI, and the platform merely unfortunately became a compute springboard for hackers to acquire training data. However, this carefully packaged high-tech narrative was collectively refuted and questioned by Chinese and English tech communities and senior security experts within just a few hours of its release.

Caption: Renowned researcher Nathan also raised objections to the "distillation attack" claim.

Multiple algorithm engineers and security practitioners working on industrial-grade LLM training pointed out that the claim of a "large-scale model distillation" was riddled with flaws in engineering logic:

1. Call Characteristics Completely Misaligned: Industrial-grade model distillation is an engineering pipeline highly dependent on continuity, stability, and structured data throughput. To complete one effective distillation training cycle, it typically requires stable calls generating millions or even tens of millions of high-quality Prompt-Completion pairs.

However, the batch of individual developer credentials stolen by hackers from OpenCode had extremely fragmented quotas. Most accounts would become invalid upon being drained to a few hundred or one thousand dollars due to triggering credit card limits, insufficient account balances, or manual cutoffs by users. No mature algorithm team would dare to build core data pipelines on these scattered credentials that could expire at any moment. 2. Credential Theft is the Essence; Distillation is Just Downstream Monetization: The tech community incisively pointed out that regardless of whether attackers use the stolen Keys for model distillation, generating spam, hooking up automated penetration testing, or reselling them in dark web API proxy pools for cash-out, the underlying nature of this incident remains singular—Credential Theft.

Naming the potential downstream data usage directly as the attack type bears the hallmarks of a PR strategy designed to deflect attention and use cutting-edge concepts to hedge against the company's own security responsibilities.

More critical technical details were subsequently exposed: In the security notification sent to affected users, OpenCode admitted that the attacker's entry point was not some obscure zero-day vulnerability (0-day), but rather "a legacy system that was in the process of decommissioning."

This exposes a critical vulnerability in the cloud infrastructure security lifecycle. A deprecated service, which should have been completely isolated and taken offline, remained exposed on the public internet due to a lack of operational oversight. Even more absurdly, this system slated for decommissioning retained high-privilege read access to the production Secrets database—the credential store containing users' plaintext or weakly encrypted API keys.

Hackers didn't even need to breach robust modern defenses directly. They simply found an old side door that the team forgot to lock, effortlessly draining the "wallets" of thousands of developers.

48 Hours of Offense, Defense, and Aftermath

If the focus during the first two days was on key leakage, the latest developments have shifted toward continuous cyber offense and defense.

On October 18, OpenCode co-founder Dax Raad publicly spoke again, revealing that attackers had relentlessly bombarded OpenCode's systems for a full 48 hours without pause. Facing such high-frequency attacks, he lamented: "Defenders must now also deploy AI Agents working 24/7, because attackers are already doing so."

However, in this battle of AI versus AI, the OpenCode team encountered an extremely awkward situation. Developer Rhys Sullivan asked Dax on social media: "When you were using frontier models to investigate, did their cybersecurity safeguards block you?"

Dax confirmed it. He admitted that halfway through the incident investigation, this became deeply frustrating—after the commercial frontier LLMs used by the team assisted with partial log and code analysis, they suddenly triggered built-in safety guardrails upon encountering numerous vulnerability signatures and attack payloads in the context, strictly deeming the content violating and refusing to process subsequent requests.

This wasn't the first time defenders were "disarmed" by their own AI tools.

In July of this year, the open-source AI community Hugging Face disclosed a security breach driven by AI Agents. In its post-incident technical report, facing over 17,000 attack records, the security team similarly used AI Agents to reconstruct the attack path but was repeatedly blocked by frontier models' safety interception mechanisms. Ultimately, they had to introduce the open-source model GLM 5.2 to assist in completing the log reverse-engineering.

While these two incidents differ technically, they jointly expose a real-world paradox of generative security: When genuine cybersecurity investigations require dissecting attack payloads, the general-purpose safety guardrails of large models often fail to distinguish friend from foe, effectively handcuffing authorized defenders instead.

For developers who suffered actual financial losses, there is only one core question: Can the stolen funds be refunded?

A turning point emerged first on the OpenAI side. Just recently, Tibo (@thsottiaux), a member of the OpenAI security team, publicly confirmed via a post that the OpenAI team has collaborated with OpenCode. Not only did they help affected OpenAI API customers restore business operations, but they also announced full refunds for all credits and compute quotas abnormally deducted during the attack (credits refunded)!

Caption: OpenAI team member Tibo confirms intervention in the aftermath, promising full refunds of quotas stolen from affected users during the attack, and urging defenders to apply for Daybreak Blue permissions early.

This drama of offense and defense, lasting dozens of hours, serves as a heavy alarm bell for all developers using LLM tools:

Handing over your API Key to third-party AI tools isn't just granting permission for code completion; it's issuing an unlimited authorization directly linked to your personal credit card, capable of generating substantial charges at any moment. In an era where centralized tool platforms cannot yet provide financial-grade isolation protection, the most prudent security strategy remains simple: Do not casually entrust your API Keys to any third-party cloud console. If it can stay in local environment variables, do not upload it to the cloud.