Rendered at 16:33:21 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
redsymbol 18 hours ago [-]
To clarify something that the OpenCode team has done a bad job of clarifying:
The leak was for something called 'OpenCode Console', which is distinct and separate from the OpenCode coding agent. If you're just using the coding agent, you're not affected. 'OpenCode Console' is a service that is similar to OpenRouter, but is much less widely used.
The name 'OpenCode Console' is super confusing, because one might think it means the CLI coding agent. It does not. 'OpenCode Console' has nothing to do with the CLI/TUI coding agent, nor the desktop app version.
The situation is made worse by the fact that 'OpenCode Console' barely has any documentation online, and the official leak announcement does not make the distinction clear at all. The OpenCode team did a terrible job of communicating this, and that's on them.
Today is a bad day for people using 'OpenCode Console'. But most people, probably the vast majority of OpenCode users who are reading this, are not using 'OpenCode Console'.
wren6991 14 hours ago [-]
As a philosopher^H person on twitter once said: "If you find two ants in your kitchen, the best estimate of the total number of ants in your kitchen is not two." OpenCode has some pedigree here.
jerieljan 15 hours ago [-]
Yeah, it's very confusing especially if you're not in the loop and their docs were only updated recently and was confusing during the v1 -> v2 transition weeks / months ago.
So far, "OpenCode" has gone through several possible definitions:
- OpenCode Terminal / CLI - This is what you get normally. Runs a service in the background and the CLI is your interface.
- OpenCode Desktop - Instead of a CLI, you get a desktop interface.
Most users usually stop here. You just install the app and you connect wherever.
So there's the services where they both make money and make things easier for users:
- OpenCode Console - Basically the serving platform for both Zen and Go, and has expanded to a hosted inference gateway and somewhat similar to OpenRouter or a managed LiteLLM. Has the option to BYOK if you have existing AI platform accounts so it charges those instead of Zen, and that's what got compromised.
- OpenCode Zen - the API service they host if you want to get access to providers but don't want to pay individually per API platform. Similar to OpenRouter. I noticed they're kinda slowly dropping the Zen moniker.
- OpenCode Go - the subscription service that they host that features open weight models and select low-cost models from frontier labs. Has different policies when it comes to privacy and retention compared to Zen.
- OpenCode Black - a limited-time, limited access subscription service that grants access to frontier models. Not sure if this is still alive or not.
john01dav 17 hours ago [-]
I thought that the many provider pay as you go product from OpenCode was Zen. Also, how does OpenCoe Go fit into this?
redsymbol 17 hours ago [-]
No, Console is different from Zen (and from Go). But you are reasonable in asking about it. The opencode team has done a horrible job of communicating what's actually going on. They have suffered real brand damage from this, and they deserve it.
PalmPilotProMax 15 hours ago [-]
But what about Open Code Pro Max?
Or Open Code Rust?
17 hours ago [-]
pranshuchittora 17 hours ago [-]
NNN... trust is already broken
pranshuchittora 22 hours ago [-]
I am the author of this post. Looks like OpenCode fans / team is not happy with this post coming on the first page of HN. It has already been flagged by many.
I never ask for upvotes, but would be great if you can upvote it.
Thanks!
Thanks for the detailed metrics. This proves my point...
qsod 20 minutes ago [-]
[dead]
xendo 20 hours ago [-]
It's clearly heavily down voted, just look at when it was added, how many points it has and its relative position.
throwoutway 19 hours ago [-]
You cant downvote HN posts (comments you can)
an0malous 19 hours ago [-]
They presumably meant that it’s been downranked relative to what you’d expect from a post with that many upvotes in that short of a time frame. Hundreds of upvotes in a few hours is usually a top 5 post
Afaik flagging acts like a super-downvote as far as the algorithm is concerned
xendo 6 hours ago [-]
One of my page was 2nd on the main page trending towards 1st, a single flagging pushed it to the middle of the second page.
pranshuchittora 18 hours ago [-]
Yes flagging is super downvote
pranshuchittora 21 hours ago [-]
The post was visible when I am logged in. But when I opened the /newest page on incognito the post wasn't there.
senordevnyc 21 hours ago [-]
It’s #14 on homepage when not logged in, same as when logged in.
pranshuchittora 20 hours ago [-]
Now it is
senordevnyc 14 hours ago [-]
lol, I posted eight minutes after you
alfiedotwtf 15 hours ago [-]
I don’t get why there would be an onslaught of downvotes?
ryandrake 17 hours ago [-]
Pretty pathetic if true. Imagine if they spent as much effort securing their systems as they spend brigading and astroturfing after getting 0wned.
trollbridge 21 hours ago [-]
Then next time do a less clickbait-y title: OpenCode had a leak of API keys for their service that is similar to OpenRouter; this does not affect most users.
tekacs 19 hours ago [-]
It's a little more than that. It seems that keys for OpenAI / Anthropic APIs that were STORED on OpenCode's OpenRouter-like backend got leaked – which additionally means that OpenCode has no ability to refund people for their losses.
cassianoleal 18 hours ago [-]
> which additionally means that OpenCode has no ability to refund people for their losses.
If they took payment, they are liable and they must have the ability to refund.
pranshuchittora 17 hours ago [-]
I guess Anthropic and OpenAI might refund based on good will.
tekacs 17 hours ago [-]
... no, I don't think so? Taking payment for <X> (providing a proxy/platform for hosting/proxying to agents) doesn't mean that you're inherently liable for <Y>, if <Y> is 'bring your own key from a third-party provider'.
pranshuchittora 17 hours ago [-]
Agree, they won't refund. But they might if the total damage is < $100K
Ciantic 22 hours ago [-]
I think every API key system should have endpoint "invalidate_api_key" this way whitehat hackers or the party who stored them could invalidate all keys in the case they leak. Now it is race against the time, and everybody got email, and everyone must act themselves.
Tiberium 22 hours ago [-]
It actually is a thing, although indirectly in a hacky way! If you push keys from GitHub secret scanning partners to a public repo or a gist, they get sent to the partner who (usually) instantly revoke them. So if you want to help someone, just make a public gist with the key and delete it like 15 seconds later, it'll be enough.
Only responsible thing in this case would have been for OpenCode people to invalidate all keys. But I guess it is not that straightforward if Anthropic/OpenAI etc don't have endpoint for it.
ameliaquining 21 hours ago [-]
There's no self-serve endpoint, but OpenCode could send the inference providers the leaked keys and ask for them to be revoked, which is a thing the inference providers can do. It's possible that this'll happen, apparently remediation is still in progress.
weknowbetter 11 hours ago [-]
FWIW they invalidated my key in the middle of a session this morning.
orf 20 hours ago [-]
That just turns a credential leak into a denial of service - one that can be triggered from anywhere.
shepherdjerred 19 hours ago [-]
In this case you'd probably prefer your key to be disabled rather than spending $$$ on tokens for everyone else
orf 19 hours ago [-]
Think that through - the person who stole the key has the decision to use it or revoke it through this hypothetical system.
If they are acting maliciously, they will take the choice that most hurts you and/or benefits them.
If the key is useless to them and revoking it hurts you, then they would do that.
If the key wasn’t useless to them, then… they would just use it and not revoke it?
asdfaoeu 18 hours ago [-]
It for whitehat third parties who discover unprotected keys obviously people intentionally stealing keys will not revoke them generally.
orf 18 hours ago [-]
And the whitehack hackers finding keys should do what, exactly?
Unilaterally decide they should be revoked, without contacting the owner?
And that’s not malicious?
drawfloat 10 hours ago [-]
Given they found a secret key in a public place? No that’s not malicious and it would be odd for a serious organisation to be upset someone immediately invalidated it.
orf 8 hours ago [-]
Are you really unable to imagine a situation where financial or physical harm is caused by a system abruptly being shut down by a credential revocation, triggered by a random person on the internet?
Be serious.
drawfloat 4 hours ago [-]
Other options available: ruin the company financially, violate the terms of service of whatever system it uses and get the organisation banned, access business/customer data.
If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience.
orf 3 hours ago [-]
This is so stupid. It’s pretty simple: malicious actors will use it to do all of those, plus now they can unilaterally bring down a system via revocation.
Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act.
That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak.
GoblinSlayer 6 hours ago [-]
Is that system made by a supervillain or a mad scientist? But such system can go amok for any reason. Anyway revocation is already possible by publication on github, telling to GPT or sending an email to webmaster.
orf 6 hours ago [-]
Credentials published on GitHub are not automatically revoked - what happens is at the discretion of the provider, for precisely this reason.
For example AWS applies a “quarantine” policy that prevents some specific actions[1].
Allowing anyone to report a potentially compromised key is one thing, but allowing anyone to unilaterally revoke a token is another.
The alternative is that the key won't be quarantined and the attacker will be able to do everything. And quarantine still means denial of some service, e.g. ec2:StartInstances is denied, but ec2:StopInstances is allowed? So the attacker can shut down the system and you won't be able to start it again?
shepherdjerred 14 hours ago [-]
What exactly are you advocating for
orf 8 hours ago [-]
Read the thread?
> I think every API key system should have endpoint "invalidate_api_key"
Not this.
shepherdjerred 60 minutes ago [-]
Yes, so you are against the proposed idea.
What is your alternative idea?
No idea why you’re being so hostile here.
orf 57 minutes ago [-]
Can you point me to where I said I had an alternative? Or any rules that say you can’t discuss an ideas flaws if you don’t immediately have an alternative?
The status quo is clearly the local minima, given the myriad of trade offs and different parties involved.
flaunf221 19 hours ago [-]
Not any more than any other public endpoint service exposes.
This revocation endpoint can be protected by auth too. Use API key that you're revoking in auth.
orf 19 hours ago [-]
How does that make any sense?
flaunf221 19 hours ago [-]
I see now from another comment you thought about denial of service for service that leaked key. And I thought about mass leak resulting in DDOS onto API provider. Wrong guess from me.
max__dev 19 hours ago [-]
Yes. Is this a bad thing?
orf 19 hours ago [-]
Of course it is? A key for some weather API getting leaked isn’t the end of the world, but having it revoked and breaking your weather app is.
computerex 21 hours ago [-]
Why are my API keys in the workspace exposed? Does OpenCode send my API keys to their backend servers??? Was this a supply chain attack that infected the opencode program itself? What is going on?
ameliaquining 21 hours ago [-]
If you use the hosted OpenCode Console and bring your own API keys, then they'd have your keys on their backend servers.
InsideOutSanta 20 hours ago [-]
The announcement is needlessly confusing, but if you only use the CLI, you're not affected. There is no supply chain attack.
NewsaHackO 14 hours ago [-]
Do you work for OpenCode? How do you know this? Every similarly sized start up would have added the statement “OpenCode Desktop users are not affected.” The fact they didn’t means they can not definitively rule that case out. It would be prudent to rotate out your third party keys in this situation, especially if it is a API key with a high drain limit.
InsideOutSanta 8 hours ago [-]
> How do you know this?
It's in their announcement; it's just not written in a way that people immediately understand.
pranshuchittora 21 hours ago [-]
They need to explain this, by releasing a detailed RCA.
verdverm 15 hours ago [-]
It sounds like most users are not affected (zen | go), and that if you are, you would have received an email. Check your OpenAi and Anthropic account for usage that was not yours.
Run a gateway like GoModel instead of uploading your keys to a vendor to prevent this class of attack in the future.
Is my understanding correct that this only affected some OpenCode Zen users who stored their (BYOK) API keys from Anthropic/Google/OpenAI?
In essence they used OpenCode Zen similar to OpenRouter, where you can BYOK or use theirs and be charged token rates.
nightpool 21 hours ago [-]
That's the only known impact so far. But we don't know the details of how these keys were exposed, so it's not entirely clear why or how "only keys" might have been affected
jchw 22 hours ago [-]
I don't use OpenCode but I would like to know who this impacts. Surely people who are just using OpenCode locally with their own credentials wouldn't be impacted, right? This sounds like something where you have a hosted service and you put your keys into that. Not saying this isn't bad, but it isn't clear and they're not sharing any information.
hahajk 21 hours ago [-]
This appears to affect users of Opencode Console, which appears to be an Openrouter-type thing?
> If you’d like easy access to all the best coding models you can try out OpenCode Console.
neya 21 hours ago [-]
Turns out even if you used credentials locally, you could've have been impacted as the .env files were also consumed by the agents. This is from some comments on Reddit / Google, so take it with a grain of salt.
rozenmd 19 hours ago [-]
@dang this title needs updating: "OpenCode Console hacked: User credentials leaked"
The opencode CLI has no impact.
Rapzid 19 hours ago [-]
It doesn't say the CLI was hacked does it?
qlte 19 hours ago [-]
OpenCode = OpenCode CLI to most people (as seen in the dozens of comments making that assumption in this thread)
Rapzid 14 hours ago [-]
That's fine but there are other apps and services under the "OpenCode" product umbrella; collectively and collequially they are "OpenCode" and the project is "OpenCode".
Headlines are designed to capture attention and readers, how much detail does it need to go into? It's not dishonest or misleading but yes it's attention grabbing.
NewsaHackO 17 hours ago [-]
OpenCode is the name of the company though.
verdverm 16 hours ago [-]
The company name is Anomaly, seems they had a namesake
19 hours ago [-]
fleshers 22 hours ago [-]
I’m a bit confused by the wording here, does it mean the credentials were hacked and then used to perform a mass distillation campaign?
pranshuchittora 22 hours ago [-]
It triggers me when these companies think that users are fool. I would have appreciated them, if they have disclosed things more transparently.
ipsum2 22 hours ago [-]
"mass distillation campaign" there's no public evidence of this. I wonder what OpenCode/Anomaly has, would be an interesting postmortem.
verdverm 15 hours ago [-]
They do have Anthropic and OpenAi as vendors, who are at the center of this hack as well, and who have been beating the "distillation attack" drum on a regular basis.
OpenCode, and the lot, will need to release an open, public, dataset containing the original queries (and other relevant details) that the hacked keys were used for. I'm unwilling to trust those industry players at their word. We need to do our own community analyses.
vdfs 21 hours ago [-]
Obviously they don't want to share details because it's ongoing
NewsaHackO 17 hours ago [-]
If OpenCode is not releasing all of the details about the exposure at the moment, it likely would be a good idea to rotation keys for the connected services at this point
verdverm 15 hours ago [-]
We don't yet know what the hacked api keys were used for. We would need grand transparency, like an open dataset with the original queries, so that the public can validate through a collaborative effort. I'm not keen to accept their early conclusions, eventual RCA summary stats, or METR reports.
22 hours ago [-]
odo1242 22 hours ago [-]
Yes
pranshuchittora 22 hours ago [-]
[dead]
monster_truck 21 hours ago [-]
Wait, is the openchode hack the cause of all the people complaining about their OAI usage getting drained/vanishing at alarming rates? That's pretty funny ngl.
The way some of this place's employees post and act online, can't say I feel all that bad.
It sounds like only a hosted service was compromised, not the open source OpenCode binary that users run on their own machines. So this wouldn't explain that.
verdverm 16 hours ago [-]
They have multiple online platforms, reading other comments, this looks to be the BYOK system where you upload keys to other vendors, as compared to Go, where you can generate API keys for your $10 sub
run a gateway like LiteLLM or GoModel, don't upload keys to a vendor
So are people going to wake up and see their Anthropic, openAI, etc accounts drained?
jprokay13 20 hours ago [-]
I saw the email this morning from OpenCode about my key being compromised alongside an email from Anthropic stating that I used up my $20 in API credits for the month. I hope they built something cool with those tokens!
NewsaHackO 17 hours ago [-]
Probably another tool help steal more tokens. Or to probe more controversial topics without fear of getting banned. Would you be able to check in the history of what they made?
AmazingEveryDay 17 hours ago [-]
I'd like to know also - don't fully understand api, tokens stuff. Can user get log of what the (stolen or not) tokens were used for? Or that just kept by the provider in secret
verdverm 14 hours ago [-]
In this specific incident, users should be able to see the history of queries for their own keys, in both OpenCode Console and their Ant/Oai accounts. All three companies have this audit feature in their respective consoles.
I would like to see the companies release an open dataset of the attackers queries, such that we can do our own analyses as a community. Public trust is in the xitter with these folks.
pranshuchittora 21 hours ago [-]
Yes
thway15269037 21 hours ago [-]
Was it opencode who bragged about their vibecoding tokenmaxxing attitude or I'm mixing them with someone else?
verdverm 16 hours ago [-]
yup, in working through a major security regression in the CLI with them this week, our gut feeling is that they did too much eyes and thinking free coding, trusting the ai output that their new design, was good, twice. It took a couple of iterations to get it in a better place.
you can learn more from here, they did handle that one much better, all-in-all
Honestly, who isn't bragging about their vibecoding tokenmaxxing attitude nowadays?
mikalauskas 11 hours ago [-]
Reading their discord some time ago I was considering to be come a customer but changed my mind after reading that they have no customer service and didn't resolve issues with a user (billing issues).
zephiel7 18 hours ago [-]
They had it coming for too long. Playing the "open and free" card while keeping your API token on server (among so much else)
pranshuchittora 20 hours ago [-]
Awaiting for detailed breakdown of the incident. I am more interested in knowing , how can a distillation attack leak / expose credentials.
Flere-Imsaho 18 hours ago [-]
No I think they used the stolen API keys to perform distillation.
verdverm 15 hours ago [-]
We don't know what the stolen keys were used for, that will require real transparency on OpenCode's part, like an open dataset of the original queries, so we can do our own analyses into the nature.
I would recommend running your own gateway instead of uploading keys to a vendor. My gateway of choice is GoModel
It’s fascinating that tokens are so valuable that people are spending so much time and effort hacking to obtain API keys.
nacs 21 hours ago [-]
They might have spent next to 0 time actually 'hacking' - they may have just told Opencode to hack Opencode website and let it run for hours or days till it succeeded.
qlte 19 hours ago [-]
API keys have been routinely stolen in mass automated attacks for malicious usage long before LLMs even existed
If the keys were used for a black market resell, the model is less important and all tokens would have been valuable, but certainly more expensive tokens earn the hacker more money over the same time frame.
tonymet 17 hours ago [-]
My understanding of the lingo, in layman's terms:
Hackers breached an Open Code legacy system containing customer keys for openai etc, and ran up large bills against the customer's openai accounts . The tokens were used to train the hacker's ai models (the distillation).
My guess is a more primitive arbitrage / resale attack . Like reselling EBT cards or "free" vpn traffic.
drewfax 15 hours ago [-]
Can someplease explain what is a distillation attack?
verdverm 15 hours ago [-]
A "distillation attack" is when someone tries to extract training data from a closed source model through the API of the Big Ai labs. Frontier model traces can be used to train other models with less effort. We don't use the word "attack" when a company does this with their own models or when we use open weights as the teacher model. This is often used to help train flash and smaller models from the mega models. The technique is used widely throughout industry.
We do not know if that is what the hacked API keys were used for. Could be distillation, could be API reselling. We will need more transparency into the nature of the requests made by the attacker. I would like to see an open dataset of the queries made with the compromised keys. All of them as originally made, not aggregate stats or another METR report.
The keys could have also been used to resell API access on the black market, again, we need good transparency to know. Considering the upstream parties involved, getting the distillation narrative out there early, without evidence, does fit a larger pattern we have seen from them this year.
lifeisloving 14 hours ago [-]
Wild, they are definately downplaying this (and trying to shift blame with the buzzword distillation attack, which is a dog whistle for "scary asian/chinese").
They're skipping past the fact thay keys were even accessible by an intruder... Like huh?? They say its only third party keys, but all my opencode keys were deactivated in tbe process... Why is that, were they storing keys in virtually plain text...
Opencode CEO, Dax, brags all day on twitter (in the most narcissistic fashion) about how much they vibecode and how fast they move. Well, it really shows.
Not to mention, Ive tried to cancel my subscriptions and was double charged, they reverted one of them, then I cancelled again and was charged again....
segfault99 14 hours ago [-]
"but all my opencode keys were deactivated in tbe process"
Similarly woke up this morning to find my OpenCode Go API key had been revoked (remaining monthly usage allowance fortunately not touched).
Whether that was precautionary or is evidence of wider data leak, who knows?
Concur that OC's X messaging is mostly 'Marketing by Sounding off like a Dick' and they're certainly not known for having the best documentation either.
lifeisloving 13 hours ago [-]
Yeah, I didnt observe any unauthorized usage either, im just curious as to why you need to invalidate your users native platform keys.. Why would these be accessible to anyone, sounds like they have poor security hygiene.
searealist 21 hours ago [-]
> security breach
> related to a large scale distillation attack
I'm not sure how this adds up. I could understand if this impacted their uptime, but not security.
Are they actually saying a bunch of credentials were stolen and are being used for distillation?
pranshuchittora 21 hours ago [-]
Yes, they think we are foooool
rvz 21 hours ago [-]
Looking forward to the post-mortem of this incident.
pranshuchittora 20 hours ago [-]
Yes, I am interested in how a distillation attack can leak credentials...
verdverm 15 hours ago [-]
I want an open dataset of the attackers queries with sufficient details that we can do our own analyses, Big Ai has lost most of the public's trust, we the public need to be able to verify for ourselves
vinni2 22 hours ago [-]
But isn’t OpenCode open source why does it need credentials.
progval 22 hours ago [-]
For the inference APIs, which need to bill users. It's unclear why OpenCode's servers (presumably) had access to the API credentials.
himata4113 22 hours ago [-]
They function similar to openrouter BYOK.
trollbridge 21 hours ago [-]
Because people cut and pasted them in.
dist-epoch 22 hours ago [-]
Maybe they support cloud agents.
kelvinjps10 21 hours ago [-]
opencode go and zen?
verdverm 15 hours ago [-]
It does not sound like those were the systems affected by this, there is another service that lets you upload keys for Ant/OAI, where you add one key for your company and then OpenCode enables you to budget / route across vendors.
Use a gateway like LiteLLM or GoModel, don't upload keys to a vendor, they are doing too much eyes and brain free coding this year
wtf was I getting many use OpenCode on OpenCode cloud emails last few days.
Were they set up so that hackers can get more info?
hypfer 19 hours ago [-]
They have shown so so so many times that their culture is not aligned with trustworthy software. Yet people keep using it.
It's not like there wouldn't be any other harnesses either. Just switch to literally anything else please.
john01dav 17 hours ago [-]
Who else has a plan like OpenCode Go for subsidized access to cheap models? I've been using Qwen 3.7 Plus on it and having great results for $10 per month with my personal usage. I'm not aware of any other options with nearly that value, but I am interested in switching because OpenCode isn't so trustworthy, it seems. This is the second issue that I've seen.
OpenCode Go is the best thing they have going. Pi is the way to go for coding harnesses, IMHO. But despite all the BS messaging, something like glm-5.3-flash on $10/month OpenCode Go plan is a great deal if they have a Come to Jesus moment about security and do a bit of team attitude adjustment.
ssernikk 19 hours ago [-]
Can you elaborate on that?
Xavier_da1 16 hours ago [-]
It’s just gonna make AI better it’s going to understand and learn.
latchkey 20 hours ago [-]
the ux is kind of crazy.
you login to their website, and you are presented with a list of providers where you can click and add your provider api key.
how the key is stored on the backend isn't clear, but it is akin to handing your password or if you know crypto, your private key, to someone and letting them store it for you.
from what i can tell, there are no links within the console to a ToS, Privacy policy or anything else. there are no warnings or documentation about how they store your keys.
someone else in this thread linked to this issue, but this comment is especially insane given that i can't find any privacy policy or tos for the console.
and their TOS/Privacy policies are equally light on details.
verdverm 14 hours ago [-]
OpenCode now has a trust page like any vendor worth consideration, but this is generally something enterprises look for. They are working towards a more mature enterprise offering, but this does not bode well for the trust going forward. We're going to need a really, really good RCA and process remediation statement. What lead to this happening, not the hack mechanics, but what at the company has allowed a number of bad security decisions to show up lately, and what are they going to do differently going forward. Hopefully more human in the loop and an external security audit by a trusted name in the security industry.
what’s interesting is that all those efforts that go into sandboxing through virtualization wouldn’t have helped here. But the solutions that proxy the api keys and hide them from agents might have worked as a defense in depth.
of course any sensible engineer that uninstalled this 6 months ago and used codex and claude code directly also avoided this, gg
nrmitchi 19 hours ago [-]
What the the purpose of this comment? Neither of those "red flags" you linked to are related (one is about config loading precedence, and the other is about Codex CLI, which is completely a completely different product and development team.
Exterior-compliance proxies, yes, are a good thing; but are also completely unrelated to the fact that OpenCode's hosted solution, that requires having credentials in some fashion, was popped.
Shitting on anyone who uses OpenCode (rather than your preferred vendor-specific product) as not being "sensible" is also completely out of hand and unnecessary.
verdverm 16 hours ago [-]
I submitted one of those originally and do think that incident is relevant. Not related, but it does qualify as a red flag generally for the company and their attention to their system designs with respect to security.
Our read on the situation is too much eyes and brain free coding, that they assumed the ai redesign of the configuration system was sound. It took a couple of PRs and explanations for them to bring the system to a better place, such that MDM config was respected at the highest priority.
I do give the OpenCode team a lot of credit, at least Aiden, for the handling of this case.
I'm now trying to get the Pi harness to support MDM, but it is not going well... see this and please consider sharing your perspectives or support there
Why are the comments pointing out there were warning signs early on being downvoted/flagged?
I looked at the linked comments, and they seem valid. I mean I dont want to go full tinfoil hat here, but what's the deal? Some people just really like opencode or something?
c-hendricks 20 hours ago [-]
All the comments I've seen about warning signs point to opencode the cli, where this is about one of opencode's hosted services.
verdverm 15 hours ago [-]
There's a pattern though, they companies at the front of the Ai hype train love to brag about their eyes and brain free coding practices. Reap what you sow I suppose
jchw 22 hours ago [-]
I think it may just be bad automated flagging. I vouch'd them since they don't really seem to violate any rules/guidelines (right?)
himata4113 22 hours ago [-]
Indeed. I've seen it happen before and it appears that they have automatic downvoting based on some criteria, possibly just some classifier. I've attributed it to some bot attack before, but it's a bit too common now.
dylan604 22 hours ago [-]
Why does it being common downplay the bot attack to you? As time goes on, I'd assume bots activity to increase. I do not see it ever going away.
himata4113 21 hours ago [-]
bots get caught and downvoting requires reputation.
InsideOutSanta 19 hours ago [-]
Because they're unrelated to this incident.
verdverm 15 hours ago [-]
As the person who worked with the OpenCode team on the CLI security regression this last week, I do not think they are unrelated, though there is no direct connection.
My read is too much vibemaxxing, not enough critical analyses of the Ai output and (re)designs of various systems in their code base.
Breaking Rule #2 - never blindly trust the output from Ai
Hi,
We identified unauthorized access to a legacy system that we were in the process of decommissioning. Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed. Please revoke and replace those keys through the relevant provider’s dashboard, update any applications using them, and review recent usage for unexpected activity.
We’re sorry this happened and will follow up with any updates.
sebastiansm7 21 hours ago [-]
We were planning to fix our vibecoded mess.
18 hours ago [-]
TZubiri 20 hours ago [-]
it’s funny how no one ever announces their critical vulns with “we have been hacked, you should uninstall our software and use something else”, at some point in the severity of the vuln that should be the conclusion, but no one ever says it
> Beware of the author of tweet, who happens to be author of OpenCode - OpenCode will leak all your data to themselves and to shady 3rd parties. Author feigned ignorance and never fixed the issue. OpenCode among other harnesses is the shadiest of all.
"when challenged about sending data to openrouter without listing it as a 3rd party processor they offered a dismissive response. the same with running prompts through cloudflare. seems trivial, but signifies general disinterest in security."
I did have an account but moved off for security reasons.
neya 22 hours ago [-]
Damn, that sucks. I didn't know OpenCode was this bad when it came to privacy.
tadasv 20 hours ago [-]
This is one of the reasons I don't trust opencode. It looked very nice on paper when it first came out and there were no alternatives. However, today I'd probably stick with simple pi setup (not sure how much better than opencode, but it looks like they don't have all this cloud stuff) or just use one of the big tech agents and call it a day.
verdverm 14 hours ago [-]
You might reconsider how serious the Pi team takes security based on the eventual result of this issue. They are also working on a service like this called Radius.
If i dont use any of their models nor i am signed in, is that a problem? i dont see anything in wireshark except for models.opencode.ai
Reyonlds96 18 hours ago [-]
I love the smell of misinformation in the morning.
All it ever did was give people free model for title gen, if they didn't set one themselves. Feature you could disable or set on your own model.
That was since removed, so now there is no free fallback model.
That is it. It is still private by default
anonymous908213 18 hours ago [-]
> All it ever did was give people free model for title gen,
All it "ever did" was send your entire prompt/context to a "free" model for harvesting. The astroturfing in this thread is absurd.
Reyonlds96 18 hours ago [-]
It sent the prompt to a GPT-5-nano model with the max zdr you can get on openai.
That was done to give people free title gen, unless they set it themselves.
Title gen does not send anything but the prompt.
Maybe try a sensible approach first, cause so far this is assumed, for no reason, to be done maliciously. "to steal data" and the like.
Opencode's source code is public, so you can verify any claim against it directly.
NavinF 18 hours ago [-]
but the prompt was sent to OpenAI via Opencode's servers right? So even when you use a local model, Opencode can still see your prompt by default?
Reyonlds96 18 hours ago [-]
It was going through zen, so they CAN see it if they want to. Same applies to anything on Zen. But, zen is ZDR. Same goes to any provider, ZDR or not, as ZDR is just an agreement. With Openai - caveats apply on Openai side itself(they retain logs regardless).
During this short period - yes. Unless it finds a valid small model, or you set one yourself - it would use the one provided by zen. or you could disable it with an invalid model altogether.
Good gesture for most users and something else to others.
It's *could by the way, as this was only a short window when this was a thing. It went back to not having this fallback pretty fast, i don't think it even lasted a month.
The leak was for something called 'OpenCode Console', which is distinct and separate from the OpenCode coding agent. If you're just using the coding agent, you're not affected. 'OpenCode Console' is a service that is similar to OpenRouter, but is much less widely used.
The name 'OpenCode Console' is super confusing, because one might think it means the CLI coding agent. It does not. 'OpenCode Console' has nothing to do with the CLI/TUI coding agent, nor the desktop app version.
The situation is made worse by the fact that 'OpenCode Console' barely has any documentation online, and the official leak announcement does not make the distinction clear at all. The OpenCode team did a terrible job of communicating this, and that's on them.
Today is a bad day for people using 'OpenCode Console'. But most people, probably the vast majority of OpenCode users who are reading this, are not using 'OpenCode Console'.
So far, "OpenCode" has gone through several possible definitions:
- OpenCode Terminal / CLI - This is what you get normally. Runs a service in the background and the CLI is your interface.
- OpenCode Desktop - Instead of a CLI, you get a desktop interface.
Most users usually stop here. You just install the app and you connect wherever.
So there's the services where they both make money and make things easier for users:
- OpenCode Console - Basically the serving platform for both Zen and Go, and has expanded to a hosted inference gateway and somewhat similar to OpenRouter or a managed LiteLLM. Has the option to BYOK if you have existing AI platform accounts so it charges those instead of Zen, and that's what got compromised.
- OpenCode Zen - the API service they host if you want to get access to providers but don't want to pay individually per API platform. Similar to OpenRouter. I noticed they're kinda slowly dropping the Zen moniker.
- OpenCode Go - the subscription service that they host that features open weight models and select low-cost models from frontier labs. Has different policies when it comes to privacy and retention compared to Zen.
- OpenCode Black - a limited-time, limited access subscription service that grants access to frontier models. Not sure if this is still alive or not.
Or Open Code Rust?
https://vale.rocks/micros/20260512-0652
If they took payment, they are liable and they must have the ability to refund.
https://docs.github.com/en/code-security/reference/secret-se... has a table with the active partners
If they are acting maliciously, they will take the choice that most hurts you and/or benefits them.
If the key is useless to them and revoking it hurts you, then they would do that.
If the key wasn’t useless to them, then… they would just use it and not revoke it?
Unilaterally decide they should be revoked, without contacting the owner?
And that’s not malicious?
Be serious.
If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience.
Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act.
That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak.
For example AWS applies a “quarantine” policy that prevents some specific actions[1].
Allowing anyone to report a potentially compromised key is one thing, but allowing anyone to unilaterally revoke a token is another.
1. https://docs.aws.amazon.com/aws-managed-policy/latest/refere...
> I think every API key system should have endpoint "invalidate_api_key"
Not this.
What is your alternative idea?
No idea why you’re being so hostile here.
The status quo is clearly the local minima, given the myriad of trade offs and different parties involved.
It's in their announcement; it's just not written in a way that people immediately understand.
Run a gateway like GoModel instead of uploading your keys to a vendor to prevent this class of attack in the future.
https://gomodel.enterpilot.io/ (my preferred gateway)
In essence they used OpenCode Zen similar to OpenRouter, where you can BYOK or use theirs and be charged token rates.
https://dev.opencode.ai/console/
It's actually kinda hard to figure out what it is. But it does appear to be different that the CLI
From https://opencode.ai/v2/docs#connect :
> If you’d like easy access to all the best coding models you can try out OpenCode Console.
The opencode CLI has no impact.
Headlines are designed to capture attention and readers, how much detail does it need to go into? It's not dishonest or misleading but yes it's attention grabbing.
OpenCode, and the lot, will need to release an open, public, dataset containing the original queries (and other relevant details) that the hacked keys were used for. I'm unwilling to trust those industry players at their word. We need to do our own community analyses.
The way some of this place's employees post and act online, can't say I feel all that bad.
that's why virustotal was flagging it then
run a gateway like LiteLLM or GoModel, don't upload keys to a vendor
- https://gomodel.enterpilot.io/ (my preference)
- https://docs.litellm.ai/docs/
I would like to see the companies release an open dataset of the attackers queries, such that we can do our own analyses as a community. Public trust is in the xitter with these folks.
you can learn more from here, they did handle that one much better, all-in-all
https://news.ycombinator.com/item?id=50075319
I would recommend running your own gateway instead of uploading keys to a vendor. My gateway of choice is GoModel
https://gomodel.enterpilot.io/
Hackers breached an Open Code legacy system containing customer keys for openai etc, and ran up large bills against the customer's openai accounts . The tokens were used to train the hacker's ai models (the distillation).
My guess is a more primitive arbitrage / resale attack . Like reselling EBT cards or "free" vpn traffic.
We do not know if that is what the hacked API keys were used for. Could be distillation, could be API reselling. We will need more transparency into the nature of the requests made by the attacker. I would like to see an open dataset of the queries made with the compromised keys. All of them as originally made, not aggregate stats or another METR report.
The keys could have also been used to resell API access on the black market, again, we need good transparency to know. Considering the upstream parties involved, getting the distillation narrative out there early, without evidence, does fit a larger pattern we have seen from them this year.
They're skipping past the fact thay keys were even accessible by an intruder... Like huh?? They say its only third party keys, but all my opencode keys were deactivated in tbe process... Why is that, were they storing keys in virtually plain text...
Opencode CEO, Dax, brags all day on twitter (in the most narcissistic fashion) about how much they vibecode and how fast they move. Well, it really shows.
Not to mention, Ive tried to cancel my subscriptions and was double charged, they reverted one of them, then I cancelled again and was charged again....
Similarly woke up this morning to find my OpenCode Go API key had been revoked (remaining monthly usage allowance fortunately not touched).
Whether that was precautionary or is evidence of wider data leak, who knows?
Concur that OC's X messaging is mostly 'Marketing by Sounding off like a Dick' and they're certainly not known for having the best documentation either.
> related to a large scale distillation attack
I'm not sure how this adds up. I could understand if this impacted their uptime, but not security.
Are they actually saying a bunch of credentials were stolen and are being used for distillation?
Use a gateway like LiteLLM or GoModel, don't upload keys to a vendor, they are doing too much eyes and brain free coding this year
- https://gomodel.enterpilot.io/ (my preference)
- https://docs.litellm.ai/docs/
It's not like there wouldn't be any other harnesses either. Just switch to literally anything else please.
The other issue: https://news.ycombinator.com/item?id=49655991
you login to their website, and you are presented with a list of providers where you can click and add your provider api key.
how the key is stored on the backend isn't clear, but it is akin to handing your password or if you know crypto, your private key, to someone and letting them store it for you.
from what i can tell, there are no links within the console to a ToS, Privacy policy or anything else. there are no warnings or documentation about how they store your keys.
someone else in this thread linked to this issue, but this comment is especially insane given that i can't find any privacy policy or tos for the console.
https://github.com/anomalyco/opencode/issues/10416#issuecomm...
https://trust.opencode.ai/
https://x.com/thdxr/status/2111831348336091179
https://x.com/thdxr/status/2111790511409258796
https://news.ycombinator.com/item?id=50075319
https://news.ycombinator.com/item?id=50060694
what’s interesting is that all those efforts that go into sandboxing through virtualization wouldn’t have helped here. But the solutions that proxy the api keys and hide them from agents might have worked as a defense in depth.
of course any sensible engineer that uninstalled this 6 months ago and used codex and claude code directly also avoided this, gg
Exterior-compliance proxies, yes, are a good thing; but are also completely unrelated to the fact that OpenCode's hosted solution, that requires having credentials in some fashion, was popped.
Shitting on anyone who uses OpenCode (rather than your preferred vendor-specific product) as not being "sensible" is also completely out of hand and unnecessary.
Our read on the situation is too much eyes and brain free coding, that they assumed the ai redesign of the configuration system was sound. It took a couple of PRs and explanations for them to bring the system to a better place, such that MDM config was respected at the highest priority.
I do give the OpenCode team a lot of credit, at least Aiden, for the handling of this case.
https://github.com/anomalyco/opencode/pull/51337#issuecommen...
I'm now trying to get the Pi harness to support MDM, but it is not going well... see this and please consider sharing your perspectives or support there
https://github.com/earendil-works/pi/issues/10895
I looked at the linked comments, and they seem valid. I mean I dont want to go full tinfoil hat here, but what's the deal? Some people just really like opencode or something?
My read is too much vibemaxxing, not enough critical analyses of the Ai output and (re)designs of various systems in their code base.
Breaking Rule #2 - never blindly trust the output from Ai
https://susam.net/inverse-laws-of-robotics.html
---
Hi, We identified unauthorized access to a legacy system that we were in the process of decommissioning. Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed. Please revoke and replace those keys through the relevant provider’s dashboard, update any applications using them, and review recent usage for unexpected activity.
We’re sorry this happened and will follow up with any updates.
This was a leak of keys added in a web UI
Me, 68 days ago:
> Beware of the author of tweet, who happens to be author of OpenCode - OpenCode will leak all your data to themselves and to shady 3rd parties. Author feigned ignorance and never fixed the issue. OpenCode among other harnesses is the shadiest of all.
> https://github.com/anomalyco/opencode/issues/10416
I did have an account but moved off for security reasons.
https://github.com/earendil-works/pi/issues/10895
https://radius.earendil.com/
That is it. It is still private by default
All it "ever did" was send your entire prompt/context to a "free" model for harvesting. The astroturfing in this thread is absurd.
Maybe try a sensible approach first, cause so far this is assumed, for no reason, to be done maliciously. "to steal data" and the like.
Opencode's source code is public, so you can verify any claim against it directly.
During this short period - yes. Unless it finds a valid small model, or you set one yourself - it would use the one provided by zen. or you could disable it with an invalid model altogether. Good gesture for most users and something else to others.
It's *could by the way, as this was only a short window when this was a thing. It went back to not having this fallback pretty fast, i don't think it even lasted a month.