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
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.
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
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!
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/ .
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?
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/
Please run at least a dev-container or a VM for the tools. You can use RDP/ VNC/ Spice or even just the terminal with tmux to work within the confines of the container/ machine. You can mirror some stuff into the container/ machine with SSHFS, Samba/ NFS, 9p. You can use all the traditional tools, filesystems and such for reliable snapshots. Push the results separately or don't give direct unrestricted git access to the agent.
It's not that hard. If you are super lazy, you can also pay for a VPS $5/month or something like that and run the workload there.
> Please run at least a dev-container or a VM for the tools.
I would like to know how to do this. Could you share your favorite how-to?
If you want a dedicated virtual host, Proxmox seems to be pretty easy to install even for relative newcomers and it has a GUI that's decent for new people and seasoned admins as well.
For the remote connection I just use SSH and tmux, so I can comfortably detach and reattach without killing the tool that's running inside the terminal on the remote machine.
I hope this helps even though I didn't provide a step-by step guide.
Working with devcontainers from CLI wasn't very difficult [0], but I must confess that I only tested it once.
> I would like to know how to do this. Could you share your favorite how-to?
See: https://www.docker.com/get-started/
EDIT:
Perhaps you are more interested in various sandboxing options. If so, the following may be of interest:
Oh btw if someone wants to run servers via qemu, I highly recommend quickemu. It provides default ssh access,sshfs, vnc,spice and all such ports to just your local device of course and also allows one to install debian or any distro (out of many many distros) using quickget.
Its really intuitive for what its worth, definitely worth a try https://github.com/quickemu-project/quickemu
I personally really like zed with ssh open remote. I can always open up terminals in it and use claude code or opencode or any and they provide AI as well (I dont use much AI this way, I make simple scripts for myself so I just copy paste for free from the websites) but I can recommend zed for what its worth as well.
https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32...
What's the difference here between this and, for example, the Neovim headless server or the VSCode remote SSH daemon? All three listen on 127.0.0.1 and would grant execution access to another process who could speak to them.
Is there a difference here? Is the choice of HTTP simply a bad one because of the potential browser exploitation, which can't exist for the others?
VS Code’s ssh daemon is authenticated.
Good note on pipes / domain sockets, but it doesn't appear there's a "default", and the example in the docs even uses TCP, despite the warning below it.
https://neovim.io/doc/user/api.html#rpc-connecting
(EDIT: I guess outside of headless mode it uses a named pipe?)
> VS Code’s ssh daemon is authenticated.
How is it authenticated? I went looking briefly but didn't turn up much; obviously there's the ssh auth itself but if you have access to the remote, is there an additional layer of auth stopping anyone from executing code via the daemon?
I don’t use VSCode you have mentioned so i don’t know how it is implemented but one can guess that it is implemented with some authentication in mind.
Reported 2025-11-17, and multiple "no responses" after repeated attempts to contact the maintainers... not a good look.
https://github.com/anomalyco/opencode/issues/6355#issuecomme...
everybody is vibecoding now, and dealing with massive security issues is bad vibes.
> Network Boundary Shield
> The Network Boundary Shield (NBS) is a protection against attacks from an external network (the Internet) to an internal network - especially against a reconnaissance attack where a web browser is abused as a proxy.
> The main goal of NBS is to prevent attacks where a public website requests a resource from the internal network (e.g. the logo of the manufacturer of the local router); NBS will detect that a web page hosted on the public Internet is trying to connect to a local IP address. NBS only blocks HTTP requests from a web page hosted on a public IP address to a private network resource; the user can allow specific web pages to access local resources (e.g. when using Intranet services).
> When server is enabled, any web page served from localhost/127.0.0.1 can execute code
> When server is enabled, any local process can execute code without authentication
> No indication when server is running (users may be unaware of exposure)
I'm sorry this is horrible. I really want there to be a good actual open cross-provider agentic coding tool, but this seems to me to be abusive of people's trust of TUI apps - part of the reason we trust them is they typically DON'T do stuff like this.
afaict, for that project they never went through PCI compliance. See original thread for more information: https://news.ycombinator.com/item?id=40228751
They seem to not have a lot of real world experience and/or throw caution to the wind and YOLO through security practices. I'd be weary using any of their products.
[0]: https://www.ycombinator.com/companies/sst
[1]: https://anoma.ly/
I have no idea where you got your internal image of YC-backed companies from, but it needs massive adjusting.
Having said that, there is definitely a need for open platform to utilize multiple vendors and models. I just don’t think the big three (Anthropic, OAI and Google) will cede that control over with so much money on the line.
Amp can do small utility scripts and changes for free (especially if you enable the ads) and Crush+GLM is pretty good at following plans done by Claude or Codex
It does take a lot of discipline to review everything instead of pile on another feature, when it's so cheap to do.
> Hey - have some bad news.
> We accidentally committed your email to our repo as part of a script that was activating OpenCode Black.
> No other information was included, just the email on its own.
Meanwhile, running opencode in a podman container seems to stop this particular, err, feature.
Atleast they didnt implode their communications like I see from some other companies.
To be really honest, when you bet on AI agents, I feel like soemtimes you bet on the future of the product as well which is built by the people so you are basically betting on the people.
I'd much rather bet/rely on people who are sensibile in communications in troubled times like this than who implode sometimes (I mean no offense to Coderabbit but this is what comes to my head right now)
So moments like these become the litmus test of the products basically imo by seeing how people communicate etc.
Maybe I'm using GitHub code search wrongly, but it appears this was just never part of even a pull request - the practice of just having someone pushing to `dev` (default branch) which then will be tagged should perhaps also be revisited.
(Several more commits under `wip: bash` and `feat: bash commands`)
https://github.com/anomalyco/opencode/commit/7505fa61b9caa17...
https://github.com/anomalyco/opencode/commit/93b71477e665600...
To be clear, this is a vulnerability. Just the same as exposing unauthenticated telnet is a vulnerability. User education is always good, but at some point in the process of continuing to build user-friendly footguns we need to start blaming the users. “It is what it is”, Duh.
This “vulnerability” has been known by devs in my circle for a while, it’s literally the very first intuitive question most devs ask themselves when using opencode, and then put authentication on top.
Particularly in the AI space it’s going to be more and more common to see users punching above their weight with deployments. Let em learn. Let em grow. We’ll see this pain multiply in the future if these lessons aren’t learned early.
It saw goproxy.cn and used goproxy.cn, looks linear to me.
So did they fix it silently, without responding to the researcher, or they fixed the silent part where now user is made a aware that a website is trying to execute code on their machine.
But this leaves a very bad taste.
Guess I will stick to aider and copy-pasting.
The rest is just code running as your user can talk to code running as your user. I don't really consider this to be a security boundary. If I can run arbitrary code by hitting a URL I accept that any program running as me can as well. Going above and beyond is praiseworthy (good for you turning on SELinux as an example) but I don't expect it by default.
No, that's a Chrome-specific feature that Google added. It is not part of any standard, and does not exist in other browsers (e.g. Safari and Firefox).
> The rest is just code running as your user can talk to code running as your user
No, that assumes that there is only a single user on the machine, and there are either no forms of isolation or that all forms of isolation also use private network namespaces, which has not been how daemons are isolated in UNIX or by systemd. For example, if you were to ever run OpenCode as root, any local process can trivially gain root as well.
True I did assume machines are single user, I haven't seen a shared computer in ages. Doing local development I have insecure/incomplete software listening on localhost all the time while developing it. And lots of people have passwordless sudo, or unprivileged access to the docker socket so protection against local processes running as me is not part of my threat model. And I know this is pretty dev centric but OpenCode is dev centric as well.
Apparently a group of devs forked it: https://github.com/dwash96/cecli
Haven't tried yet
Also it uses astro 5.7.13 that may have an SSRF of it's own. No idea if would be exploitable, but way out of date packages with potential security risks are a good place to start looking.
which introduced so many bugs that people unsubscribed
come on people, docker and podman exist, please use them - it isolates you not only from problems like this but supply chain attacks as well.
it also has superior compatibility, any person working on your project will have all the tools available to compile it since to build & run it you use a simple Containerfile.
(rather outdated now: https://github.com/DeprecatedLuke/claude-loop)
