Clauster Dashboard Unauthenticated Access Vulnerability
A Clauster instance deployed on a non-loopback address can be accessed unauthenticated, even if password protection is configured, due to auth.enabled defaulting to false. This allows an attacker with network access to gain full control of the dashboard, including listing projects, spawning remote-control bridges, editing files, reading logs, and cloning repositories, ultimately leading to remote code execution in project directories.
A high-severity vulnerability (GHSA-h4g2-xfmw-q2c9) has been disclosed in Clauster, a project management and automation tool. Versions up to and including 0.2.1 are affected. The vulnerability allows an unauthenticated attacker with network access to gain full control over the Clauster dashboard and its API, even if the operator believes the instance is password-protected. This occurs when Clauster is bound to a non-loopback address (e.g., 0.0.0.0 or a local area network IP) and the auth.enabled configuration flag is left at its default false value. This misconfiguration bypasses all intended authentication checks, enabling an attacker to manipulate projects, execute arbitrary code via claude remote-control bridges, and potentially exfiltrate sensitive data. Docker deployments are particularly susceptible as the official image binds to 0.0.0.0 by default, and previous documentation did not explicitly advise setting auth.enabled.
Attack Chain
- Attacker identifies a Clauster instance exposed on a non-loopback network interface (e.g.,
0.0.0.0or a LAN IP). - Attacker sends an unauthenticated HTTP GET request to a sensitive API endpoint, such as
http://<host>:7621/api/instances. - The Clauster instance responds with a
200 OKstatus code and the requested data, effectively bypassing the intended authentication mechanism due to theauth.enabled: falsemisconfiguration. - Attacker gains full control over all Clauster dashboard functionalities, including listing projects, accessing project details, and manipulating configurations.
- Attacker spawns
claude remote-controlbridges within targeted project directories on the Clauster host. - Attacker leverages the
claude remote-controlbridge to execute arbitrary Claude Code, achieving remote code execution (RCE) on the host system within the context of the project. - Attacker can then edit
CLAUDE.md, read bridge logs, or clone configured repositories, leading to data exfiltration or further system compromise.
Impact
Successful exploitation allows an unauthenticated attacker with network access to achieve full administrative control over the Clauster dashboard. This includes the ability to list projects, spawn and stop claude remote-control bridges, edit project files such as CLAUDE.md, read bridge logs, and clone repositories where configured. Critically, because claude remote-control bridges execute Claude Code against the host's project directories, this misconfiguration effectively grants the attacker remote code execution capabilities on the underlying system. This can lead to complete compromise of the host, data theft, and further network intrusion. Loopback deployments (127.0.0.1) are not affected by this specific vulnerability.
Recommendation
- Immediately update all Clauster instances to the latest patch release once available, as it will enforce stricter configuration validation to prevent this misconfiguration.
- Apply the documented workaround by ensuring
auth.enabled: trueis explicitly set in yourclauster.ymlfile or via theCLAUSTER_AUTH_ENABLED=trueenvironment variable for all non-loopback deployments. - Verify that unauthenticated access to
http://<host>:7621/api/instancesreturns a401 Unauthorizedstatus code after applying the workaround.
Indicators of compromise
1
url
| Type | Value |
|---|---|
| url | http://<host>:7621/api/instances |