Unauthenticated remote code execution in OpenCode

Original Article ↗ Hacker News Discussion ↗

Vulnerability and Impact

  • Local HTTP server exposed unauthenticated code execution; originally had permissive CORS, later limited to certain origins.
  • Even after partial fixes, concerns remain: once enabled, any localhost page or local process could execute code; no clear indication server is running.
  • Many see this as an egregious violation of basic principles (least privilege, access control, injection) and a breach of trust for a TUI tool.

Disclosure Process and “Silent” Fix

  • Reporter claims initial disclosure in Nov 2025 with multiple ignored contacts.
  • Maintainers say the email used wasn’t monitored and they lacked a proper SECURITY.md; they fixed the issue as soon as they saw it.
  • CVE is marked “Vendor Advisory”; users criticize the lack of proactive user notification and characterize it as a “silent fix” initially.

Maintainer Response and Capacity Issues

  • Maintainer admits mishandling security reports, cites rapid growth, hundreds of daily issues, and inexperience with CVEs.
  • Plans: bug bounty, audits, better process, security.txt; password now added, and latest release claimed to fully fix RCE.
  • Reactions are mixed: some praise accountability, others say words are cheap until practices change.

Trust, Governance, and Startup Culture

  • Surprise that this is a backed company, not a small hobby project; some recall earlier products with questionable security posture.
  • Criticism of “move fast and break things” and “vibecoding” culture where security and governance lag growth and fundraising.
  • Several argue this incident should be a litmus test for whether to trust the organization at all.

Security Design Critiques

  • Strong pushback on shipping an unauthenticated RCE endpoint plus CORS allowances in a CLI that auto-starts a server.
  • Some argue localhost RCE is “just code as your user talking to itself”; others counter with multi-user systems, root risk, and non-Chrome browsers lacking localhost protections.
  • Suggestions to focus money on secure design and staff training rather than only bug bounties.

Sandboxing and User Mitigations

  • Many recommend running AI agents in containers, VMs, devcontainers, or remote hosts, not directly on laptops.
  • Tools and patterns suggested: Docker/Podman, Proxmox/KVM, VS Code devcontainers, remote SSH + tmux, browser protections like uBlock’s LAN filter or JShelter’s Network Boundary Shield.
  • Repeated advice: never give agents unrestricted access to your primary environment or git repo.

Comparisons to Other Tools & Ecosystem

  • Comparisons to Neovim and VS Code: those use domain sockets or authenticated daemons; TCP modes are explicitly documented as insecure.
  • Broader dissatisfaction: multiple agentic coding tools feel “rough,” under-maintained, or security-light; users discuss alternatives and forks.
  • Some note that AI-written code and “feature velocity” are outpacing code review and core maintenance, increasing risk.

Broader Takeaways for AI Coding Agents

  • Many see this as a warning about the entire class of local AI agents with execution powers.
  • Expectation that ops and security workloads will surge as users “punch above their weight” with these tools.
  • Several commenters say this incident has dissuaded them from trying OpenCode and pushed them back toward simpler or more conservative workflows.