- Per a GitHub advisory, Vibe-Trading's default setup lets anyone reaching port 8899 run commands as root inside its container, once an LLM key is configured.
- Authentication is off unless the operator sets a key. Even then, the advisory says read endpoints stay open, so session history can be read without a login.
- Before deploying any AI agent, ask whether it can run commands, whether it starts with authentication on, and what it runs as.
When the chat box is a shell
An AI agent that can run commands changes what a missing password means. A normal web app without a login exposes data. An agent without a login exposes whatever the agent is allowed to do.
That is the lesson in a new GitHub advisory, GHSA-v2f8-6655-7grj, published on October 2. It covers Vibe-Trading, an AI agent project with a FastAPI server. The advisory lists five findings. The most serious chains a missing login to a shell running as root inside the project's container.
How the chain works
The server checks logins through a function called require_auth(). The advisory says that when the setting API_AUTH_KEY is empty, the function returns immediately and checks nothing. The example configuration file ships with that setting commented out.
Two other defaults widen the damage. The Dockerfile has no USER directive, so the server runs as root inside its container. The shipped compose file also publishes the server on port 8899 across every network interface, with no limit on who may connect.
From there, the advisory describes three requests, none carrying credentials. The caller creates a session. The caller posts a message asking the agent to run a command. The agent then chooses a built-in command tool, BashTool, and passes the text the model wrote straight to a shell.
The advisory's test asked for 'id && uname -a' and got back uid=0(root). Its conclusion is that the caller controls the whole container. One condition applies: the operator must supply a working LLM key. Any functioning deployment needs one, so the advisory treats this as ordinary setup, not an extra security choice.
Turning auth on is not the whole fix
The second finding matters most to teams that did the right thing. The advisory traces it to a design choice noted in the code. Login checks guard only actions that change something: creating, updating or deleting. Reading is left open.
In the advisory's test, API_AUTH_KEY was set. A message containing a fake broker token was posted with a valid Bearer token. A later request with no Authorization header returned HTTP 200 and the token in plain text.
The advisory warns that operators may paste broker tokens, LLM keys or trading account details into prompts. Those would be readable by anyone who can reach the server. The same gap exposes the run records and their prompts.
Three smaller gaps that add up
The upload endpoint blocks file types such as .exe and .zip. It does not block .py, .sh or .yaml. It also returns the saved file's full path, so an attacker need not guess where it landed. The advisory says this needs no LLM key.
The cross-origin setup trusts six localhost addresses and allows credentialed requests. Some settings pages are meant to be reachable only from the same machine. The code decides that by reading the network address of whoever connected. A browser on that machine always shows up as 127.0.0.1, whatever page it is displaying. The advisory says a malicious page on a whitelisted local port could then drive the API from the operator's browser. That is a risk for developers who run the agent on their own workstation.
The settings endpoint also shows the first four and last four characters of each API key. The advisory says this can matter for keys with limited randomness, such as Tushare tokens.
What this shows
The pattern here is a safe default that was left to the operator. Authentication was optional, root was the default user, and the port was open to the network. Each choice is ordinary on its own. Together, once an LLM key is set, they hand a root shell in the container to anyone who can connect.
Agents raise the cost of that kind of convenience. The model turns a plain sentence into a command, so the login is the main barrier once the port is reachable.
The advisory's excerpt does not say whether a patched release exists. It also reports no attacks in the wild. Teams using the project should check the advisory page directly.
Questions to put to your team
First, ask for a list of every AI agent or agent framework running in your environment, including developer laptops and test servers. Ask which ones can execute commands or write files.
Second, ask whether each one starts with authentication enforced. A blank key should stop the server from starting, not switch checks off.
Third, ask what user each agent runs as and which networks can reach it. Agents should run without root and sit behind private network rules.
Fourth, ask whether read access is protected as well as write access. Prompts can hold credentials, so session history deserves the same protection as the tools.
An agent that can act on your systems should be treated as a privileged account. It needs a login before it needs a feature list.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
