top | item 46592871

(no title)

thdxr | 1 month ago

hey maintainer here

we've done a poor job handling these security reports, usage has grown rapidly and we're overwhelmed with issues

we're meeting with some people this week to advise us on how to handle this better, get a bug bounty program funded and have some audits done

discuss

order

Imustaskforhelp|1 month ago

My original message was more positive but after more looking into context, I am a bit more pessimistic.

Now I must admit though that I am little concerned by the fact that the vulnerability reporters tried multiple times to contact you but till no avail. This is not a good look at all and I hope you can fix it asap as you mention

I respect dax from the days of SST framework but this is genuinely such a bad look especially when they Reported on 2025-11-17, and multiple "no responses" after repeated attempts to contact the maintainers...

Sure they reported the bug now but who knows what could have / might have even been happening as OpenCode was the most famous open source coding agent and surely more cybersec must have watched it, I can see a genuine possibility where something must have been used in the wild as well from my understanding from black hat adversaries

I think this means that we should probably run models in gvisor/proper sandboxing efforts.

Even right now, we don't know how many more such bugs might persist and can lead to even RCE.

Dax, This short attention would make every adversary look for even more bugs / RCE vulnerabilities right now as we speak so you only have a very finite time in my opinion. I hope things can be done as fast as possible now to make OpenCode more safer.

thdxr|1 month ago

the email they found was from a different repo and not monitored. this is ultimately our fault for not having a proper SECURITY.md on our main repository

the issue that was reported was fixed as soon as we heard about it - going through the process of learning about the CVE process, etc now and setting everything up correctly. we get 100s of issues reported to us daily across various mediums and we're figuring out how to manage this

i can't really say much beyond this is my own inexperience showing

jannniii|1 month ago

They are a small team and tool has gotten wildly popular. Which is not to say that slowing down and addressing quality and security issues would not be a bad idea.

I’ve been an active user of opencode for 7-8 months now, really like the tool, but beginning to get a feeling that the core team’s idea of keeping the core development to themselves is not going to scale any longer.

Really loving opencode though!

Rygian|1 month ago

Don't waste your time and money on funding bug bounties or "getting audits done". Your staff will add another big security flaw just the next day, back to square one.

Spend that money in reorganizing your management and training your staff so that everyone in your company is onboard with https://owasp.org/Top10/2025/A06_2025-Insecure_Design/ .

staticassertion|1 month ago

If part of the problem was that no one was responding to a vulnerability report then a bug bounty program would potentially address that.

bopbopbop7|1 month ago

Why not just ask Claude to fix the security issues and make sure they don't happen again?

Hamuko|1 month ago

And if you don't have a Claude subscription, you can just ask your friends to fix them via the remote code execution server.

Y_Y|1 month ago

Talk about kicking someone while they're down...

croes|1 month ago

Who knows what created the issues in the first place place

digdugdirk|1 month ago

I've been curious how this project will grow over time, it seems to have taken the lead as the first open source terminal agent framework/runner, and definitely seems to be growing faster than any organization would/could/should be able to manage.

It really seems like the main focus of the project should be in how to organize the work of the project, rather than on the specs/requirements/development of the codebase itself.

What are the general recommendations the team has been getting for how to manage the development velocity? And have you looked into various anarchist organizational principles?

observationist|1 month ago

Good luck, and thank you for eating the accountability sandwich and being up front about what you're doing. That's not always easy to do, and it's appreciated!

heliumtera|1 month ago

Congrats on owning this, good job, respect

shimman|1 month ago

It's hard to not own it when it's publicly disclosed. Maybe save the accolades for when they actually do something and not just say something.

cryptonector|1 month ago

For one thing spend a lot more time analyzing your code for these bugs. Use expert humans + LLMs to come up with an analysis plan then use humans + LLMs to execute the plan.

dionian|1 month ago

I don't know much about your product, but I have to say that hearing this kind of blunt communication is really refreshing

rtaylorgarlock|1 month ago

Respect for openness. Good work and good luck.

Rygian|1 month ago

I don't understand what is being encouraged here.

Something is seriously wrong when we say "hey, respect!" to a company who develops an unauthenticated RCE feature that should glaringly shine [0] during any internal security analysis, on software that they are licensing in exchange for money [1], and then fumble and drop the ball on security reports when someone does their due diligence for them.

If this company wants to earn any respect, they need at least to publish their post-mortem about how their software development practices allowed such a serious issue to reach shipping.

This should come as a given, especially seeing that this company already works on software related to security (OpenAuth [2]).

[0] https://owasp.org/Top10/2025/ - https://owasp.org/Top10/2025/A06_2025-Insecure_Design/ - https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/ - https://owasp.org/Top10/2025/A05_2025-Injection/

[1] https://opencode.ai/enterprise

[2] https://anoma.ly/

falloutx|1 month ago

Its okay, if you can fix it soon, it should be fine.