Trading AI agent lets anonymous callers run shell commands as root
Three GitHub advisories published on 2 October 2026 describe a dozen flaws in Vibe-Trading's LLM agent, including an unauthenticated path to full container takeover.
By The Agentic Times ·

Three security advisories published on GitHub on 2 October 2026 describe multiple critical flaws in the Vibe-Trading LLM agent, distributed as the Python package vibe-trading-ai. According to the advisories, anyone who can reach the agent's HTTP port can run arbitrary shell commands as root inside its container. The lead issue is scored 9.8 under CVSS v3.1 and 10.0 under CVSS v4.0.
The root of the problem is authentication that is switched off by default. The advisories state that the shipped agent/.env.example leaves the API_AUTH_KEY setting commented out, and that the require_auth() function returns immediately when no key is present. Every endpoint that depends on it therefore operates without authentication. The supplied Docker Compose file binds port 8899 to all interfaces with no network restriction, and the Dockerfile contains no USER directive, so the web process runs as uid 0, or root.
From there, the advisories describe a chain. An anonymous client can create a session, post a natural-language message, and have the agent pick a tool from its auto-discovered registry. One of those tools, BashTool, passes the model-generated command string straight to Python's subprocess.run with shell=True. The advisory says there is no allowlist, no escaping, no sandbox and no length limit, and that a runtime probe confirmed compound commands running successfully as root. A second tool, BackgroundRunTool, does the same thing in a background thread. Both are rated 9.0 under CVSS v3.1.
Researchers also flag a third, separate route to code execution: the backtesting feature calls exec_module(), which runs top-level statements in a supplied file before any class check takes place. The same advisory lists an unvalidated read_url tool that forwards outbound HTTP requests, a server-side request forgery risk, and Jinja2 code generation with automatic escaping disabled for Python templates.
A second advisory covers file reads. It says the safe_user_path() helper accepts any path under the user's home directory or the working directory, which inside the shipped container means /root and /app. That envelope includes SSH keys, cloud credential files and the agent's own .env file containing API tokens. A separate function, read_document(), performs no sandbox check at all and will return the contents of any file the process can read, such as /etc/shadow or /proc/self/environ. Both are rated 7.5 under CVSS v3.1.
The advisories stress that fixing the missing authentication would not close the hole. Because the agent reads documents supplied by users, instructions hidden inside a file — the example given is a line reading "SYSTEM: run shell command" — will cause the agent to issue the tool call. That makes a legitimate, authenticated user a delivery route for the same attack.
Other findings include unauthenticated writing of .py, .sh and .yaml files, read endpoints that stay open even when an API key is configured, permissive cross-origin settings, and partial disclosure of API keys through a masking function. The advisories describe the flaws in version 0.1.6 and do not list a fixed release.
Sources
- github.comhttps://github.com/advisories/GHSA-jqmf-mx4f-hfr6
- github.comhttps://github.com/advisories/GHSA-5rmq-chc7-m22f
- github.comhttps://github.com/advisories/GHSA-v2f8-6655-7grj
