Vulnerabilities in pkg:pypi/clauster

PACKAGE
Advisory Summary

GHSA-h4g2-xfmw-q2c9 is a HIGH non-loopback deployments can serve the vulnerability (CWE-306: Missing Authentication for Critical Function) affecting Clauster libraries in the PyPI ecosystem. The issue involves non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset. Remediation is available by upgrading affected packages to version 0.2.2.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/clauster

1 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:pypi/clauster. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-h4g2-xfmw-q2c9 - HIGH Clauster: Non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset

GHSA-h4g2-xfmw-q2c9 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-h4g2-xfmw-q2c9
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-306: Missing Authentication for Critical Function
Affected Product Clauster
Package Ecosystem PyPI
Published Date
Last Updated

How to Fix GHSA-h4g2-xfmw-q2c9

To remediate this vulnerability, upgrade all affected Clauster dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

clauster fixed: 0.2.2
pip install clauster>=0.2.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show clauster

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-h4g2-xfmw-q2c9, inspect your installed packages using pip:

pip show clauster

Analyze the terminal output to locate any version of Clauster in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.2.2), your application is affected.

Note: The pip show clauster command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-306: Missing Authentication for Critical Function, where the product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. In Clauster, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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.

GHSA-h4g2-xfmw-q2c9 Affected Clauster Versions

1 component(s)
Fixed Versions:
0.2.2
Product / Package Ecosystem Affected Versions Fixed Version
clauster
PyPI
< 0.2.2
0.2.2

References

Frequently Asked Questions

What is GHSA-h4g2-xfmw-q2c9?
GHSA-h4g2-xfmw-q2c9 is a security vulnerability in Clauster involving Non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset under CWE-306: Missing Authentication for Critical Function.
Which Clauster versions are affected?
Affected versions include releases prior to 0.2.2 across affected packages: clauster.
What version fixes GHSA-h4g2-xfmw-q2c9?
Upgrading to 0.2.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is clauster affected?
Yes, clauster is affected in releases prior to 0.2.2. Upgrade your dependency to 0.2.2 or later.
What CWE is associated with GHSA-h4g2-xfmw-q2c9?
GHSA-h4g2-xfmw-q2c9 is classified under CWE-306: Missing Authentication for Critical Function (The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.).
How can I check PyPI dependencies for GHSA-h4g2-xfmw-q2c9?
Run the dependency tree command: 'pip show clauster'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-h4g2-xfmw-q2c9",
  "modified" : "2026-07-10T20:37:23Z",
  "published" : "2026-07-10T20:37:23Z",
  "aliases" : [ ],
  "summary" : "Clauster: Non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset",
  "details" : "### Summary\nA 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.\n\n### Impact\nAn 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.\n\nLoopback (`127.0.0.1`) deployments need no auth by design and are **not** affected.\n\n### Affected configurations\nAll released versions (≤ 0.2.1) where **all** of the following hold:\n- `host` is a non-loopback address, **and**\n- `auth.password_required: true` and/or `auth.reverse_proxy.enabled: true` is set, **and**\n- `auth.enabled` is left at its default `false`.\n\nDocker deployments are affected: the image binds `0.0.0.0`, and the previously-documented `docker run` command did not set `auth.enabled`.\n\n### Root cause\nTwo layers checked different flags:\n- The runtime auth guard enforces authentication only when `config.auth.enabled` is true; when false it passes **every** request through unauthenticated.\n- 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.\n\n### Proof of concept\nWith `host: 0.0.0.0`, `auth.password_required: true`, a valid `auth.password_hash`, and `auth.enabled` unset:\n\n```\ncurl http://<host>:7621/api/instances\n```\n\nreturns `200` with the full instance list and **no credentials**. Setting `auth.enabled: true` returns `401`.\n\n### Patches\nAn 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.\n\n### Workaround\nOn 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.\n\n### Credit\nFound during an internal security review.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "clauster"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.2.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.2.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/schubydoo/clauster/security/advisories/GHSA-h4g2-xfmw-q2c9"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/schubydoo/clauster"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-306" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-10T20:37:23Z",
    "nvd_published_at" : null
  }
}