OpenCode Hacked: 1.4% of Users' API Keys Stolen, Racking Up Thousands in Fraudulent Charges

The legacy online system of OpenCode, an open-source AI coding tool, was breached, affecting 1.4% of Console users. Some developers woke up to find their AI service bills had skyrocketed overnight, with amounts ranging from hundreds to over a thousand dollars. This incident exposes not just a security flaw in a single platform, but systemic risks across the entire AI service key management chain.

Incident Recap: Abnormal Bills Overnight

According to security media outlet Hacks.gr, the attack occurred at night and targeted OpenCode Console, an online service where users can store access keys for various AI service providers. The intruders used these stored keys to call APIs, generating unauthorized charges. Developers reported receiving high-charge notifications on social media one after another, with amounts ranging from a few hundred dollars to over a thousand.

OpenCode notified affected users via email the following morning. Co-founder Dax Raad explicitly stated that the open-source application itself and the command-line tool (CLI) were not affected by this incident; the problem was limited to the Console online service.

This distinction is worth noting: the CLI tool and standalone app do not rely on cloud-stored keys, whereas the Console, as a hosted service, centrally stores users' API credentials—making it a prime target for attackers.

API Keys and the Console Hosting Model

An API key is a credential issued by an AI service provider to identify the caller and bill based on usage or authorize access. Unlike account passwords, keys are typically stored in plaintext or encrypted form. Once leaked, attackers can directly call APIs in the victim's name, with charges billed to the victim.

OpenCode Console follows a typical "key hosting" model: developers store keys for platforms like Anthropic, Google, and OpenAI in a third-party online service, which then makes requests on their behalf. This model reduces local configuration costs but also concentrates credentials scattered across various locations into a single high-value target. Once the Console is breached, attackers can gain access to multiple providers' APIs at once without having to compromise each developer's environment individually.

Provider Response: Bans, Refunds, and Collaboration

Anthropic and Google quickly banned keys deemed compromised upon learning of the situation, while OpenAI worked with OpenCode to restore access and refunded usage consumed during the attack. OpenCode stated that refunds for unauthorized charges are being processed.

All three major providers intervened almost simultaneously, indicating that AI service providers' response mechanisms for key leaks are relatively mature. However, for developers, having keys banned also means business interruption—before refunds arrive, they need to cancel old keys and reapply with each provider themselves. OpenCode advises affected users to deal directly with each provider rather than waiting for the platform to handle it uniformly.

Standard Procedure After a Key Leak

Mainstream AI providers typically follow three steps for suspected key leaks: first, revoke or ban the key to stop further abuse; then, assess abnormal usage based on call logs; finally, refund or credit confirmed unauthorized consumption. Anthropic and Google's banning of keys this time is the first step; OpenAI's collaboration with OpenCode to restore access and refund reflects platform-provider cooperation.

For developers, a ban means service interruption, so they need to generate new keys in the provider's backend, update local configurations, and check whether any residual old keys are still usable in other systems. Refunds usually lag behind bans, so developers should not wait for the platform to handle it uniformly but should proactively verify bills and submit appeals.

Investigation Hindered: The Dilemma of AI Safety Filters

A rather ironic twist occurred during the incident analysis. While investigating, the OpenCode team found that AI safety filters refused to analyze dangerous files related to the attack. In other words, the safety mechanisms designed to prevent AI abuse became an obstacle for the security team's forensic work.

OpenCode subsequently obtained access to a special OpenAI project under which models do not refuse such defensive security tasks. This detail reflects a real dilemma in current AI safety policies: overly broad content filtering can inadvertently harm legitimate security research, and how to balance protection with usability remains an unresolved industry challenge.

AI Safety Filters and Defensive Security Research

AI safety filters (such as model-side content moderation layers) are designed to prevent models from generating malicious code, attack payloads, and other harmful content. However, security teams often need to analyze dangerous files left by attackers during forensics, and such requests are easily misclassified by filters as malicious intent and refused.

The special OpenAI project access obtained by OpenCode is a controlled channel for defensive security research, allowing sensitive samples to be processed under supervision. This mechanism shows that the industry has recognized that generic filtering strategies cannot cover all legitimate scenarios and that whitelists, dedicated projects, or manual review are needed to distinguish "offensive abuse" from "defensive analysis." However, the entry barriers and coverage of such channels remain limited, and how to balance security with usability is still an open question.

Key Questions Remain Unresolved

OpenCode has not yet disclosed how attackers gained system access, how keys were stored, or the full scope of key abuse. The company only stated that the situation is still active.

These information gaps are troubling. If there are design flaws in key storage, other AI tool platforms with similar architectures could face the same risks. For developers who rely on third-party platforms to host API keys, this incident raises a direct question: Is it worth the risk to entrust keys to any online service?

Implications for Developers

In the short term, affected users should immediately cancel and replace keys on platforms like Anthropic, Google, and OpenAI, and check bills for abnormal charges. In the longer term, this incident suggests several practical principles: use separate keys for different services and set spending limits; prioritize managing keys in local environments rather than hosting them with third parties; and establish monitoring and alerts for API usage.

The convenience of AI coding tools is built on the free flow of keys, but once keys are centrally stored, they turn from credentials into attack surfaces. The OpenCode incident is limited in scale, but the alarm it sounds applies to the entire AI tool ecosystem.

(This article is based on Hacks.gr reporting and public statements from OpenCode's co-founder; some details await further official disclosure.)

Key Decentralization and the Principle of Least Privilege

The core practice for reducing key concentration risk is "decentralization and least privilege": issue separate keys for different applications or environments to avoid one key leak affecting all services; set spending limits and usage alerts for each key in the provider's backend so abnormal calls can be intercepted before causing large losses; prioritize storing keys in local environment variables or dedicated key managers rather than hosting them with third-party online platforms.

Additionally, keys should be rotated regularly and call logs audited, with immediate revocation upon detecting anomalies. These measures cannot completely eliminate risk, but they can limit the impact of a single-point leak to a manageable scope.

One-line Summary

OpenCode's legacy Console was breached, 1.4% of users' AI keys were abused generating high bills, exposing systemic risks of key hosting.

Paragraph Summary

The legacy online Console system of open-source AI coding tool OpenCode was breached, with 1.4% of users' stored AI service keys stolen by attackers, generating hundreds to thousands of dollars in unauthorized charges. Anthropic and Google banned leaked keys, OpenAI collaborated with OpenCode on refunds, and the open-source app and CLI tool were unaffected. During the investigation, AI safety filters refused to analyze attack-related files; OpenCode eventually gained analysis access through a special OpenAI project. The intrusion method, key storage method, and scope of abuse remain undisclosed, and the situation is still described as active. The incident reminds developers to decentralize keys, set spending limits, and localize key management, and to be wary of the concentration risk of third-party key hosting.