I have a hypothesis why issues like that are so widespread. That AI infrastructure is mostly developed by large companies; their business model is selling software as a service at scale. Hence containers, micro-services, TCP/IP in between. That approach is reasonable for data centres because these made of multiple servers i.e. need networking, and they have private virtual networks just to connect servers so the security consequences aren’t too bad.
If they were designing these infrastructure pieces primarily for consumer use, they would have used named pipes, Unix domain sockets, or some other local-only IPC method instead of TCP/IP.
I don't know if I missed something, but this CVE isn't that major as it was suggested to be? For one it had to originate from app.opencode.com and even if it didn't most (good) browsers block websites from probing localhost. Yes it is still a pretty bad CVE, but not as critical as some might suggest.
> For one it had to originate from app.opencode.com
No, that was the initial mitigation! Before the vulnerability was reported, the server was accessible to the entire world with a wide-open CORS policy.
Not sure what you mean by that, but before they implemented any mitigations, it had a CORS policy that allowed requests from any origin. As far as I know, Chromium is the only browser platform that has blocked sites from connecting to localhost, so users of other browsers would be vulnerable, and so would Chrome users if they could be convinced to allow a localhost connection.
> a RCE vulnerability is the type of thing that nation state actors in Russia and North Korea dream of
Does this mean other state actors are beyond needs of RCE vulns as their tools belt and North Korea and Russia lagging behind? Some other interpretation from security-involved practitioners here - like, I don't know - we already have Pegasus, phew on OpenCode RCE?
> Does this mean other state actors are beyond needs of RCE vulns
No, from experience, any nation state actor would love to take advantage of a RCE vuln: this was painted from the perspective of Bottlerocket which is in use by DoD, NSA, etc.
Historically at least there have been some established high trust projects for which curl | bash made sense. But with AI the scene is full of grifters and vibe coders so we can't have nice things.
The one thing here confusing to me is the past tense used throughout. This CVE seems presented as both past and present, yet the present evidence isn't... Presented.
I have a hypothesis why issues like that are so widespread. That AI infrastructure is mostly developed by large companies; their business model is selling software as a service at scale. Hence containers, micro-services, TCP/IP in between. That approach is reasonable for data centres because these made of multiple servers i.e. need networking, and they have private virtual networks just to connect servers so the security consequences aren’t too bad.
If they were designing these infrastructure pieces primarily for consumer use, they would have used named pipes, Unix domain sockets, or some other local-only IPC method instead of TCP/IP.
I don't know if I missed something, but this CVE isn't that major as it was suggested to be? For one it had to originate from app.opencode.com and even if it didn't most (good) browsers block websites from probing localhost. Yes it is still a pretty bad CVE, but not as critical as some might suggest.
> For one it had to originate from app.opencode.com
No, that was the initial mitigation! Before the vulnerability was reported, the server was accessible to the entire world with a wide-open CORS policy.
https://github.com/anomalyco/opencode/commit/7d2d87fa2c44e32...
How is it wide open? Does everything go through a localhost proxy?
Not sure what you mean by that, but before they implemented any mitigations, it had a CORS policy that allowed requests from any origin. As far as I know, Chromium is the only browser platform that has blocked sites from connecting to localhost, so users of other browsers would be vulnerable, and so would Chrome users if they could be convinced to allow a localhost connection.
> a RCE vulnerability is the type of thing that nation state actors in Russia and North Korea dream of
Does this mean other state actors are beyond needs of RCE vulns as their tools belt and North Korea and Russia lagging behind? Some other interpretation from security-involved practitioners here - like, I don't know - we already have Pegasus, phew on OpenCode RCE?
> Does this mean other state actors are beyond needs of RCE vulns
No, from experience, any nation state actor would love to take advantage of a RCE vuln: this was painted from the perspective of Bottlerocket which is in use by DoD, NSA, etc.
Great write up.
These local agents that you spawn and give access to your drive are kind of insane to me.
It's at the level of
which you cannot inspect, and may be well different every time you interact with it!As per usual, being at the forefront of the tech world is leaving behind privacy and security in the dust... until something bad happens.
Not for me. I was running these things in sandboxes from the start. Couldn't believe people were running this stuff straight up.
Historically at least there have been some established high trust projects for which curl | bash made sense. But with AI the scene is full of grifters and vibe coders so we can't have nice things.
Wild that people don't run these kind of AI agent tools in isolated containers. They seem crazy dangerous even without CVEs.
The one thing here confusing to me is the past tense used throughout. This CVE seems presented as both past and present, yet the present evidence isn't... Presented.
True: but technically the CVE was mitigated by OpenCode by after 1.1.10
* Not running the server by default * Patched the wide open CORS policy which left the server open to execution by any page you visited.
The server is still there but you have to explicitly enable it via `opencode serve`
The original disclosure has a table of fixes that have landed: https://cy.md/opencode-rce/