security: reveal-token endpoint lacks requireLocalhost guard #411

New issue

Closed

opened 2026-07-21 00:06:01 +02:00 by dries · 0 comments

dries commented

2026-07-21 00:06:01 +02:00

Owner

Finding #2 (Medium) from a security review.

Problem

POST /api/settings/remote-access/reveal-token returns the plaintext remote-access token — a credential granting full gRPC control of the instance (session mutation, tmux/opencode launch). It is gated only by s.post + requireAuth, unlike every other privileged route which uses requireLocalhost.

With auth disabled (default) and a non-loopback -addr, any network client can fetch the credential.

Refs

internal/server/routes.go:136
internal/server/handlers_settings.go (handleRevealRemoteToken)

Suggested fix

Wrap the handler in requireLocalhost (like the other host-control routes), or refuse when auth == nil and the peer is non-loopback.

Acceptance

reveal-token returns 403 for a non-loopback client.
Loopback + authenticated (or trust-localhost) still works.
Test covering the non-loopback reject.

Finding #2 (Medium) from a security review. ## Problem `POST /api/settings/remote-access/reveal-token` returns the plaintext remote-access token — a credential granting full gRPC control of the instance (session mutation, tmux/opencode launch). It is gated only by `s.post` + `requireAuth`, unlike every other privileged route which uses `requireLocalhost`. With auth disabled (default) and a non-loopback `-addr`, any network client can fetch the credential. ## Refs - `internal/server/routes.go:136` - `internal/server/handlers_settings.go` (`handleRevealRemoteToken`) ## Suggested fix Wrap the handler in `requireLocalhost` (like the other host-control routes), or refuse when `auth == nil` and the peer is non-loopback. ## Acceptance - reveal-token returns 403 for a non-loopback client. - Loopback + authenticated (or trust-localhost) still works. - Test covering the non-loopback reject.