A coworker raised an interesting point to me. The CORS fix removes exploitation by arbitrary websites (but obviously allows full access from the opencode domain), but let's take that piece out for a second...

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?

▲

mirashii an hour ago | parent | next [-]

Neovim’s server defaults to named pipes or domain sockets, which do not have this issue. The documentation states that the TCP option is insecure.

VS Code’s ssh daemon is authenticated.

	▲	ollien 31 minutes ago \| parent [-]
		> Neovim’s server defaults to named pipes or domain sockets, which do not have this issue. The documentation states that the TCP option is insecure. 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?

▲

winstonwinston 2 hours ago | parent | prev [-]

If you have a localhost server that uses a client input to execute code without authentication, that’s a local code execution vulnerability at the very least. It becomes a RCE when you find a way to reach local server over the wire, such as via browser http request.

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.