A vulnerability in Clauster (≤0.2.1) occurs when the instance is bound to a non-loopback address and authentication is partially configured (password or reverse proxy enabled) but the auth.enabled flag remains false (default). The runtime authentication guard only enforces authentication if auth.enabled is true, otherwise it allows all requests unauthenticated. The configuration validator does not require auth.enabled to be true when password or reverse proxy authentication is set, resulting in a misconfiguration that exposes the dashboard and API without authentication. This enables unauthenticated attackers with network access to fully control the dashboard and execute code remotely via Claude Code bridges. Loopback-only deployments are unaffected. A patch release will enforce fail-closed validation requiring auth.enabled to be true for non-loopback binds with authentication settings. Documentation and Docker defaults have been updated accordingly.

Unauthenticated attackers with network access to a Clauster instance bound to a non-loopback address and misconfigured authentication can gain full control over the dashboard and API. They can list projects, spawn or stop remote-control bridges that execute code in project directories, edit files, read logs, and clone repositories. This effectively allows remote code execution within the context of the project directories. Loopback-only deployments are not impacted. The vulnerability arises from a configuration validation flaw combined with runtime enforcement logic.

A patch release is planned that will enforce strict configuration validation requiring auth.enabled to be true when authentication is configured on non-loopback binds. Until the patch is available, operators should explicitly set auth.enabled: true in their configuration alongside existing auth.password_required and password hash or reverse proxy settings. Alternatively, bind Clauster to the loopback interface only and access it through an SSH tunnel or trusted authenticating reverse proxy. The updated documentation and Docker usage instructions reflect these mitigations.