You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Harden server mode: require auth for non-loopback binds (secure-by-default) #44640
This is not an issue but an much needed hardening for non-loopback bind + no auth case.
Summary
opencode serve / opencode web print a warning and then start unauthenticated
when bound to a non-loopback address without OPENCODE_SERVER_PASSWORD. Because the CLI
actively advertises this configuration — opencode web --hostname 0.0.0.0 prints
ready-to-use "Network access: http://:" URLs, and --mdns defaults the
hostname to 0.0.0.0 — a user following the printed instructions ends up exposing an API
that can spawn processes on the host with no credentials.
This is a secure-by-default / hardening request, not a new vulnerability report. The
underlying unauthenticated-server behavior is already documented (CVE-2026-22812) and I
understand per SECURITY.md that securing server mode is the operator's responsibility. This
issue only asks that the default not lead users into that exposure.
The gap
The problem isn't that server mode can be unauthenticated — it's that the CLI's own output
(web network URLs, --mdns binding to 0.0.0.0) actively steers users toward binding
non-loopback without a password.
Suggested mitigations (any one closes the gap)
Refuse to bind a non-loopback address unless OPENCODE_SERVER_PASSWORD is set, with a
clear error. Loopback-only stays passwordless, as today.
Or: auto-generate a random session password when binding non-loopback without one, print
it once at startup, and require it.
Don't print "Network access" URLs unless auth is configured.
Expected vs actual (mitigation 1)
Expected: opencode serve --hostname 0.0.0.0 without a password exits with:
"Refusing to bind 0.0.0.0 without authentication. Set OPENCODE_SERVER_PASSWORD, or use
--hostname 127.0.0.1 for local-only access."
Actual: warning printed, server starts unauthenticated on all interfaces.
Implemented in v2: the CLI server requires a password and generates a random one when none is configured, printing it at foreground startup. This covers the auto-generated-password mitigation requested here rather than starting an unauthenticated network listener. Upgrade with npm i -g @opencode/cli@latest. If you still see this on v2, please open a new issue with the details.
Activity
github-actions commentedon Aug 24, 2026
This issue might be a duplicate of existing issues. Please check:
opencode webserver — insecure default + no access logging #38857: Reports the same underlying exposure —opencode webbinding to0.0.0.0without authentication, and requests that the CLI refuse to start on non-localhost interfaces without a password (identical to your mitigation 1). It also includes a real-world compromise account.0.0.0.0withOPENCODE_SERVER_PASSWORDsupport, which overlaps with your suggested mitigations.You may want to add your comments or suggested mitigations to those existing threads rather than tracking this separately.
vishal-sr-2206 commentedon Aug 24, 2026
Thanks to Duplicate check bot, with its reference i can map that issue #38857 could been avoided if the requested hardening was implemented.
Thanks.
neriousy commentedon Oct 19, 2026
Implemented in v2: the CLI server requires a password and generates a random one when none is configured, printing it at foreground startup. This covers the auto-generated-password mitigation requested here rather than starting an unauthenticated network listener. Upgrade with
npm i -g @opencode/cli@latest. If you still see this on v2, please open a new issue with the details.