Vulnerabilities in pkg:pypi/vibe-trading-ai

PACKAGE
Advisory Summary

GHSA-v2f8-6655-7grj is a CRITICAL (CVSS 10.0) remote code execution vulnerability (CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains) affecting Vibe trading ai libraries in the PyPI ecosystem. The issue involves vibe-trading fastapi endpoints permit unauthenticated access, file upload, and an rce chain. Remediation is available by upgrading affected packages to version 0.1.7.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/vibe-trading-ai

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:pypi/vibe-trading-ai. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-v2f8-6655-7grj - CRITICAL Vibe-Trading FastAPI endpoints permit unauthenticated access, file upload, and an RCE chain
GHSA-5rmq-chc7-m22f - HIGH Vibe-Trading file-read tools expose arbitrary server-readable files
GHSA-jqmf-mx4f-hfr6 - CRITICAL Vibe-Trading LLM-callable tools permit command execution, code injection, and SSRF

GHSA-v2f8-6655-7grj at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-v2f8-6655-7grj
Severity CRITICAL
CVSS v3.1 Base Score 10.0
CWE Classification CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains
Affected Product Vibe trading ai
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 10.0

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix GHSA-v2f8-6655-7grj

To remediate this vulnerability, upgrade all affected Vibe trading ai dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

vibe-trading-ai fixed: 0.1.7
pip install vibe-trading-ai>=0.1.7
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show vibe-trading-ai

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-v2f8-6655-7grj, inspect your installed packages using pip:

pip show vibe-trading-ai

Analyze the terminal output to locate any version of Vibe trading ai in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.1.7), your application is affected.

