- A GitHub advisory says two Vibe-Trading file-reading tools let an AI agent open files such as /etc/shadow and API keys, because path checks are too wide or missing.
- The advisory notes shell-focused monitoring would miss this route, and that the shipped container runs as root, which widens the exposure.
- Teams running AI agents should list which folders each tool may open, run agents as non-root, and keep secrets out of reach.
Security teams spend years learning to watch for an attacker running commands on a server. A new advisory on the Vibe-Trading project describes a different route. The attacker asks the AI agent to read the file, and the agent does it.
The lesson here is that an AI tool's permissions are only as tight as the check written into each tool. If that check is loose or missing, the agent becomes a file reader for anyone who can talk to it.
What the advisory found
The GitHub Advisory Database published GHSA-5rmq-chc7-m22f on October 2, 2026. It covers Vibe-Trading, an open-source project from HKUDS. The advisory describes two findings, both rated High. The advisory text provided shows no CVE ID.
The first, labelled F9, is a path check that is too wide. A function called safe_user_path() is meant to let tools open broker export files. In practice it accepts any path under the home directory or the working directory.
In the shipped Docker container, those resolve to /root and /app. So SSH keys, AWS credentials, Kubernetes config and the agent's own .env file all pass the check. The advisory says that file holds the operator's real OPENROUTER_API_KEY and TUSHARE_TOKEN.
The second, labelled F10, is a check that is missing. The read_document() function takes a file path from the AI model and confirms only that the file exists. It never calls a sandbox check. So the function will hand back the complete contents of whatever file the server process is allowed to open.
The advisory calls F10 strictly broader than F9. F9 stops at /root and /app. F10 has no boundary at all.
How the leak works
For F10, the advisory's probe was direct. read_document('/etc/passwd') returned 839 characters. /etc/shadow came back in full. /proc/self/environ returned the whole process environment, with API keys in plaintext.
F9 leaks more quietly. The advisory tested a planted fake credential file passed to a tool that expects a trade journal. The tool failed to parse it. Its error message contained the first line of the file. That is the parse-error channel: the failure message itself carries the data out.
The container makes this worse. The advisory notes the Dockerfile has no USER directive, so the web process runs as root. Root can read nearly everything.
Why reach matters
The advisory says these tools are reachable by any anonymous client on port 8899 when combined with another finding in the same set, GHSA-1 (F1). It also says the same defects apply to logged-in sessions. They also apply to prompt injection, where hidden instructions in a document the agent processes steer it.
The reproduction steps assume a working LLM API key and the shipped Docker setup. Deployments that differ from that setup may differ in exposure.
The advisory makes a point security leaders should note. Because no shell is involved, endpoint monitoring tuned to BashTool or shell signatures will miss this credential-extraction path.
Why fixing one is not enough
A maintainer might patch only F10, since it is the broader flaw. The advisory argues against that. Adding the safe_user_path check to read_document would still leak /root, because that check itself is too wide.
The advisory's recommended fixes have three parts. First, replace the home-and-working-directory rule with a strict allowlist, such as a dedicated broker exports folder. Second, add the missing check in read_document. Third, run the process as a non-root user. The advisory says that last step does not fix the traversal but reduces the damage of a successful exploit.
What leaders should ask
This applies to any team running an AI agent with file tools, not only this project.
Ask your team which files each agent tool can open. The answer should be a short list of named folders, not whatever the process can see.
Ask whether the agent's container runs as root. Ask whether API keys sit in the process environment or in files under the agent's reach.
Ask whether monitoring would notice a file read made through an AI tool rather than a shell. If the answer is no, the detection gap is real.
An AI agent acts with the authority of the process that runs it. Give that process the smallest reach you can, and treat every tool as a door that needs its own lock.
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.
