# GHSA-h4g2-xfmw-q2c9: Clauster: Non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset

> Unauthenticated attackers can execute code and escalate privileges on non-loopback deployments if auth.enabled is unset, despite password configuration.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 10 Jul 2026

## What is GHSA-h4g2-xfmw-q2c9?

GHSA-h4g2-xfmw-q2c9 is an authentication bypass vulnerability in clauster, published on 10 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

### Summary
A Clauster instance bound to a **non-loopback** address (e.g. `0.0.0.0` or a LAN IP) can serve the entire dashboard and its API **without any authentication** — even when the operator has configured a password — if `auth.enabled` is left at its default (`false`). The operator believes the instance is password-protected; in reality every request is served unauthenticated.

### Impact
An unauthenticated attacker with network access to the instance gains full control of the dashboard: list projects, **spawn/stop `claude remote-control` bridges in any project directory**, edit `CLAUDE.md`, read bridge logs, and (where configured) clone repositories. Because bridges run Claude Code against the host's project directories, this is effectively remote code execution in those projects.

Loopback (`127.0.0.1`) deployments need no auth by design and are **not** affected.

### Affected configurations
All released versions (≤ 0.2.1) where **all** of the following hold:
- `host` is a non-loopback address, **and**
- `auth.password_required: true` and/or `auth.reverse_proxy.enabled: true` is set, **and**
- `auth.enabled` is left at its default `false`.

Docker deployments are affected: the image binds `0.0.0.0`, and the previously-documented `docker run` command did not set `auth.enabled`.

### Root cause
Two layers checked different flags:
- The runtime auth guard enforces authentication only when `config.auth.enabled` is true; when false it passes **every** request through unauthenticated.
- The config validator, for a non-loopback bind, required only one of `auth.password_required` / `auth.reverse_proxy.enabled` / `auth.allow_unauthenticated_network` — **not** `auth.enabled`. So a config with a password but `enabled=false` validated, started, and enforced nothing.

### Proof of concept
With `host: 0.0.0.0`, `auth.password_required: true`, a valid `auth.password_hash`, and `auth.enabled` unset:

```
curl http://<host>:7621/api/instances
```

returns `200` with the full instance list and **no credentials**. Setting `auth.enabled: true` returns `401`.

### Patches
An upcoming patch release makes the config validator **fail closed**: a non-loopback bind is refused unless authentication is actually enforced — `auth.enabled: true` together with `auth.password_required` (+ a hash) or `auth.reverse_proxy.enabled`, or the explicit `auth.allow_unauthenticated_network` opt-out. The README, `clauster.yml.example`, and Docker docs were corrected to match.

### Workaround
On any non-loopback deployment, set `auth.enabled: true` in `clauster.yml` (or `CLAUSTER_AUTH_ENABLED=true`) alongside your existing `auth.password_required` + hash (or reverse-proxy) settings. Alternatively, bind to loopback only and reach it via an SSH tunnel or a trusted authenticating reverse proxy.

### Credit
Found during an internal security review.

## Which versions are affected by GHSA-h4g2-xfmw-q2c9?

2 open source packages ship an affected version, including clauster.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `clauster` | PyPI | All versions | 0.2.2 |
| `clauster` | PyPI | All versions | 0.2.2 |

## How do I fix GHSA-h4g2-xfmw-q2c9?

Upgrade clauster to 0.2.2 or later.

## Is GHSA-h4g2-xfmw-q2c9 being exploited?

There is no known exploitation of GHSA-h4g2-xfmw-q2c9 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-h4g2-xfmw-q2c9 and fix it if it is affected.

What it is: GHSA-h4g2-xfmw-q2c9 is an authentication bypass vulnerability in clauster, published on 10 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-h4g2-xfmw-q2c9 in the wild and no public exploit code.

Affected packages and fixed versions:
- clauster (PyPI): affected all versions; fixed in 0.2.2
- clauster (PyPI): affected all versions; fixed in 0.2.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/ (Markdown: https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-h4g2-xfmw-q2c9

---
From sbomify Insights: https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/
Summaries are generated and may contain mistakes; the official description above is the record.