GHSA-H4G2-XFMW-Q2C9: Missing Authentication Bypass in Clauster Configuration Validator

Clauster is a self-hosted web user interface and launcher designed to manage Claude Code remote-control bridges. The platform exposes administrative endpoints to manage active bridges, monitor logs, and configure workspace settings. Claude Code remote-control bridges execute system commands in local project directories under the privileges of the hosting process.

In versions up to and including v0.2.1, Clauster contains a missing authentication vulnerability classified as CWE-306. When deployed on a network-exposed interface without loopback restrictions, the application exposes administrative control APIs and configuration interfaces unauthenticated if the master switch auth.enabled is not explicitly set to true.

This flaw allows unauthenticated remote attackers with network access to the port to access the dashboard and control endpoints. Attackers can leverage this access to execute arbitrary commands through the managed Claude Code bridges, gaining remote code execution on the underlying host system.

The vulnerability arises from a logic mismatch between the configuration validator and the runtime authentication enforcement layer. The application employs a fail-open design when validating network interfaces and configured credentials.

At runtime, the authentication middleware checks incoming requests only if auth.enabled is explicitly set to true. If auth.enabled is set to false or omitted entirely, the auth guard is bypassed, and all API calls are processed without authentication verification. This design ignores other configured variables such as password_required or reverse_proxy.enabled during runtime checks.

In vulnerable versions, the configuration validator in src/clauster/config.py permitted non-loopback bindings as long as password_required or reverse_proxy.enabled were configured, without verifying that the master auth.enabled key was active. Consequently, operators who configured credentials but omitted the master auth.enabled switch had their configurations validated successfully while the application remained completely unprotected.

The vulnerability was patched in version v0.2.2 by introducing a robust fail-closed validation routine. A new helper function, _missing_enforced_auth, was added to determine whether a configuration enforces authentication at runtime.

def _missing_enforced_auth(host: str, auth: AuthConfig) -> bool:
    """Return True when binding host would NOT actually enforce authentication."""
    if host in _LOOPBACK_HOSTS:
        return False
    return not (auth.enabled and (auth.password_required or auth.reverse_proxy.enabled))

The configuration validator _loopback_or_authed was updated to utilize this helper. When a non-loopback host is bound and _missing_enforced_auth evaluates to true, the validator raises a ValueError unless the operator has explicitly configured allow_unauthenticated_network to bypass the security check.

a = self.auth
if _missing_enforced_auth(self.host, a) and not a.allow_unauthenticated_network:
    raise ValueError(
        f"refusing non-loopback host={self.host!r} without enforced auth. Set "
        "auth.enabled: true together with auth.password_required ..."
    )

The update also modified administrative diagnostics in src/clauster/ops.py to use the same logic, preventing situations where the setup validator and runtime diagnostics disagree on configuration safety.

An attacker with network access to the exposed Clauster port can verify the vulnerability by making a direct request to the /api/instances endpoint. Since the authentication guard evaluates auth.enabled as false, it does not prompt for user credentials.

A vulnerable instance returns an HTTP 200 OK status code and a JSON response detailing active projects. A secured instance returns an HTTP 401 Unauthorized status code or is unable to boot due to validation failures.

Once administrative endpoint access is established, the attacker can use the exposed API to list directory structures, view workspace logs, and spawn a Claude Code remote-control bridge. Because the Claude Code process runs commands in the context of the configured directories, the attacker achieves arbitrary command execution.

The security impact of this vulnerability is critical, leading to unauthorized code execution with the privileges of the process running Clauster. Successful exploitation yields complete control over the underlying environment and projects managed by the application.

Attackers can access sensitive environment variables, retrieve stored database credentials, manipulate project source code, and compromise the integrity of host files. Because the managed application integrates directly with Claude Code bridges, control over the dashboard acts as a gateway for local shell execution.

This vulnerability has been evaluated with a CVSS v4.0 score of 8.7, reflecting High impact on confidentiality, integrity, and availability. The threat model is highly applicable to deployments utilizing Docker containers, which often bind to 0.0.0.0 by default to handle inter-container network traffic.

The recommended remediation is to upgrade the Clauster installation to version v0.2.2 or higher. The updated configuration validator ensures the application will fail to launch if an insecure non-loopback binding is detected.

If upgrading is not immediately possible, operators must verify that auth.enabled is explicitly set to true inside clauster.yml. The configuration must combine this setting with valid credentials, as shown below:

# Secure configuration snippet
host: 0.0.0.0
port: 7621
auth:
  enabled: true
  password_required: true
  password_hash: "$argon2id$v=19$m=65536,t=3,p=4$..."

Additionally, restricting the application binding to loopback (127.0.0.1) minimizes the attack surface. For containerized deployments, mapping ports specifically to loopback addresses prevents external network exposure even if the internal container process binds to wildcard interfaces.