{"answers":{"affected":"2 open source packages ship an affected version, including clauster.","exploited":"There is no known exploitation of GHSA-h4g2-xfmw-q2c9 in the wild and no public exploit code.","fix":"Upgrade clauster to 0.2.2 or later.","what":"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."},"fix_prompt":"Check this codebase for GHSA-h4g2-xfmw-q2c9 and fix it if it is affected.\n\nWhat 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.\nExploitation: There is no known exploitation of GHSA-h4g2-xfmw-q2c9 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- clauster (PyPI): affected all versions; fixed in 0.2.2\n- clauster (PyPI): affected all versions; fixed in 0.2.2\n\nTask:\n1. 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.\n2. 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.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/ (Markdown: https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/index.md)","id":"GHSA-h4g2-xfmw-q2c9","markdown":"https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/index.md","name":"GHSA-h4g2-xfmw-q2c9","record":{"aliases":[],"analysis":{"component_type":"server_software","fix_type":"configuration_change","impacts":["code_execution","privilege_escalation"],"network_reachable":"yes","non_default_config":true,"product_category":"Claude Code dashboard","requires_auth":"none","summary":"Unauthenticated attackers can execute code and escalate privileges on non-loopback deployments if auth.enabled is unset, despite password configuration.","user_interaction":"not_required","vuln_class":"auth_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### 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://\u003chost\u003e: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.","ecosystems":["PyPI"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Clauster: Non-loopback deployments can serve the dashboard unauthenticated when auth.enabled is unset","id":"GHSA-h4g2-xfmw-q2c9","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"auth_bypass","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"PyPI","fixed":["0.2.2"],"introduced":["0"],"last_affected":[],"package":"clauster","purl":null,"source":"GHSA-h4g2-xfmw-q2c9"},{"ecosystem":"PyPI","fixed":["0.2.2"],"introduced":["0"],"last_affected":[],"package":"clauster","purl":"pkg:pypi/clauster","source":"GHSA-h4g2-xfmw-q2c9"}],"products":null,"published":"2026-07-10","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Unauthenticated attackers can execute code and escalate privileges on non-loopback deployments if auth.enabled is unset, despite password configuration.","url":"https://insights.sbomify.com/GHSA-h4g2-xfmw-q2c9/"}