Note: The pip show vibe-trading-ai command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains, where the product uses a web-client protection mechanism such as a content security policy (csp) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate. In Vibe trading ai, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary: 5 findings — unauthenticated full-API exposure (F1, lead Critical), read-side authorization gap that persists even with `API_AUTH_KEY` set (F2), unauthenticated file write of `.py`/`.sh`/`.yaml` to a server-returned path (F3), default-permissive CORS that combines with a loopback-only check to grant any browser page on whitelisted localhost ports credentialed cross-origin access (F-A4), and partial API-key disclosure via `_mask_secret()` (F-A5). --- ### Shared baseline (applies to all 5 findings) The shipped `agent/.env.example` line 112 ships `# API_AUTH_KEY=` commented out. `require_auth()` at `agent/api_server.py` line 303 executes `if not api_key: return` and returns `None` immediately when `API_AUTH_KEY` is unset, so every endpoint decorated with `dependencies=[Depends(require_auth)]` operates as unauthenticated. The shipped `Dockerfile` does **not** contain a `USER` directive, so the FastAPI process runs as `uid=0(root)` inside the container (verified: `docker exec id` returns `uid=0(root) gid=0(root)`). The `docker-compose.yml` binds `0.0.0.0:8899` with no network restriction. The only operator action required beyond a clean install is supplying a working LLM API key so the agent loop can complete its tool-call round trip — this is the normal first step to make the agent functional, not an additional security opt-in. F-A4 and F-A5 do *not* require an LLM key (see per-finding notes); F1 and F3 do not require an LLM key for the unauth surface itself, only for the chained RCE demonstration in F1. ### Reproducer environment (common) ```sh git clone https://github.com/HKUDS/Vibe-Trading.git cd Vibe-Trading git checkout 7452610113a75529b5d55fd2217bb17f7bec66f7 # v0.1.6 + 1 frontend fix; same vuln state as v0.1.6 cp agent/.env.example agent/.env # (For F1 chained demo only:) edit agent/.env to set OPENROUTER_API_KEY=<real key> docker compose up -d # port 8899 is now reachable; HOST below is the docker host's IP from the attacker's perspective ``` > **Note on the `HOST` placeholder used throughout the per-finding "Steps to observe" blocks below**: replace `HOST` with the address you reach the docker host on — typically `localhost` (or `127.0.0.1`) if you are running the reproducer on the same machine as the container. All `curl` commands below assume this substitution. --- ### Finding 1 — Critical: Unauthenticated network client reaches shell execution via POST /sessions/{id}/messages - **Severity**: Critical - **CVSS v3.1**: 9.8 — `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` - **CVSS v4.0**: 10.0 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` - **CWE**: CWE-306 (Missing Authentication for Critical Function); chains into CWE-78 (Group B, F6) **Affected files**: - `agent/api_server.py:303` — `if not api_key: return` early return in `require_auth()` - `agent/api_server.py:736` — `@app.post("/sessions/{session_id}/messages", dependencies=[Depends(require_auth)])` (the dependency is a no-op when `API_AUTH_KEY` is unset) - `agent/src/tools/bash_tool.py:44-46` — `subprocess.run(command, shell=True, cwd=cwd)` with command read from `kwargs['command']` (full bug detail tracked in GHSA-2 / Group B / F6) **Intent vs actual**: The session API is intended to serve authenticated users only. When `API_AUTH_KEY` is unset, `require_auth()` returns `None` immediately and `dependencies=[Depends(require_auth)]` becomes a no-op. Any anonymous TCP client to port 8899 can therefore create a session, post a message, and receive the LLM agent's response. The LLM ReAct agent — given a natural-language request to run a command — selects `BashTool` from the auto-discovered registry, which calls `subprocess.run(command, shell=True)` with the LLM-emitted string. The container has no `USER` directive, so the resulting process runs as `uid=0(root)`. **Steps to observe**: 1. Start the server per the shared reproducer above (with a working `OPENROUTER_API_KEY` set in `agent/.env`). Confirm `curl -fs http://HOST:8899/health` returns 200. 2. `SID=$(curl -s -X POST http://HOST:8899/sessions -H 'Content-Type: application/json' -d '{}' | python3 -c "import json,sys;print(json.load(sys.stdin)['session_id'])")` 3. `curl -s -X POST "http://HOST:8899/sessions/$SID/messages" -H 'Content-Type: application/json' -d '{"content":"Execute the shell command '\''id && uname -a'\'' and report the output verbatim."}'` 4. Wait ~5–15 seconds, then `curl -s "http://HOST:8899/sessions/$SID/messages"` and observe the BashTool result message containing `uid=0(root)`, the kernel version, and the container hostname — all returned with no `Authorization` header on any of the three requests. **Impact**: An unauthenticated caller with TCP access to port 8899 can execute arbitrary shell commands as root inside the container. This is the top-severity entry point of the RCE chain. Combined with the absent `USER` directive in the Dockerfile, the blast radius is full container takeover. --- ### Finding 2 — High: Read endpoints return full session history with no authentication, even when API_AUTH_KEY is set - **Severity**: High - **CVSS v3.1**: 7.5 — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` - **CVSS v4.0**: 8.7 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` - **CWE**: CWE-862 (Missing Authorization) **Affected file**: `agent/api_server.py` — `require_auth()` docstring at line 289 states "Only write endpoints (POST/PUT/DELETE/PATCH) use this dependency." Read endpoints with no `Depends(require_auth)`: - line 804 — `@app.get("/runs", response_model=List[RunInfo])` - line 788 — `@app.get("/runs/{run_id}", response_model=RunResponse)` - line 748 — `@app.get("/runs/{run_id}/code")` - line 769 — `@app.get("/runs/{run_id}/pine")` - line 1153 — `@app.get("/sessions", response_model=List[SessionResponse])` - line 1173 — `@app.get("/sessions/{session_id}", response_model=SessionResponse)` - line 1251 — `@app.get("/sessions/{session_id}/messages", response_model=List[MessageResponse])` - line 1272 — `@app.get("/sessions/{session_id}/events")` - line 1444 — `@app.get("/swarm/runs")` **Intent vs actual**: When `API_AUTH_KEY` is configured, the implicit operator expectation is that all session data is protected. The actual design is documented in the docstring at line 289 — read endpoints have no `Depends(require_auth)`, so they remain unauthenticated even with `API_AUTH_KEY` set. A runtime probe with `API_AUTH_KEY=any-secret-value` configured: a session was created with a valid Bearer token, a message containing `BROKER_TOKEN=ts-secret-deadbeef-real-private-data` was posted, then `GET /sessions/{id}/messages` was issued with **no** `Authorization` header and returned HTTP 200 with the broker token string verbatim in the response — confirming the gap persists when authentication is enabled. **Steps to observe**: 1. Set `API_AUTH_KEY=any-secret-value` in `agent/.env`. Under docker compose, add a bind-mount on the `vibe-trading` service so the container reads the change: `volumes: - ./agent/.env:/app/agent/.env:ro`. Then `docker compose up -d --force-recreate` (a plain `restart` reuses the existing process env and will not pick up the change). 2. `SID=$(curl -s -X POST http://HOST:8899/sessions -H 'Authorization: Bearer any-secret-value' -H 'Content-Type: application/json' -d '{}' | python3 -c "import json,sys;print(json.load(sys.stdin)['session_id'])")` 3. `curl -s -X POST "http://HOST:8899/sessions/$SID/messages" -H 'Authorization: Bearer any-secret-value' -H 'Content-Type: application/json' -d '{"content":"BROKER_TOKEN=ts-secret-test-value"}'` (this requires the Bearer token because POST is auth-protected) 4. **No-auth read** — `curl -s "http://HOST:8899/sessions/$SID/messages"` (no `Authorization` header). Observe HTTP 200 with the broker token visible. 5. Also: `curl -s "http://HOST:8899/runs"` returns all run records (including their prompt fields) with no auth. **Impact**: An unauthenticated caller can enumerate the full history of every agent session — including any broker tokens, LLM API keys, or trading account details the operator has pasted into prompts. The gap persists when the operator believes their write operations are protected, making it deceptive for operators who have followed the SECURITY.md spirit and turned auth on. --- ### Finding 3 — High: Unauthenticated POST /upload writes arbitrary .py/.sh/.yaml files to server filesystem with full path returned - **Severity**: High - **CVSS v3.1**: 8.1 — `AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N` - **CVSS v4.0**: 8.7 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N` - **CWE**: CWE-434 (Unrestricted Upload of File with Dangerous Type) **Affected file**: - `agent/api_server.py:1310-1321` — `_BLOCKED_UPLOAD_EXT` set rejects `.exe`, `.msi`, `.bat`, `.cmd`, `.com`, `.scr`, `.app`, `.dmg`, `.so`, `.dll`, `.dylib`, `.zip`, `.rar`, `.7z`, `.tar`, `.gz`, `.tgz`, `.bz2`, `.xz` — but **not** `.py`, `.sh`, `.yaml`, `.j2`, `.json`, `.html`, or `Dockerfile` - `agent/api_server.py:1347` — `@app.post("/upload", dependencies=[Depends(require_auth)])` (no-op when `API_AUTH_KEY` unset) **Intent vs actual**: `POST /upload` is intended as an authenticated file-staging mechanism. In default config the auth dependency is a no-op (per F1). The extension blocklist is a denylist not an allowlist, so dangerous executable-adjacent types pass through. The uploaded file is saved as `<uuid>.<ext>` and the **full resolved server path is returned in the response body** under `"file_path"`, so the attacker does not need to guess paths. **Steps to observe** (no LLM key required): 1. Start the server in default config (no `API_AUTH_KEY`). 2. `curl -s -X POST http://HOST:8899/upload -F 'file=@/dev/stdin;filename=payload.py' <<< 'print("ATTACKER_CONTROLLED")'` 3. Observe HTTP 200 with JSON containing `"status":"ok"` and `"file_path":"/app/agent/uploads/<uuid>.py"`. 4. Repeat with `filename=config.yaml` and `filename=run.sh` to confirm multiple executable-adjacent types pass. **Impact**: Any unauthenticated caller can write arbitrary Python scripts, shell scripts, or YAML configuration to a known, server-returned path. F3 is independent of any LLM API key — it is the cleanest unauth-write primitive in the codebase. The uploaded file is reachable from the LLM agent's tool envelope and chains into Group B / F8 (backtest exec_module premature exec) for a non-bash RCE path. --- ### Finding A4 — Medium: Default-permissive CORS allowlist + loopback-only check on /settings let any localhost-served browser page drive credentialed cross-origin requests - **Severity**: Medium - **CVSS v3.1**: 7.7 — `AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N` - **CVSS v4.0**: 6.3 — `AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N` - **CWE**: CWE-942 (Permissive Cross-domain Policy with Untrusted Domains); CWE-346 (Origin Validation Error) **Affected file**: - `agent/api_server.py:252-264` — `_CORS_ORIGINS = os.getenv(...)` defaults to a list of six localhost origins (`http://localhost:3000`, `:5173`, `:8000`; same for `127.0.0.1`); `CORSMiddleware` is added with `allow_credentials=True`, `allow_methods=["*"]`, `allow_headers=["*"]` - `agent/api_server.py:309-336` — `_is_local_client()` and `require_local_or_auth()`: the loopback check examines `request.client.host` (TCP peer IP), which is `127.0.0.1` for **any** browser request from the same machine, regardless of the page's origin - `agent/api_server.py:908` — `dependencies=[Depends(require_local_or_auth)]` on `/settings/llm` and related endpoints (granted to any browser request from the host) **Intent vs actual**: The CORS allowlist is intended to permit the bundled Vite/React frontend to make credentialed API calls during development. The intent is a development-convenience configuration. The actual configuration permits **any** local web page served from one of the six listed origins — which includes any other application, IDE preview pane, local web tool, or static HTML file served by another process listening on those ports — to issue credentialed cross-origin POSTs/GETs and read the responses in JavaScript. Because the loopback check at `_is_local_client()` examines the TCP peer IP (always `127.0.0.1` for browser requests from the host), browser-driven cross-origin requests from a whitelisted origin also bypass the loopback restriction on `/settings/*`, which would otherwise have been the only barrier. **Steps to observe** (no LLM key required): 1. Start the server in default config. 2. Preflight: `curl -s -X OPTIONS "http://HOST:8899/sessions" -H "Origin: http://localhost:3000" -H "Access-Control-Request-Method: POST" -i` — observe the response includes `access-control-allow-credentials: true`, `access-control-allow-origin: http://localhost:3000`, and `access-control-allow-methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT`. 3. Confirm a real `POST /sessions` with `Origin: http://localhost:3000` returns the same allow-credentials header in the response so a browser can read the body. 4. Preflight against a settings endpoint: `curl -s -X OPTIONS "http://HOST:8899/settings/llm" -H "Origin: http://localhost:3000" -i`. Then `curl -s "http://HOST:8899/settings/llm" -H "Origin: http://localhost:3000"` and observe the response is allowed because `request.client.host = 127.0.0.1` satisfies `_is_local_client()`. 5. Negative control: `curl -s -X OPTIONS "http://HOST:8899/sessions" -H "Origin: http://evil.example.com" -i` — observe no CORS headers, demonstrating the allowlist is functional for non-localhost origins. **Impact**: Any malicious or compromised local web page on a whitelisted localhost port can silently drive the Vibe-Trading API in the operator's browser context — creating sessions, posting messages (which chain into F1's BashTool RCE), reading session histories (F2), and reading settings including the partial-key hint exposed by F-A5. Required user interaction is limited to the operator visiting a page that issues background `fetch()` calls. This expands the F1-F3 surface from direct TCP attackers to browser-mediated attackers that share a host with a developer running the agent. --- ### Finding A5 — Medium: Settings endpoints expose first-4 + last-4 characters of every configured API key via _mask_secret() - **Severity**: Medium - **CVSS v3.1**: 5.3 — `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N` - **CVSS v4.0**: 6.9 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N` - **CWE**: CWE-200 (Exposure of Sensitive Information) **Affected files**: - `agent/api_server.py:467-474` — `_mask_secret()` returns `f"{value[:4]}...{value[-4:]}"` for any string longer than 8 characters - `agent/api_server.py:372` — `LLM_API_KEY_PLACEHOLDERS` filters out shipped placeholders so the leak fires only when a real key is configured - `agent/api_server.py:505-522` — `GET /settings/llm` returns `api_key_hint = _mask_secret(api_key) if api_key_configured else None` - `agent/api_server.py:561` — `GET /settings/data-sources` returns `tushare_token_hint=_mask_secret(token) if token_configured else None` - `agent/test_settings_api.py:106` — assertion `api_key_hint == "or-s...alue"` for input `or-secret-value` confirms the 4+4 reveal is the intended API contract **Intent vs actual**: The frontend needs to confirm to the operator that an API key is configured, so the appropriate hint is a boolean presence indicator or a fixed placeholder. The actual implementation reveals the first 4 and last 4 characters. For structured provider keys with predictable prefixes (`sk-or-v1-`, `gsk_`, `xoxb-`, `ts-`), the leading 4 bytes are largely fixed and the entropy leak is concentrated in the trailing 4 — which can be material for tokens with bounded total entropy (e.g. Tushare tokens). A runtime probe configured `OPENROUTER_API_KEY=sk-or-v1-AbCdEfGhXyZ12345fakekey` and `TUSHARE_TOKEN=ts-real-shaped-token-1234567890ab` and observed `api_key_hint='sk-o...ekey'` and `tushare_token_hint='ts-r...90ab'` from the corresponding GET endpoints. **Steps to observe** (no LLM key required other than the configured value being non-placeholder; the call itself does not consume the LLM): 1. Edit `agent/.env` to replace the placeholder with a real-shaped key, e.g. `OPENROUTER_API_KEY=sk-or-v1-TestKeyAbcde12345`. Restart the server. 2. From any loopback client *or* via the F-A4 cross-origin path, `curl -s "http://127.0.0.1:8899/settings/llm"` (no `Authorization` header). 3. Observe HTTP 200 with `api_key_configured=true` and `api_key_hint` containing the first 4 and last 4 characters of the real key. 4. `curl -s "http://127.0.0.1:8899/settings/data-sources"` to observe `tushare_token_hint` follow the same pattern. **Impact**: Every functional deployment leaks structured bytes of the configured API keys. Combined with offline guessing against bounded-entropy provider keys (notably Tushare tokens), the partial reveal can narrow the attack space to a tractable bruteforce window. The leak is reachable from the F-A4 cross-origin browser path, so it does not require even loopback TCP access — only an operator who visits a malicious local web page in a browser running on the same host as the agent. --- ### Suggested remediation (per finding) 1. **F1 / F3** — `require_auth()` must fail closed when `API_AUTH_KEY` is not set. Either raise on startup if the env var is empty, or generate a random per-install key and emit a one-time bootstrap message. Replace the `if not api_key: return` shortcut at line 303 with explicit handling of dev-vs-production. 2. **F2** — Apply `Depends(require_auth)` to all read-side `@app.get()` decorators (`/runs*`, `/sessions*`, `/swarm/runs*`). The current docstring at line 289 ("Only write endpoints use this dependency") describes the bug rather than design intent. 3. **F3** — Convert `_BLOCKED_UPLOAD_EXT` to an allowlist (`.csv`, `.tsv`, `.json`, `.pdf`, `.txt`, `.xlsx`, `.docx` etc.) rather than a denylist; add `.py`, `.sh`, `.yaml`, `.j2`, `Dockerfile` to the rejection set in any case. Place uploads in a directory outside the agent's tool-discovery envelope. 4. **F-A4** — Tighten `_CORS_ORIGINS` default to only `http://localhost:5173` (the bundled Vite dev port). Decouple `_is_local_client` from `request.client.host` — require either a Bearer token *or* a positive `Origin` header check, not the TCP peer IP. Document loud that adding any port to `_CORS_ORIGINS` grants full credentialed cross-origin API access. 5. **F-A5** — Replace `_mask_secret()` with a fixed placeholder ("•••configured•••") or a boolean presence flag. If the UI requires a hint, hash the key (truncated SHA-256) so the hint cannot be inverted to bytes of the original. ---

