GHSA-RM43-82J9-R4MJ: Path Traversal (Arbitrary File Read) in atomic-agents-stack Dashboard

The optional dashboard HTTP server included in the atomic-agents-stack Python package exposes an attack surface that permits unauthenticated arbitrary file reads. The affected component is located in atomic_agents/dashboard/serve.py and is implemented via DashboardHandler, a subclass of BaseHTTPRequestHandler. When enabled, this server is designed to host static HTML assets and render dynamic agent interaction logs.

The vulnerability lies within the endpoint routing mechanisms that process incoming HTTP GET requests. Because the server fails to restrict access to the designated static and agent asset directories, any network-adjacent or remote attacker with access to the dashboard port can manipulate file paths. This results in a classic Path Traversal vulnerability (CWE-22) that allows the extraction of sensitive configuration files, system files, and environment specifications.

Exploitation does not require authentication or active session state, elevating the impact to high-severity. Although the server binds to the local loopback interface by default, configuration options permit exposing the service on all network interfaces. Additionally, the service remains susceptible to exploitation via Server-Side Request Forgery or DNS rebinding techniques even when restricted to loopback.

The root cause of this vulnerability is the insecure resolution of filesystem paths within the do_GET handler of DashboardHandler. Specifically, when requests are directed to the /agents/ or /_dashboard/ paths, the server retrieves file paths by appending the user-supplied URI string directly to the self.agents_root base path. This concatenation is performed using Python's pathlib.Path division operator without sanitizing or canonicalizing the resulting target path.

While pathlib provides structured path representations, appending paths containing directory traversal sequences (such as ../) does not raise an exception. Instead, the traversal sequences remain embedded within the path object. When the handler invokes filesystem methods like exists() or is_file() on the unsanitized Path object, the underlying operating system resolves the relative traversal segments, allowing the path to escape the intended directory boundary.

Because there are no containment checks, an HTTP request pointing to /etc/passwd via traversal escapes the sandbox seamlessly. This dynamic is illustrated in the logical diagram below, showcasing how a validation omission allows the directory escape sequence to interact directly with the host filesystem.

In vulnerable versions up to and including 1.0.0, the routing logic uses direct string manipulation and unsafe joins. The do_GET method handles requests targeting /agents/ by stripping the prefix and then appending the remaining string directly to self.agents_root. This direct trust in the URL path is demonstrated in the following vulnerable snippet:

if path.startswith("/agents/"):
    agent_name = path[len("/agents/"):].rstrip("/")
    # UNSAFE: Direct concatenation allows traversal via agent_name
    self._serve_file(self.agents_root / agent_name / "dashboard.html", "text/html")
    return

In the patched version 1.1.0 (commit ec474f458122c5c0ca718d0df3078c8080338b2c), the developer implemented a rigorous containment check using a custom helper function named safe_resolve_under. This helper ensures that the resolved target is situated strictly within the expected parent directory. The updated path-resolution flow handles /agents/ requests securely:

if path.startswith("/agents/"):
    agent_name = path[len("/agents/") :].rstrip("/")
    # Early explicit check for path traversal indicators
    if "/" in agent_name or "\\" in agent_name or ".." in agent_name:
        self.send_error(404, "Not found")
        return
    try:
        # Enforces absolute directory containment
        resolved = safe_resolve_under(agent_name, self.agents_root)
    except PathTraversalError:
        self.send_error(404, "Not found")
        return
    self._serve_file_contained(resolved / "dashboard.html", "text/html")
    return

The fix is comprehensive because it combines multiple defense layers. It performs an early rejection of common path separation symbols to minimize side-channel variations, followed by strict canonicalization using safe_resolve_under. This methodology resolves symbolic links before comparing the target path with the base directory, eliminating symlink bypasses.

An attacker can exploit this vulnerability using basic network utilities such as curl or wget. The exploitation requirements depend on the server configuration and network placement. If the dashboard server is configured to bind to 0.0.0.0, it is directly reachable over the network on port 8765, which allows unauthenticated external access.

To execute the attack, the adversary must construct an HTTP GET request containing directory traversal sequences that target a known system file. Using the --path-as-is flag with curl ensures that the local client does not resolve the relative path segments before transmitting the request to the target server. The target path climbs out of the dashboard directory structure to reach administrative system files.

A typical exploit payload targets the local configuration files or operating system user databases. For instance, sending a request to /_dashboard/../../../../etc/passwd forces the server to traverse up the directory structure and return the contents of the /etc/passwd file. The server processes the request, locates the file, and streams its content back to the client with an HTTP 200 OK status code.

The impact of this path traversal flaw is classified as high-severity with a CVSS v4.0 base score of 8.2. Since the server runs with the permissions of the user starting the Python application, an attacker can retrieve any file that this user has read access to. This typically includes sensitive application source code, API keys, private configuration files, database credentials, and local system configurations.

A secondary impact involves the leakage of deployment environment details that can facilitate subsequent attacks. For example, reading files such as /proc/self/environ, .env, or configuration files within the application root exposes cryptographic secret keys and access tokens. These leaked credentials can lead to complete host or API account compromise if the keys are reused elsewhere.

Because the service lacks write capabilities or destructive file actions, the integrity and availability of the host remain unaffected. However, the high confidentiality impact presents significant risk to deployments. This risk is especially elevated in cloud container environments where service account tokens are often stored at predictable filesystem paths.

The primary remediation strategy is to upgrade the atomic-agents-stack library to version 1.1.0 or greater. This version incorporates the safe_resolve_under verification utility across all endpoints in the dashboard implementation, which effectively neutralizes path traversal attempts. Upgrades can be performed directly through the Python package installer pip.

In environments where an immediate package upgrade is not feasible, several temporary mitigation techniques can reduce risk. Administrators must ensure the dashboard server is configured to bind strictly to the loopback interface (127.0.0.1) rather than 0.0.0.0, thereby limiting the direct network attack surface. Access control lists or local host firewalls should be implemented to drop traffic to port 8765 from external networks.

Additionally, running the Python process under a dedicated, low-privilege system user account conforms to the principle of least privilege. This configuration prevents the server from reading highly sensitive system files (such as /etc/shadow) even if a path traversal request successfully traverses out of the application root. Developers should also verify that symbolic links within the static asset folders do not point to directories outside the designated root.