GHSA-v2f8-6655-7grj: Remote Code Execution and Authentication Bypass in vibe-trading-ai

The vibe-trading-ai software is an automated cryptocurrency and financial trading framework designed to integrate artificial intelligence agent loops into real-time trading environments. The platform relies on a backend API server built on FastAPI to process strategy commands, configure active LLMs, and track backtesting execution. This backend exposes an API surface on port 8899 that interfaces with both the local user interface and background task executors.

In versions prior to 0.1.7, the default deployment architecture exposed a highly vulnerable attack surface. The software configured a fail-open security mechanism where authorization was bypassed if an environment secret was omitted. Furthermore, the default configuration files mapped the API port to all network interfaces (0.0.0.0) without restricting external traffic.

The resulting vulnerability footprint allows unauthenticated attackers to systematically exploit the application. Attackers can execute arbitrary terminal operations, retrieve historical trading databases, and overwrite core application modules. This occurs due to the execution of the agent container as root, combined with the lack of access controls on critical endpoints.

The primary root cause resides within the authentication dependency implemented in agent/api_server.py. The function require_auth() was designed to inspect incoming HTTP requests for credentials. However, it evaluated the presence of the system-wide secret key before performing validation. If the API_AUTH_KEY environment variable was empty or commented out in the configuration files, the function returned None instead of raising an HTTP exception.

Because the distributed .env.example file contained a commented-out authorization key, most standard installations defaulted to an unauthenticated mode. This fail-open logic meant that any client could access routes decorated with authentication dependencies. Simultaneously, the development team implemented read endpoints (GET routes) without adding authorization controls, allowing unauthorized data access even when write operations were secured.

The ultimate mechanism for arbitrary code execution relies on the application's design as an autonomous agent. The framework exposes a BashTool within the agent loop to execute operating system commands. This tool executes raw strings using python's subprocess.run(shell=True). By sending a natural language prompt instructing the agent to run a shell command, an unauthenticated network observer can execute commands inside the host environment.

A technical evaluation of the differences between the vulnerable code and the official patch in commit 9454d4a27a763b80e1d6eb5763b86c88e9e4e714 reveals a multi-layered security hardening strategy. The vulnerability in agent/api_server.py was remediated by rewriting the authentication verification logic to reject connections when the API key is not configured.

# Vulnerable authentication implementation (pre-0.1.7)
def require_auth(cred: HTTPAuthorizationCredentials = Security(_security)):
    api_key = _configured_api_key()
    if not api_key:
        return  # Fail-open: returns None and allows access if unset
    if not cred or cred.credentials != api_key:
        raise HTTPException(status_code=401, detail="Invalid or missing API key")

# Patched authentication implementation (0.1.7)
def _validate_api_auth(
    *,
    request: Request,
    cred: Optional[HTTPAuthorizationCredentials],
    query_api_key: Optional[str] = None,
    allow_query: bool = False,
) -> None:
    api_key = _configured_api_key()
    if not api_key:
        if _is_local_client(request):
            return  # Permits local loopback development only
        raise HTTPException(
            status_code=status.HTTP_403_FORBIDDEN,
            detail="API_AUTH_KEY is required for non-local API access",
        )
 
    token = _auth_credential_from_header_or_query(cred, query_api_key, allow_query=allow_query)
    if not token or not hmac.compare_digest(token, api_key):
        raise HTTPException(status_code=401, detail="Invalid or missing API key")

Additionally, the developers implemented an Abstract Syntax Tree (AST) validation checker inside agent/backtest/runner.py via _validate_signal_engine_source. This mechanism parses Python files prior to import to confirm they do not contain top-level execution statements. This mitigates the risk of running unauthorized actions through backtesting modules. Finally, the Dockerfile was updated to run under a non-root system user named vibe instead of defaulting to root root permissions.

To execute commands on a vulnerable instance, an attacker must first locate an exposed endpoint on port 8899. Because of the open port binding configuration, this can be achieved using a standard network scanner. Once a host is identified, the attacker initiates a stateful session and triggers the execution chain through the agent's interactive interfaces.

First, the attacker creates an active session using the /sessions route:

curl -s -X POST http://<target>:8899/sessions \
  -H 'Content-Type: application/json' \
  -d '{}'

The server responds with a JSON payload containing a unique session identifier (session_id). The attacker uses this identifier to send a malicious instructions object to the agent loop via the message endpoint. The instructions request that the agent process a command using the system terminal:

curl -s -X POST "http://<target>:8899/sessions/<session_id>/messages" \
  -H 'Content-Type: application/json' \
  -d '{"content":"Please use the shell execution tool to run the command: id && cat /etc/passwd"}'

Because the agent executes inside a Docker container configured without a designated USER field, the payload runs with root administrative rights. The attacker can then request the resulting terminal output by querying the messages log endpoint GET /sessions/<session_id>/messages after a brief processing interval.

The impact of this vulnerability is critical. Successful exploitation gives an unauthenticated remote attacker complete administrative control over the host running the application. Attackers can execute commands, steal credentials, and compromise downstream services connected to the container.

Since the software is used for algorithmic trading, the target container typically stores high-value assets. These assets include API secret keys for exchanges, active private keys for web3 wallets, and database records containing historical transaction records. Access to these resources allows attackers to steal funds or disrupt automated trading systems.

The vulnerability also exposes host networks to further compromise. Attackers can leverage the compromised container as a pivot point to map, scan, and attack other systems within the private internal network. The high risk is reflected in the perfect CVSS base score of 10.0.

Securing a deployment requires updating the installation packages and hardening network configurations. Users should upgrade the application package to version 0.1.7 or later to implement the authentication and filesystem controls. This can be accomplished through standard pip upgrade processes.

pip install --upgrade vibe-trading-ai

In addition to the software upgrade, developers must modify deployment configurations. The docker-compose.yml file should be updated to restrict access to port 8899. Binding the port explicitly to the local loopback address (127.0.0.1:8899:8899) prevents external systems from communicating with the API endpoint.

Finally, users must configure a strong API key in the environment variables. Setting the API_AUTH_KEY variable with a high-entropy secret ensures the API validates authorization headers for all external requests. If shell execution features are not required, administrators should disable them by setting VIBE_TRADING_ENABLE_SHELL_TOOLS=0 in the environment configuration.