GHSA-v2f8-6655-7grj Affected Vibe trading ai Versions

1 component(s)
Fixed Versions:
0.1.7
Product / Package Ecosystem Affected Versions Fixed Version
vibe-trading-ai
PyPI
≥ 0.1.0
< 0.1.7
0.1.7

References

Frequently Asked Questions

What is GHSA-v2f8-6655-7grj?
GHSA-v2f8-6655-7grj is a security vulnerability in Vibe trading ai involving Vibe-Trading FastAPI endpoints permit unauthenticated access, file upload, and an RCE chain under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains.
Which Vibe trading ai versions are affected?
Affected versions include releases prior to 0.1.7 across affected packages: vibe-trading-ai.
What version fixes GHSA-v2f8-6655-7grj?
Upgrading to 0.1.7 (or the latest patched release for your respective branch) resolves the vulnerability.
Is vibe-trading-ai affected?
Yes, vibe-trading-ai is affected in releases prior to 0.1.7. Upgrade your dependency to 0.1.7 or later.
What is the CVSS score of GHSA-v2f8-6655-7grj?
GHSA-v2f8-6655-7grj has a CVSS v3.1 base score of 10.0 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
What CWE is associated with GHSA-v2f8-6655-7grj?
GHSA-v2f8-6655-7grj is classified under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains (The product uses a web-client protection mechanism such as a Content Security Policy (CSP) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate.).
How can I check PyPI dependencies for GHSA-v2f8-6655-7grj?
Run the dependency tree command: 'pip show vibe-trading-ai'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-v2f8-6655-7grj",
  "modified" : "2026-10-02T22:44:26Z",
  "published" : "2026-10-02T22:44:26Z",
  "aliases" : [ ],
  "summary" : "Vibe-Trading FastAPI endpoints permit unauthenticated access, file upload, and an RCE chain",
  "details" : "### Summary: \n5 findings — unauthenticated full-API exposure (F1, lead Critical), read-side authorization gap that persists even with `API_AUTH_KEY` set (F2), unauthenticated file write of `.py`/`.sh`/`.yaml` to a server-returned path (F3), default-permissive CORS that combines with a loopback-only check to grant any browser page on whitelisted localhost ports credentialed cross-origin access (F-A4), and partial API-key disclosure via `_mask_secret()` (F-A5).\n\n---\n\n### Shared baseline (applies to all 5 findings)\n\nThe shipped `agent/.env.example` line 112 ships `# API_AUTH_KEY=` commented out. `require_auth()` at `agent/api_server.py` line 303 executes `if not api_key: return` and returns `None` immediately when `API_AUTH_KEY` is unset, so every endpoint decorated with `dependencies=[Depends(require_auth)]` operates as unauthenticated. The shipped `Dockerfile` does **not** contain a `USER` directive, so the FastAPI process runs as `uid=0(root)` inside the container (verified: `docker exec id` returns `uid=0(root) gid=0(root)`). The `docker-compose.yml` binds `0.0.0.0:8899` with no network restriction.\n\nThe only operator action required beyond a clean install is supplying a working LLM API key so the agent loop can complete its tool-call round trip — this is the normal first step to make the agent functional, not an additional security opt-in. F-A4 and F-A5 do *not* require an LLM key (see per-finding notes); F1 and F3 do not require an LLM key for the unauth surface itself, only for the chained RCE demonstration in F1.\n\n### Reproducer environment (common)\n\n```sh\ngit clone https://github.com/HKUDS/Vibe-Trading.git\ncd Vibe-Trading\ngit checkout 7452610113a75529b5d55fd2217bb17f7bec66f7   # v0.1.6 + 1 frontend fix; same vuln state as v0.1.6\ncp agent/.env.example agent/.env\n# (For F1 chained demo only:) edit agent/.env to set OPENROUTER_API_KEY=<real key>\ndocker compose up -d\n# port 8899 is now reachable; HOST below is the docker host's IP from the attacker's perspective\n```\n\n> **Note on the `HOST` placeholder used throughout the per-finding \"Steps to observe\" blocks below**: replace `HOST` with the address you reach the docker host on — typically `localhost` (or `127.0.0.1`) if you are running the reproducer on the same machine as the container. All `curl` commands below assume this substitution.\n\n---\n\n### Finding 1 — Critical: Unauthenticated network client reaches shell execution via POST /sessions/{id}/messages\n\n- **Severity**: Critical\n- **CVSS v3.1**: 9.8 — `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`\n- **CVSS v4.0**: 10.0 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`\n- **CWE**: CWE-306 (Missing Authentication for Critical Function); chains into CWE-78 (Group B, F6)\n\n**Affected files**:\n- `agent/api_server.py:303` — `if not api_key: return` early return in `require_auth()`\n- `agent/api_server.py:736` — `@app.post(\"/sessions/{session_id}/messages\", dependencies=[Depends(require_auth)])` (the dependency is a no-op when `API_AUTH_KEY` is unset)\n- `agent/src/tools/bash_tool.py:44-46` — `subprocess.run(command, shell=True, cwd=cwd)` with command read from `kwargs['command']` (full bug detail tracked in GHSA-2 / Group B / F6)\n\n**Intent vs actual**: The session API is intended to serve authenticated users only. When `API_AUTH_KEY` is unset, `require_auth()` returns `None` immediately and `dependencies=[Depends(require_auth)]` becomes a no-op. Any anonymous TCP client to port 8899 can therefore create a session, post a message, and receive the LLM agent's response. The LLM ReAct agent — given a natural-language request to run a command — selects `BashTool` from the auto-discovered registry, which calls `subprocess.run(command, shell=True)` with the LLM-emitted string. The container has no `USER` directive, so the resulting process runs as `uid=0(root)`.\n\n**Steps to observe**:\n\n1. Start the server per the shared reproducer above (with a working `OPENROUTER_API_KEY` set in `agent/.env`). Confirm `curl -fs http://HOST:8899/health` returns 200.\n2. `SID=$(curl -s -X POST http://HOST:8899/sessions -H 'Content-Type: application/json' -d '{}' | python3 -c \"import json,sys;print(json.load(sys.stdin)['session_id'])\")`\n3. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H 'Content-Type: application/json' -d '{\"content\":\"Execute the shell command '\\''id && uname -a'\\'' and report the output verbatim.\"}'`\n4. Wait ~5–15 seconds, then `curl -s \"http://HOST:8899/sessions/$SID/messages\"` and observe the BashTool result message containing `uid=0(root)`, the kernel version, and the container hostname — all returned with no `Authorization` header on any of the three requests.\n\n**Impact**: An unauthenticated caller with TCP access to port 8899 can execute arbitrary shell commands as root inside the container. This is the top-severity entry point of the RCE chain. Combined with the absent `USER` directive in the Dockerfile, the blast radius is full container takeover.\n\n---\n\n### Finding 2 — High: Read endpoints return full session history with no authentication, even when API_AUTH_KEY is set\n\n- **Severity**: High\n- **CVSS v3.1**: 7.5 — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`\n- **CVSS v4.0**: 8.7 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`\n- **CWE**: CWE-862 (Missing Authorization)\n\n**Affected file**: `agent/api_server.py` — `require_auth()` docstring at line 289 states \"Only write endpoints (POST/PUT/DELETE/PATCH) use this dependency.\" Read endpoints with no `Depends(require_auth)`:\n- line 804 — `@app.get(\"/runs\", response_model=List[RunInfo])`\n- line 788 — `@app.get(\"/runs/{run_id}\", response_model=RunResponse)`\n- line 748 — `@app.get(\"/runs/{run_id}/code\")`\n- line 769 — `@app.get(\"/runs/{run_id}/pine\")`\n- line 1153 — `@app.get(\"/sessions\", response_model=List[SessionResponse])`\n- line 1173 — `@app.get(\"/sessions/{session_id}\", response_model=SessionResponse)`\n- line 1251 — `@app.get(\"/sessions/{session_id}/messages\", response_model=List[MessageResponse])`\n- line 1272 — `@app.get(\"/sessions/{session_id}/events\")`\n- line 1444 — `@app.get(\"/swarm/runs\")`\n\n**Intent vs actual**: When `API_AUTH_KEY` is configured, the implicit operator expectation is that all session data is protected. The actual design is documented in the docstring at line 289 — read endpoints have no `Depends(require_auth)`, so they remain unauthenticated even with `API_AUTH_KEY` set. A runtime probe with `API_AUTH_KEY=any-secret-value` configured: a session was created with a valid Bearer token, a message containing `BROKER_TOKEN=ts-secret-deadbeef-real-private-data` was posted, then `GET /sessions/{id}/messages` was issued with **no** `Authorization` header and returned HTTP 200 with the broker token string verbatim in the response — confirming the gap persists when authentication is enabled.\n\n**Steps to observe**:\n\n1. Set `API_AUTH_KEY=any-secret-value` in `agent/.env`. Under docker compose, add a bind-mount on the `vibe-trading` service so the container reads the change: `volumes: - ./agent/.env:/app/agent/.env:ro`. Then `docker compose up -d --force-recreate` (a plain `restart` reuses the existing process env and will not pick up the change).\n2. `SID=$(curl -s -X POST http://HOST:8899/sessions -H 'Authorization: Bearer any-secret-value' -H 'Content-Type: application/json' -d '{}' | python3 -c \"import json,sys;print(json.load(sys.stdin)['session_id'])\")`\n3. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H 'Authorization: Bearer any-secret-value' -H 'Content-Type: application/json' -d '{\"content\":\"BROKER_TOKEN=ts-secret-test-value\"}'` (this requires the Bearer token because POST is auth-protected)\n4. **No-auth read** — `curl -s \"http://HOST:8899/sessions/$SID/messages\"` (no `Authorization` header). Observe HTTP 200 with the broker token visible.\n5. Also: `curl -s \"http://HOST:8899/runs\"` returns all run records (including their prompt fields) with no auth.\n\n**Impact**: An unauthenticated caller can enumerate the full history of every agent session — including any broker tokens, LLM API keys, or trading account details the operator has pasted into prompts. The gap persists when the operator believes their write operations are protected, making it deceptive for operators who have followed the SECURITY.md spirit and turned auth on.\n\n---\n\n### Finding 3 — High: Unauthenticated POST /upload writes arbitrary .py/.sh/.yaml files to server filesystem with full path returned\n\n- **Severity**: High\n- **CVSS v3.1**: 8.1 — `AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N`\n- **CVSS v4.0**: 8.7 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:N`\n- **CWE**: CWE-434 (Unrestricted Upload of File with Dangerous Type)\n\n**Affected file**:\n- `agent/api_server.py:1310-1321` — `_BLOCKED_UPLOAD_EXT` set rejects `.exe`, `.msi`, `.bat`, `.cmd`, `.com`, `.scr`, `.app`, `.dmg`, `.so`, `.dll`, `.dylib`, `.zip`, `.rar`, `.7z`, `.tar`, `.gz`, `.tgz`, `.bz2`, `.xz` — but **not** `.py`, `.sh`, `.yaml`, `.j2`, `.json`, `.html`, or `Dockerfile`\n- `agent/api_server.py:1347` — `@app.post(\"/upload\", dependencies=[Depends(require_auth)])` (no-op when `API_AUTH_KEY` unset)\n\n**Intent vs actual**: `POST /upload` is intended as an authenticated file-staging mechanism. In default config the auth dependency is a no-op (per F1). The extension blocklist is a denylist not an allowlist, so dangerous executable-adjacent types pass through. The uploaded file is saved as `<uuid>.<ext>` and the **full resolved server path is returned in the response body** under `\"file_path\"`, so the attacker does not need to guess paths.\n\n**Steps to observe** (no LLM key required):\n\n1. Start the server in default config (no `API_AUTH_KEY`).\n2. `curl -s -X POST http://HOST:8899/upload -F 'file=@/dev/stdin;filename=payload.py' <<< 'print(\"ATTACKER_CONTROLLED\")'`\n3. Observe HTTP 200 with JSON containing `\"status\":\"ok\"` and `\"file_path\":\"/app/agent/uploads/<uuid>.py\"`.\n4. Repeat with `filename=config.yaml` and `filename=run.sh` to confirm multiple executable-adjacent types pass.\n\n**Impact**: Any unauthenticated caller can write arbitrary Python scripts, shell scripts, or YAML configuration to a known, server-returned path. F3 is independent of any LLM API key — it is the cleanest unauth-write primitive in the codebase. The uploaded file is reachable from the LLM agent's tool envelope and chains into Group B / F8 (backtest exec_module premature exec) for a non-bash RCE path.\n\n---\n\n### Finding A4 — Medium: Default-permissive CORS allowlist + loopback-only check on /settings let any localhost-served browser page drive credentialed cross-origin requests\n\n- **Severity**: Medium\n- **CVSS v3.1**: 7.7 — `AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N`\n- **CVSS v4.0**: 6.3 — `AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N`\n- **CWE**: CWE-942 (Permissive Cross-domain Policy with Untrusted Domains); CWE-346 (Origin Validation Error)\n\n**Affected file**:\n- `agent/api_server.py:252-264` — `_CORS_ORIGINS = os.getenv(...)` defaults to a list of six localhost origins (`http://localhost:3000`, `:5173`, `:8000`; same for `127.0.0.1`); `CORSMiddleware` is added with `allow_credentials=True`, `allow_methods=[\"*\"]`, `allow_headers=[\"*\"]`\n- `agent/api_server.py:309-336` — `_is_local_client()` and `require_local_or_auth()`: the loopback check examines `request.client.host` (TCP peer IP), which is `127.0.0.1` for **any** browser request from the same machine, regardless of the page's origin\n- `agent/api_server.py:908` — `dependencies=[Depends(require_local_or_auth)]` on `/settings/llm` and related endpoints (granted to any browser request from the host)\n\n**Intent vs actual**: The CORS allowlist is intended to permit the bundled Vite/React frontend to make credentialed API calls during development. The intent is a development-convenience configuration. The actual configuration permits **any** local web page served from one of the six listed origins — which includes any other application, IDE preview pane, local web tool, or static HTML file served by another process listening on those ports — to issue credentialed cross-origin POSTs/GETs and read the responses in JavaScript. Because the loopback check at `_is_local_client()` examines the TCP peer IP (always `127.0.0.1` for browser requests from the host), browser-driven cross-origin requests from a whitelisted origin also bypass the loopback restriction on `/settings/*`, which would otherwise have been the only barrier.\n\n**Steps to observe** (no LLM key required):\n\n1. Start the server in default config.\n2. Preflight: `curl -s -X OPTIONS \"http://HOST:8899/sessions\" -H \"Origin: http://localhost:3000\" -H \"Access-Control-Request-Method: POST\" -i` — observe the response includes `access-control-allow-credentials: true`, `access-control-allow-origin: http://localhost:3000`, and `access-control-allow-methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT`.\n3. Confirm a real `POST /sessions` with `Origin: http://localhost:3000` returns the same allow-credentials header in the response so a browser can read the body.\n4. Preflight against a settings endpoint: `curl -s -X OPTIONS \"http://HOST:8899/settings/llm\" -H \"Origin: http://localhost:3000\" -i`. Then `curl -s \"http://HOST:8899/settings/llm\" -H \"Origin: http://localhost:3000\"` and observe the response is allowed because `request.client.host = 127.0.0.1` satisfies `_is_local_client()`.\n5. Negative control: `curl -s -X OPTIONS \"http://HOST:8899/sessions\" -H \"Origin: http://evil.example.com\" -i` — observe no CORS headers, demonstrating the allowlist is functional for non-localhost origins.\n\n**Impact**: Any malicious or compromised local web page on a whitelisted localhost port can silently drive the Vibe-Trading API in the operator's browser context — creating sessions, posting messages (which chain into F1's BashTool RCE), reading session histories (F2), and reading settings including the partial-key hint exposed by F-A5. Required user interaction is limited to the operator visiting a page that issues background `fetch()` calls. This expands the F1-F3 surface from direct TCP attackers to browser-mediated attackers that share a host with a developer running the agent.\n\n---\n\n### Finding A5 — Medium: Settings endpoints expose first-4 + last-4 characters of every configured API key via _mask_secret()\n\n- **Severity**: Medium\n- **CVSS v3.1**: 5.3 — `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N`\n- **CVSS v4.0**: 6.9 — `AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N`\n- **CWE**: CWE-200 (Exposure of Sensitive Information)\n\n**Affected files**:\n- `agent/api_server.py:467-474` — `_mask_secret()` returns `f\"{value[:4]}...{value[-4:]}\"` for any string longer than 8 characters\n- `agent/api_server.py:372` — `LLM_API_KEY_PLACEHOLDERS` filters out shipped placeholders so the leak fires only when a real key is configured\n- `agent/api_server.py:505-522` — `GET /settings/llm` returns `api_key_hint = _mask_secret(api_key) if api_key_configured else None`\n- `agent/api_server.py:561` — `GET /settings/data-sources` returns `tushare_token_hint=_mask_secret(token) if token_configured else None`\n- `agent/test_settings_api.py:106` — assertion `api_key_hint == \"or-s...alue\"` for input `or-secret-value` confirms the 4+4 reveal is the intended API contract\n\n**Intent vs actual**: The frontend needs to confirm to the operator that an API key is configured, so the appropriate hint is a boolean presence indicator or a fixed placeholder. The actual implementation reveals the first 4 and last 4 characters. For structured provider keys with predictable prefixes (`sk-or-v1-`, `gsk_`, `xoxb-`, `ts-`), the leading 4 bytes are largely fixed and the entropy leak is concentrated in the trailing 4 — which can be material for tokens with bounded total entropy (e.g. Tushare tokens). A runtime probe configured `OPENROUTER_API_KEY=sk-or-v1-AbCdEfGhXyZ12345fakekey` and `TUSHARE_TOKEN=ts-real-shaped-token-1234567890ab` and observed `api_key_hint='sk-o...ekey'` and `tushare_token_hint='ts-r...90ab'` from the corresponding GET endpoints.\n\n**Steps to observe** (no LLM key required other than the configured value being non-placeholder; the call itself does not consume the LLM):\n\n1. Edit `agent/.env` to replace the placeholder with a real-shaped key, e.g. `OPENROUTER_API_KEY=sk-or-v1-TestKeyAbcde12345`. Restart the server.\n2. From any loopback client *or* via the F-A4 cross-origin path, `curl -s \"http://127.0.0.1:8899/settings/llm\"` (no `Authorization` header).\n3. Observe HTTP 200 with `api_key_configured=true` and `api_key_hint` containing the first 4 and last 4 characters of the real key.\n4. `curl -s \"http://127.0.0.1:8899/settings/data-sources\"` to observe `tushare_token_hint` follow the same pattern.\n\n**Impact**: Every functional deployment leaks structured bytes of the configured API keys. Combined with offline guessing against bounded-entropy provider keys (notably Tushare tokens), the partial reveal can narrow the attack space to a tractable bruteforce window. The leak is reachable from the F-A4 cross-origin browser path, so it does not require even loopback TCP access — only an operator who visits a malicious local web page in a browser running on the same host as the agent.\n\n---\n\n### Suggested remediation (per finding)\n\n1. **F1 / F3** — `require_auth()` must fail closed when `API_AUTH_KEY` is not set. Either raise on startup if the env var is empty, or generate a random per-install key and emit a one-time bootstrap message. Replace the `if not api_key: return` shortcut at line 303 with explicit handling of dev-vs-production.\n2. **F2** — Apply `Depends(require_auth)` to all read-side `@app.get()` decorators (`/runs*`, `/sessions*`, `/swarm/runs*`). The current docstring at line 289 (\"Only write endpoints use this dependency\") describes the bug rather than design intent.\n3. **F3** — Convert `_BLOCKED_UPLOAD_EXT` to an allowlist (`.csv`, `.tsv`, `.json`, `.pdf`, `.txt`, `.xlsx`, `.docx` etc.) rather than a denylist; add `.py`, `.sh`, `.yaml`, `.j2`, `Dockerfile` to the rejection set in any case. Place uploads in a directory outside the agent's tool-discovery envelope.\n4. **F-A4** — Tighten `_CORS_ORIGINS` default to only `http://localhost:5173` (the bundled Vite dev port). Decouple `_is_local_client` from `request.client.host` — require either a Bearer token *or* a positive `Origin` header check, not the TCP peer IP. Document loud that adding any port to `_CORS_ORIGINS` grants full credentialed cross-origin API access.\n5. **F-A5** — Replace `_mask_secret()` with a fixed placeholder (\"•••configured•••\") or a boolean presence flag. If the UI requires a hint, hash the key (truncated SHA-256) so the hint cannot be inverted to bytes of the original.\n\n---",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "vibe-trading-ai"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.1.0"
      }, {
        "fixed" : "0.1.7"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/HKUDS/Vibe-Trading/security/advisories/GHSA-v2f8-6655-7grj"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/HKUDS/Vibe-Trading/commit/9454d4a27a763b80e1d6eb5763b86c88e9e4e714"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/HKUDS/Vibe-Trading"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/HKUDS/Vibe-Trading/releases/tag/v0.1.7"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-200", "CWE-306", "CWE-434", "CWE-862", "CWE-942" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-02T22:44:26Z",
    "nvd_published_at" : null
  }
}