Summary
In 2.0.442, the per-request header-token check appears to have been removed from several local daemon GET endpoints (/v1/runtime, /v1/inventory, /v1/settings, /v1/events, /v1/sessions), which now rely solely on the 127.0.0.1 bind plus the Origin allow-list. Raising this as a defense-in-depth concern — this was noticed during routine supply-chain monitoring and the package is otherwise clean; not reporting any malicious behavior.
Details
These endpoints expose local runtime state, inventory, and settings. The loopback bind prevents remote network access, and the Origin allow-list mitigates browser-driven CSRF / DNS-rebinding. However, with the GET header-token gate removed, any local process — or a request path that doesn't carry a browser Origin header (e.g. a non-browser client) — can read these endpoints without presenting a token. The SSE event stream also moved to query-string token auth (/v1/events/stream?...token=), which is more prone to leaking via process arguments, shell history, proxy logs, and Referer than a header-based token.
Separately, the daemon.auth.unauthorized audit event (and the _record_auth_audit_event helper) was removed in this release; 401s are now written directly. This reduces security telemetry for auth-failure / probing detection.
Risk scenario
On a shared or compromised developer machine, a malicious local process could read Guard's inventory / settings / runtime state (and metadata about the tools Guard is protecting) without the previously-required token. Because auth-failure auditing was also removed in the same release, such probing would leave less trace.
Suggested mitigations
- Keep the header-token gate on state-exposing
GET endpoints as defense-in-depth, alongside the loopback bind and Origin allow-list.
- Prefer header-based tokens over query-string tokens for the SSE stream where the client allows it.
- Retain
daemon.auth.unauthorized (or equivalent) audit logging for auth failures.
Happy to provide more detail. Thanks for the work on Guard!
Summary
In
2.0.442, the per-request header-token check appears to have been removed from several local daemonGETendpoints (/v1/runtime,/v1/inventory,/v1/settings,/v1/events,/v1/sessions), which now rely solely on the127.0.0.1bind plus the Origin allow-list. Raising this as a defense-in-depth concern — this was noticed during routine supply-chain monitoring and the package is otherwise clean; not reporting any malicious behavior.Details
These endpoints expose local runtime state, inventory, and settings. The loopback bind prevents remote network access, and the Origin allow-list mitigates browser-driven CSRF / DNS-rebinding. However, with the GET header-token gate removed, any local process — or a request path that doesn't carry a browser
Originheader (e.g. a non-browser client) — can read these endpoints without presenting a token. The SSE event stream also moved to query-string token auth (/v1/events/stream?...token=), which is more prone to leaking via process arguments, shell history, proxy logs, andRefererthan a header-based token.Separately, the
daemon.auth.unauthorizedaudit event (and the_record_auth_audit_eventhelper) was removed in this release; 401s are now written directly. This reduces security telemetry for auth-failure / probing detection.Risk scenario
On a shared or compromised developer machine, a malicious local process could read Guard's inventory / settings / runtime state (and metadata about the tools Guard is protecting) without the previously-required token. Because auth-failure auditing was also removed in the same release, such probing would leave less trace.
Suggested mitigations
GETendpoints as defense-in-depth, alongside the loopback bind and Origin allow-list.daemon.auth.unauthorized(or equivalent) audit logging for auth failures.Happy to provide more detail. Thanks for the work on Guard!