OpenCode Console breach: rotate your LLM provider keys
What was reported about the OpenCode Console breach, how to rotate the keys it touched, and how to cap the damage when any tool that stores a key is breached.
Founder, Newly
Published Last updated
If you stored an OpenAI, Anthropic or Google API key in the OpenCode Console, create a new key, switch to it, revoke the old one at the provider, then read your usage for unexplained spend. BleepingComputer reports that 1.4% of Console users were affected. The same steps apply to any tool that holds a copy of your key, including the ones you built.
What was reported about the OpenCode Console breach?
OpenCode is a coding agent. Its Console is a hosted account area where users can store provider API keys. The facts below come from BleepingComputer's report, checked on 24 October 2026. We did not find an advisory on OpenCode's own website, so every row is press-reported and the project's statements are relayed through that report.
| Item | What the report says |
|---|---|
| Earliest exposure | 17 October 2026, 00:30 UTC |
| Duration | At least 48 hours |
| Announced | 19 October 2026 |
| Who was affected | 1.4% of Console users, per a project maintainer statement |
| What was exposed | Provider API keys stored in the Console, including Anthropic, OpenAI and Google keys |
| Reported effect | User-reported charges from several hundred dollars to about $1,700 overnight; Google suspended some affected projects |
| Vendor response | Working with the three providers; possible reimbursement mentioned in the notice to affected users |
| Not stated | How the keys were stored, how the attacker got in, and whether any key was used before 17 October |
What this page does not claim
We cannot confirm from a primary source how the keys were stored, the cause, or the scale beyond the percentage above. If your account was affected, OpenCode's notice to you is the authority. The steps below do not depend on those details.
Why does a stored key matter to someone building an app?
An AI provider key is a bearer credential. Whoever holds the string can make requests that are billed to your account. It carries no username and no second factor, so a copy in the wrong place is the whole problem. OWASP's Mobile Top 10 lists hardcoded credentials as an easy access point for attackers and advises rotating API keys regularly.
App builders usually have more copies than they remember. Newly builds a real iPhone and Android app with React Native and Expo, and you can download the code or connect your own repository. Wherever you build, the key can end up in the places on the diagram.
Copy 3 is the one you can fix at the source. Expo's docs say EXPO_PUBLIC_ variables are visible in plain text in your compiled application. Google's Gemini docs give the same advice for mobile apps: run a backend proxy instead of shipping the key.
The budget angle matters too. OWASP lists unbounded consumption among its LLM risks, with economic loss as one outcome. A leaked key with no cap is that risk in its simplest form.
How do I rotate my provider keys in an hour?
Order matters. Create the replacement first so your app keeps working, then revoke. OWASP's secrets management guidance lists the sequence as revocation, rotation, deletion from systems and logs, then logging for the incident record.
- List every key and every place it lives (the first self-test item).
- Create a new key at the provider, with the same restrictions.
- Put it in your server or secret store, not in the app or the repository.
- Redeploy, and confirm the app works with the new key.
- Revoke or delete the old key at the provider.
- Read usage and billing for the period the old key was live.
| Provider | What its docs say to use | What to look for in your account |
|---|---|---|
| OpenAI | Keys in environment variables or a secret manager; set an expiration date on project keys and keep a regular rotation process | The Usage page, once tracking is enabled, for spend you did not cause |
| Anthropic | Keys can be scoped to one workspace; each workspace can have its own spend and rate limits | The Usage page by workspace. The Default Workspace cannot carry a spend limit, so use a named workspace |
| Google Cloud | Application and API restrictions on every key; to rotate, create a new key with the same restrictions, update apps, then delete the old one | Billing and API usage logs for the project, and any project suspension notice |
Google's Gemini guidance adds one detail: disable the old key only after the new one is verified, so you do not cause downtime. A usage page that looks ordinary proves little, because a stolen key can be used lightly. If you cannot account for a key's history, treat it as exposed.
If a key reached your repository, rotation does not erase it from history. Red's rotate secrets after a breach guide covers the wider list of credentials to replace, and the website incident response playbook covers what to record while you do it.
How do I limit the damage when a tool that stores keys is breached?
You cannot stop a third party from being breached. You can decide what a copy of your key is worth when it leaks. The table compares where the key lives with what a leak gives someone and the control that shrinks it.
| Where the key lives | What a leak gives | Control that shrinks it |
|---|---|---|
| A third-party tool's account | Full use of the key until you revoke it | Use a key made for that tool only, with its own spend limit; revoke it when you stop using the tool |
| The app bundle | Anyone who installs the app can read it | Move the call to a server; add per-user limits there |
| The repository or its history | Everyone with read access, now and later | Turn on secret scanning and push protection if you host on GitHub |
| Your server's environment | Whoever gets into the server or its deploy settings | Separate keys per app and environment; a spend limit at the provider; an alert on unusual use |
Two controls apply to all four rows. First, set a provider spend limit below what you could afford to lose; Anthropic's documentation describes a user-set limit below the tier cap. Second, split keys so one leak does not end every app you run.
If your app has an AI feature, remember who spends. AI inside a Newly app uses credits, and some features have limits. A key you supply for your own server carries its own bill, so limit calls per signed-in user on that server. The chatbot self-test and the 15-minute app check walk through both.
Finally, look at your own domain from outside. Bots probe for files such as /.env; Red's 30-second check for .env and .git requests shows what to look for. Back on the security hub you can find the rest of this series.
Where do you stand?
Every item starts as unknown. Move it to detected when you find the problem, and to confirmed only when you hold the evidence listed under it. A tool's own dashboard saying a key was deleted is not evidence; the provider's key list is.
Your provider-key check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Do I need to rotate my keys if I never used OpenCode?
Not because of this incident. The reports concern keys stored in the OpenCode Console. The same reasoning applies to any tool that holds a copy of a provider key for you: if you cannot say who can read that copy, rotating is cheap and ends the question.
Is deleting the key from the tool enough?
No. Deleting a copy in one tool does not disable the key at the provider. Create a new key, switch your app or server to it, and revoke the old key in the provider's console. Revoking is the step that makes a leaked copy useless.
How do I know if my key was used by someone else?
Read the provider's usage and billing pages for spend you did not cause: new models, odd hours, a jump in volume. A quiet usage page proves little, because a stolen key can be used lightly. Treat a key you cannot account for as exposed and rotate it.
Can a spend limit replace rotation?
No. A spend limit caps the bill, so it limits the cost of a leak. It does not stop someone using the key until the cap is reached, and it does not remove their access to anything else the key can do. Use both.
Should the AI key be inside my mobile app?
No. Anything compiled into an Expo or React Native app can be read by whoever installs it, and Expo's docs say so for EXPO_PUBLIC_ variables. Keep the provider key on a server you control and let the app call that server after checking who is signed in.
Does the free scan tell me whether my key leaked?
It can report API keys and tokens it finds in the bundles your live site ships, and exposed .env files. It cannot see a key held inside a third-party tool's account. That part is yours to check with the provider.
Sources
All pages checked on 24 October 2026.
- OpenCode hack exposes API keys amid AI distillation attacks, BleepingComputer
- Production best practices, API key safety, OpenAI developer docs
- Rate limits and spend limits, Anthropic Claude docs
- Workspaces, Anthropic Claude docs
- API keys, Google Cloud docs
- Using Gemini API keys, Google AI for Developers
- Secrets Management Cheat Sheet, OWASP Cheat Sheet Series
- LLM10:2025 Unbounded Consumption, OWASP GenAI Security Project
- M1: Improper Credential Usage, OWASP Mobile Top 10
- Environment variables in Expo, Expo docs
- About secret scanning, GitHub docs
- About push protection, GitHub docs