Beyond RCE, the application suffers from broken authorization on read-only endpoints, which remain accessible even when API_AUTH_KEY is configured. Additional vulnerabilities include an unrestricted file upload mechanism that allows attackers to write scripts (e.g., .py, .sh) to known paths, and a permissive CORS configuration that permits cross-origin requests from any local machine-served web application. These vulnerabilities, combined with the application's reliance on LLM tool-calling, present a high risk for data exfiltration and persistent malicious activity.

Attack Chain

1. Attacker performs discovery against an exposed Vibe-Trading instance on TCP port 8899.
2. Attacker confirms the lack of authentication by executing a POST request to /sessions without an Authorization header.
3. Attacker uses the /sessions endpoint to create a new session and obtain a session_id.
4. Attacker submits a crafted message to /sessions/{session_id}/messages containing a natural language prompt designed to trigger the BashTool.
5. The ReAct agent selects BashTool, which executes subprocess.run(command, shell=True) using the attacker-supplied input.
6. The command executes as root (UID 0) within the container environment, granting the attacker arbitrary code execution.
7. Attacker uses the RCE primitive to exfiltrate sensitive environment variables, LLM API keys, or broker tokens stored in the container memory or file system.

Impact

Successful exploitation leads to full container takeover and potential compromise of the host environment if proper container isolation is missing. An attacker can exfiltrate sensitive data, including LLM API keys and broker credentials used for automated trading. Given the application's functionality, this can result in unauthorized financial transactions or persistent access to the victim's trading accounts. The vulnerabilities affect all instances deployed with default settings using the provided docker-compose.yml.

Recommendation

Prioritize the immediate securing of all Vibe-Trading instances by enforcing authentication.

• Set a strong API_AUTH_KEY in the environment configuration and ensure the application is restarted with the new settings.
• Implement a USER directive in the Dockerfile to drop privileges from root to a non-privileged user.
• Restrict network access to the API server to trusted source IP addresses using firewall rules or container network policies.
• Block or monitor all HTTP requests to the /upload and /sessions endpoints that lack valid Authorization headers.