CWE-200
DiscouragedExposure of Sensitive Information to an Unauthorized Actor
Abstraction: Class · Status: Draft
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
16379 vulnerabilities reference this CWE, most recent first.
GHSA-V249-5W98-3V22
Vulnerability from github – Published: 2022-05-17 04:18 – Updated: 2022-05-17 04:18templates/default/index.php in Redaxscript 0.3.2 allows remote attackers to obtain sensitive information via a direct request, which reveals the full path in an error message.
{
"affected": [],
"aliases": [
"CVE-2011-5314"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-01-01T11:59:00Z",
"severity": "MODERATE"
},
"details": "templates/default/index.php in Redaxscript 0.3.2 allows remote attackers to obtain sensitive information via a direct request, which reveals the full path in an error message.",
"id": "GHSA-v249-5w98-3v22",
"modified": "2022-05-17T04:18:46Z",
"published": "2022-05-17T04:18:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-5314"
},
{
"type": "WEB",
"url": "https://www.htbridge.com/advisory/HTB22804"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V24G-HGCJ-MX7C
Vulnerability from github – Published: 2022-05-17 05:29 – Updated: 2022-05-17 05:29xajax 0.6 beta1 allows remote attackers to obtain sensitive information via a direct request to a .php file, which reveals the installation path in an error message, as demonstrated by xajax_core/plugin_layer/xajaxScriptPlugin.inc.php and certain other files.
{
"affected": [],
"aliases": [
"CVE-2011-3821"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-09-24T00:55:00Z",
"severity": "MODERATE"
},
"details": "xajax 0.6 beta1 allows remote attackers to obtain sensitive information via a direct request to a .php file, which reveals the installation path in an error message, as demonstrated by xajax_core/plugin_layer/xajaxScriptPlugin.inc.php and certain other files.",
"id": "GHSA-v24g-hgcj-mx7c",
"modified": "2022-05-17T05:29:47Z",
"published": "2022-05-17T05:29:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3821"
},
{
"type": "WEB",
"url": "http://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/%21_README"
},
{
"type": "WEB",
"url": "http://code.google.com/p/inspathx/source/browse/trunk/paths_vuln/xajax"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2011/06/27/6"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V24W-VWV8-8QJF
Vulnerability from github – Published: 2023-10-26 00:30 – Updated: 2023-11-03 18:30An issue in Anglaise Company Anglaise.Company v.13.6.1 allows a remote attacker to obtain sensitive information via crafted GET request.
{
"affected": [],
"aliases": [
"CVE-2023-38845"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T22:15:09Z",
"severity": "HIGH"
},
"details": "An issue in Anglaise Company Anglaise.Company v.13.6.1 allows a remote attacker to obtain sensitive information via crafted GET request.",
"id": "GHSA-v24w-vwv8-8qjf",
"modified": "2023-11-03T18:30:22Z",
"published": "2023-10-26T00:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38845"
},
{
"type": "WEB",
"url": "https://github.com/syz913/CVE-reports/blob/main/CVE-2023-38845.md"
},
{
"type": "WEB",
"url": "https://liff.line.me/1657030660-8nDEQNbe"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V257-HPRQ-J5RM
Vulnerability from github – Published: 2022-05-24 16:50 – Updated: 2024-04-04 01:16An information disclosure vulnerability exists when DirectWrite improperly discloses the contents of its memory, aka 'DirectWrite Information Disclosure Vulnerability'. This CVE ID is unique from CVE-2019-1097.
{
"affected": [],
"aliases": [
"CVE-2019-1093"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-15T19:15:00Z",
"severity": "MODERATE"
},
"details": "An information disclosure vulnerability exists when DirectWrite improperly discloses the contents of its memory, aka \u0027DirectWrite Information Disclosure Vulnerability\u0027. This CVE ID is unique from CVE-2019-1097.",
"id": "GHSA-v257-hprq-j5rm",
"modified": "2024-04-04T01:16:18Z",
"published": "2022-05-24T16:50:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1093"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1093"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V25X-MMFH-G7W6
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07In the Federation component of OpenStack Keystone before 11.0.4, 12.0.0, and 13.0.0, an authenticated "GET /v3/OS-FEDERATION/projects" request may bypass intended access restrictions on listing projects. An authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected.
{
"affected": [],
"aliases": [
"CVE-2018-14432"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-31T14:29:00Z",
"severity": "MODERATE"
},
"details": "In the Federation component of OpenStack Keystone before 11.0.4, 12.0.0, and 13.0.0, an authenticated \"GET /v3/OS-FEDERATION/projects\" request may bypass intended access restrictions on listing projects. An authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected.",
"id": "GHSA-v25x-mmfh-g7w6",
"modified": "2022-05-13T01:07:33Z",
"published": "2022-05-13T01:07:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14432"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2523"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2533"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2543"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4275"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2018/07/25/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104930"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V26C-V53C-85V2
Vulnerability from github – Published: 2024-04-15 03:31 – Updated: 2024-04-15 03:31aEnrich Technology a+HRD's functionality for front-end retrieval of system configuration values lacks proper restrictions on a specific parameter, allowing attackers to modify this parameter to access certain sensitive system configuration values.
{
"affected": [],
"aliases": [
"CVE-2024-3774"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-15T03:16:08Z",
"severity": "MODERATE"
},
"details": "aEnrich Technology a+HRD\u0027s functionality for front-end retrieval of system configuration values lacks proper restrictions on a specific parameter, allowing attackers to modify this parameter to access certain sensitive system configuration values.",
"id": "GHSA-v26c-v53c-85v2",
"modified": "2024-04-15T03:31:00Z",
"published": "2024-04-15T03:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3774"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7724-c28d3-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V27C-Q5XG-JVVH
Vulnerability from github – Published: 2024-01-24 15:30 – Updated: 2026-04-28 21:33Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Cozmoslabs Profile Builder Pro.This issue affects Profile Builder Pro: from n/a through 3.10.0.
{
"affected": [],
"aliases": [
"CVE-2024-22141"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-24T15:15:08Z",
"severity": "MODERATE"
},
"details": "Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Cozmoslabs Profile Builder Pro.This issue affects Profile Builder Pro: from n/a through 3.10.0.",
"id": "GHSA-v27c-q5xg-jvvh",
"modified": "2026-04-28T21:33:51Z",
"published": "2024-01-24T15:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22141"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/profile-builder-pro/wordpress-profile-builder-pro-plugin-3-10-0-totp-secret-key-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V298-4XPP-8Q7W
Vulnerability from github – Published: 2022-05-14 01:00 – Updated: 2025-04-20 03:47Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Replication). Supported versions that are affected are 5.5.57 and earlier, 5.6.37 and earlier and 5.7.19 and earlier. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Server accessible data. CVSS 3.0 Base Score 4.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N).
{
"affected": [],
"aliases": [
"CVE-2017-10268"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-19T17:29:00Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Replication). Supported versions that are affected are 5.5.57 and earlier, 5.6.37 and earlier and 5.7.19 and earlier. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Server accessible data. CVSS 3.0 Base Score 4.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N).",
"id": "GHSA-v298-4xpp-8q7w",
"modified": "2025-04-20T03:47:06Z",
"published": "2022-05-14T01:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10268"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3265"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:3442"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0279"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0574"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2439"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:2729"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1258"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/06/msg00015.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20171019-0002"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4341"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-4002"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101390"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039597"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V299-6Q62-275R
Vulnerability from github – Published: 2022-05-14 03:15 – Updated: 2022-05-14 03:15The REST API in Dataiku DSS before 4.2.3 allows remote attackers to obtain sensitive information (i.e., determine if a username is valid) because of profile pictures visibility.
{
"affected": [],
"aliases": [
"CVE-2018-10732"
],
"database_specific": {
"cwe_ids": [
"CWE-200"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-28T17:29:00Z",
"severity": "MODERATE"
},
"details": "The REST API in Dataiku DSS before 4.2.3 allows remote attackers to obtain sensitive information (i.e., determine if a username is valid) because of profile pictures visibility.",
"id": "GHSA-v299-6q62-275r",
"modified": "2022-05-14T03:15:06Z",
"published": "2022-05-14T03:15:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10732"
},
{
"type": "WEB",
"url": "https://doc.dataiku.com/dss/latest/release_notes/4.2.html#security"
},
{
"type": "WEB",
"url": "https://github.com/alt3kx/CVE-2018-10732"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V2F8-6655-7GRJ
Vulnerability from github – Published: 2026-10-02 22:44 – Updated: 2026-10-02 22:44Summary:
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
HOSTplaceholder used throughout the per-finding "Steps to observe" blocks below: replaceHOSTwith the address you reach the docker host on — typicallylocalhost(or127.0.0.1) if you are running the reproducer on the same machine as the container. Allcurlcommands 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:
- Start the server per the shared reproducer above (with a working
OPENROUTER_API_KEYset inagent/.env). Confirmcurl -fs http://HOST:8899/healthreturns 200. 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'])")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."}'- Wait ~5–15 seconds, then
curl -s "http://HOST:8899/sessions/$SID/messages"and observe the BashTool result message containinguid=0(root), the kernel version, and the container hostname — all returned with noAuthorizationheader 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:
- Set
API_AUTH_KEY=any-secret-valueinagent/.env. Under docker compose, add a bind-mount on thevibe-tradingservice so the container reads the change:volumes: - ./agent/.env:/app/agent/.env:ro. Thendocker compose up -d --force-recreate(a plainrestartreuses the existing process env and will not pick up the change). 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'])")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)- No-auth read —
curl -s "http://HOST:8899/sessions/$SID/messages"(noAuthorizationheader). Observe HTTP 200 with the broker token visible. - 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):
- Start the server in default config (no
API_AUTH_KEY). curl -s -X POST http://HOST:8899/upload -F 'file=@/dev/stdin;filename=payload.py' <<< 'print("ATTACKER_CONTROLLED")'- Observe HTTP 200 with JSON containing
"status":"ok"and"file_path":"/app/agent/uploads/<uuid>.py". - Repeat with
filename=config.yamlandfilename=run.shto 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):
- Start the server in default config.
- Preflight:
curl -s -X OPTIONS "http://HOST:8899/sessions" -H "Origin: http://localhost:3000" -H "Access-Control-Request-Method: POST" -i— observe the response includesaccess-control-allow-credentials: true,access-control-allow-origin: http://localhost:3000, andaccess-control-allow-methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT. - Confirm a real
POST /sessionswithOrigin: http://localhost:3000returns the same allow-credentials header in the response so a browser can read the body. - Preflight against a settings endpoint:
curl -s -X OPTIONS "http://HOST:8899/settings/llm" -H "Origin: http://localhost:3000" -i. Thencurl -s "http://HOST:8899/settings/llm" -H "Origin: http://localhost:3000"and observe the response is allowed becauserequest.client.host = 127.0.0.1satisfies_is_local_client(). - 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):
- Edit
agent/.envto replace the placeholder with a real-shaped key, e.g.OPENROUTER_API_KEY=sk-or-v1-TestKeyAbcde12345. Restart the server. - From any loopback client or via the F-A4 cross-origin path,
curl -s "http://127.0.0.1:8899/settings/llm"(noAuthorizationheader). - Observe HTTP 200 with
api_key_configured=trueandapi_key_hintcontaining the first 4 and last 4 characters of the real key. curl -s "http://127.0.0.1:8899/settings/data-sources"to observetushare_token_hintfollow 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)
- F1 / F3 —
require_auth()must fail closed whenAPI_AUTH_KEYis 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 theif not api_key: returnshortcut at line 303 with explicit handling of dev-vs-production. - 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. - F3 — Convert
_BLOCKED_UPLOAD_EXTto an allowlist (.csv,.tsv,.json,.pdf,.txt,.xlsx,.docxetc.) rather than a denylist; add.py,.sh,.yaml,.j2,Dockerfileto the rejection set in any case. Place uploads in a directory outside the agent's tool-discovery envelope. - F-A4 — Tighten
_CORS_ORIGINSdefault to onlyhttp://localhost:5173(the bundled Vite dev port). Decouple_is_local_clientfromrequest.client.host— require either a Bearer token or a positiveOriginheader check, not the TCP peer IP. Document loud that adding any port to_CORS_ORIGINSgrants full credentialed cross-origin API access. - 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.
{
"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"
}
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-116: Excavation
An adversary actively probes the target in a manner that is designed to solicit information that could be leveraged for malicious purposes.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-169: Footprinting
An adversary engages in probing and exploration activities to identify constituents and properties of the target.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-224: Fingerprinting
An adversary compares output from a target system to known indicators that uniquely identify specific details about the target. Most commonly, fingerprinting is done to determine operating system and application versions. Fingerprinting can be done passively as well as actively. Fingerprinting by itself is not usually detrimental to the target. However, the information gathered through fingerprinting often enables an adversary to discover existing weaknesses in the target.
CAPEC-285: ICMP Echo Request Ping
An adversary sends out an ICMP Type 8 Echo Request, commonly known as a 'Ping', in order to determine if a target system is responsive. If the request is not blocked by a firewall or ACL, the target host will respond with an ICMP Type 0 Echo Reply datagram. This type of exchange is usually referred to as a 'Ping' due to the Ping utility present in almost all operating systems. Ping, as commonly implemented, allows a user to test for alive hosts, measure round-trip time, and measure the percentage of packet loss.
CAPEC-287: TCP SYN Scan
An adversary uses a SYN scan to determine the status of ports on the remote target. SYN scanning is the most common type of port scanning that is used because of its many advantages and few drawbacks. As a result, novice attackers tend to overly rely on the SYN scan while performing system reconnaissance. As a scanning method, the primary advantages of SYN scanning are its universality and speed.
CAPEC-290: Enumerate Mail Exchange (MX) Records
An adversary enumerates the MX records for a given via a DNS query. This type of information gathering returns the names of mail servers on the network. Mail servers are often not exposed to the Internet but are located within the DMZ of a network protected by a firewall. A side effect of this configuration is that enumerating the MX records for an organization my reveal the IP address of the firewall or possibly other internal systems. Attackers often resort to MX record enumeration when a DNS Zone Transfer is not possible.
CAPEC-291: DNS Zone Transfers
An attacker exploits a DNS misconfiguration that permits a ZONE transfer. Some external DNS servers will return a list of IP address and valid hostnames. Under certain conditions, it may even be possible to obtain Zone data about the organization's internal network. When successful the attacker learns valuable information about the topology of the target organization, including information about particular servers, their role within the IT structure, and possibly information about the operating systems running upon the network. This is configuration dependent behavior so it may also be required to search out multiple DNS servers while attempting to find one with ZONE transfers allowed.
CAPEC-292: Host Discovery
An adversary sends a probe to an IP address to determine if the host is alive. Host discovery is one of the earliest phases of network reconnaissance. The adversary usually starts with a range of IP addresses belonging to a target network and uses various methods to determine if a host is present at that IP address. Host discovery is usually referred to as 'Ping' scanning using a sonar analogy. The goal is to send a packet through to the IP address and solicit a response from the host. As such, a 'ping' can be virtually any crafted packet whatsoever, provided the adversary can identify a functional host based on its response. An attack of this nature is usually carried out with a 'ping sweep,' where a particular kind of ping is sent to a range of IP addresses.
CAPEC-293: Traceroute Route Enumeration
An adversary uses a traceroute utility to map out the route which data flows through the network in route to a target destination. Tracerouting can allow the adversary to construct a working topology of systems and routers by listing the systems through which data passes through on their way to the targeted machine. This attack can return varied results depending upon the type of traceroute that is performed. Traceroute works by sending packets to a target while incrementing the Time-to-Live field in the packet header. As the packet traverses each hop along its way to the destination, its TTL expires generating an ICMP diagnostic message that identifies where the packet expired. Traditional techniques for tracerouting involved the use of ICMP and UDP, but as more firewalls began to filter ingress ICMP, methods of traceroute using TCP were developed.
CAPEC-294: ICMP Address Mask Request
An adversary sends an ICMP Type 17 Address Mask Request to gather information about a target's networking configuration. ICMP Address Mask Requests are defined by RFC-950, "Internet Standard Subnetting Procedure." An Address Mask Request is an ICMP type 17 message that triggers a remote system to respond with a list of its related subnets, as well as its default gateway and broadcast address via an ICMP type 18 Address Mask Reply datagram. Gathering this type of information helps the adversary plan router-based attacks as well as denial-of-service attacks against the broadcast address.
CAPEC-295: Timestamp Request
This pattern of attack leverages standard requests to learn the exact time associated with a target system. An adversary may be able to use the timestamp returned from the target to attack time-based security algorithms, such as random number generators, or time-based authentication mechanisms.
CAPEC-296: ICMP Information Request
An adversary sends an ICMP Information Request to a host to determine if it will respond to this deprecated mechanism. ICMP Information Requests are a deprecated message type. Information Requests were originally used for diskless machines to automatically obtain their network configuration, but this message type has been superseded by more robust protocol implementations like DHCP.
CAPEC-297: TCP ACK Ping
An adversary sends a TCP segment with the ACK flag set to a remote host for the purpose of determining if the host is alive. This is one of several TCP 'ping' types. The RFC 793 expected behavior for a service is to respond with a RST 'reset' packet to any unsolicited ACK segment that is not part of an existing connection. So by sending an ACK segment to a port, the adversary can identify that the host is alive by looking for a RST packet. Typically, a remote server will respond with a RST regardless of whether a port is open or closed. In this way, TCP ACK pings cannot discover the state of a remote port because the behavior is the same in either case. The firewall will look up the ACK packet in its state-table and discard the segment because it does not correspond to any active connection. A TCP ACK Ping can be used to discover if a host is alive via RST response packets sent from the host.
CAPEC-298: UDP Ping
An adversary sends a UDP datagram to the remote host to determine if the host is alive. If a UDP datagram is sent to an open UDP port there is very often no response, so a typical strategy for using a UDP ping is to send the datagram to a random high port on the target. The goal is to solicit an 'ICMP port unreachable' message from the target, indicating that the host is alive. UDP pings are useful because some firewalls are not configured to block UDP datagrams sent to strange or typically unused ports, like ports in the 65K range. Additionally, while some firewalls may filter incoming ICMP, weaknesses in firewall rule-sets may allow certain types of ICMP (host unreachable, port unreachable) which are useful for UDP ping attempts.
CAPEC-299: TCP SYN Ping
An adversary uses TCP SYN packets as a means towards host discovery. Typical RFC 793 behavior specifies that when a TCP port is open, a host must respond to an incoming SYN "synchronize" packet by completing stage two of the 'three-way handshake' - by sending an SYN/ACK in response. When a port is closed, RFC 793 behavior is to respond with a RST "reset" packet. This behavior can be used to 'ping' a target to see if it is alive by sending a TCP SYN packet to a port and then looking for a RST or an ACK packet in response.
CAPEC-300: Port Scanning
An adversary uses a combination of techniques to determine the state of the ports on a remote target. Any service or application available for TCP or UDP networking will have a port open for communications over the network.
CAPEC-301: TCP Connect Scan
An adversary uses full TCP connection attempts to determine if a port is open on the target system. The scanning process involves completing a 'three-way handshake' with a remote port, and reports the port as closed if the full handshake cannot be established. An advantage of TCP connect scanning is that it works against any TCP/IP stack.
CAPEC-302: TCP FIN Scan
An adversary uses a TCP FIN scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with the FIN bit set in the packet header. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow the adversary to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.
CAPEC-303: TCP Xmas Scan
An adversary uses a TCP XMAS scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with all possible flags set in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.
CAPEC-304: TCP Null Scan
An adversary uses a TCP NULL scan to determine if ports are closed on the target machine. This scan type is accomplished by sending TCP segments with no flags in the packet header, generating packets that are illegal based on RFC 793. The RFC 793 expected behavior is that any TCP segment with an out-of-state Flag sent to an open port is discarded, whereas segments with out-of-state flags sent to closed ports should be handled with a RST in response. This behavior should allow an attacker to scan for closed ports by sending certain types of rule-breaking packets (out of sync or disallowed by the TCB) and detect closed ports via RST packets.
CAPEC-305: TCP ACK Scan
An adversary uses TCP ACK segments to gather information about firewall or ACL configuration. The purpose of this type of scan is to discover information about filter configurations rather than port state. This type of scanning is rarely useful alone, but when combined with SYN scanning, gives a more complete picture of the type of firewall rules that are present.
CAPEC-306: TCP Window Scan
An adversary engages in TCP Window scanning to analyze port status and operating system type. TCP Window scanning uses the ACK scanning method but examine the TCP Window Size field of response RST packets to make certain inferences. While TCP Window Scans are fast and relatively stealthy, they work against fewer TCP stack implementations than any other type of scan. Some operating systems return a positive TCP window size when a RST packet is sent from an open port, and a negative value when the RST originates from a closed port. TCP Window scanning is one of the most complex scan types, and its results are difficult to interpret. Window scanning alone rarely yields useful information, but when combined with other types of scanning is more useful. It is a generally more reliable means of making inference about operating system versions than port status.
CAPEC-307: TCP RPC Scan
An adversary scans for RPC services listing on a Unix/Linux host.
CAPEC-308: UDP Scan
An adversary engages in UDP scanning to gather information about UDP port status on the target system. UDP scanning methods involve sending a UDP datagram to the target port and looking for evidence that the port is closed. Open UDP ports usually do not respond to UDP datagrams as there is no stateful mechanism within the protocol that requires building or establishing a session. Responses to UDP datagrams are therefore application specific and cannot be relied upon as a method of detecting an open port. UDP scanning relies heavily upon ICMP diagnostic messages in order to determine the status of a remote port.
CAPEC-309: Network Topology Mapping
An adversary engages in scanning activities to map network nodes, hosts, devices, and routes. Adversaries usually perform this type of network reconnaissance during the early stages of attack against an external network. Many types of scanning utilities are typically employed, including ICMP tools, network mappers, port scanners, and route testing utilities such as traceroute.
CAPEC-310: Scanning for Vulnerable Software
An attacker engages in scanning activity to find vulnerable software versions or types, such as operating system versions or network services. Vulnerable or exploitable network configurations, such as improperly firewalled systems, or misconfigured systems in the DMZ or external network, provide windows of opportunity for an attacker. Common types of vulnerable software include unpatched operating systems or services (e.g FTP, Telnet, SMTP, SNMP) running on open ports that the attacker has identified. Attackers usually begin probing for vulnerable software once the external network has been port scanned and potential targets have been revealed.
CAPEC-312: Active OS Fingerprinting
An adversary engages in activity to detect the operating system or firmware version of a remote target by interrogating a device, server, or platform with a probe designed to solicit behavior that will reveal information about the operating systems or firmware in the environment. Operating System detection is possible because implementations of common protocols (Such as IP or TCP) differ in distinct ways. While the implementation differences are not sufficient to 'break' compatibility with the protocol the differences are detectable because the target will respond in unique ways to specific probing activity that breaks the semantic or logical rules of packet construction for a protocol. Different operating systems will have a unique response to the anomalous input, providing the basis to fingerprint the OS behavior. This type of OS fingerprinting can distinguish between operating system types and versions.
CAPEC-313: Passive OS Fingerprinting
An adversary engages in activity to detect the version or type of OS software in a an environment by passively monitoring communication between devices, nodes, or applications. Passive techniques for operating system detection send no actual probes to a target, but monitor network or client-server communication between nodes in order to identify operating systems based on observed behavior as compared to a database of known signatures or values. While passive OS fingerprinting is not usually as reliable as active methods, it is generally better able to evade detection.
CAPEC-317: IP ID Sequencing Probe
This OS fingerprinting probe analyzes the IP 'ID' field sequence number generation algorithm of a remote host. Operating systems generate IP 'ID' numbers differently, allowing an attacker to identify the operating system of the host by examining how is assigns ID numbers when generating response packets. RFC 791 does not specify how ID numbers are chosen or their ranges, so ID sequence generation differs from implementation to implementation. There are two kinds of IP 'ID' sequence number analysis - IP 'ID' Sequencing: analyzing the IP 'ID' sequence generation algorithm for one protocol used by a host and Shared IP 'ID' Sequencing: analyzing the packet ordering via IP 'ID' values spanning multiple protocols, such as between ICMP and TCP.
CAPEC-318: IP 'ID' Echoed Byte-Order Probe
This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'ID' value from the probe packet. An attacker sends a UDP datagram with an arbitrary IP 'ID' value to a closed port on the remote host to observe the manner in which this bit is echoed back in the ICMP error message. The identification field (ID) is typically utilized for reassembling a fragmented packet. Some operating systems or router firmware reverse the bit order of the ID field when echoing the IP Header portion of the original datagram within an ICMP error message.
CAPEC-319: IP (DF) 'Don't Fragment Bit' Echoing Probe
This OS fingerprinting probe tests to determine if the remote host echoes back the IP 'DF' (Don't Fragment) bit in a response packet. An attacker sends a UDP datagram with the DF bit set to a closed port on the remote host to observe whether the 'DF' bit is set in the response packet. Some operating systems will echo the bit in the ICMP error message while others will zero out the bit in the response packet.
CAPEC-320: TCP Timestamp Probe
This OS fingerprinting probe examines the remote server's implementation of TCP timestamps. Not all operating systems implement timestamps within the TCP header, but when timestamps are used then this provides the attacker with a means to guess the operating system of the target. The attacker begins by probing any active TCP service in order to get response which contains a TCP timestamp. Different Operating systems update the timestamp value using different intervals. This type of analysis is most accurate when multiple timestamp responses are received and then analyzed. TCP timestamps can be found in the TCP Options field of the TCP header.
CAPEC-321: TCP Sequence Number Probe
This OS fingerprinting probe tests the target system's assignment of TCP sequence numbers. One common way to test TCP Sequence Number generation is to send a probe packet to an open port on the target and then compare the how the Sequence Number generated by the target relates to the Acknowledgement Number in the probe packet. Different operating systems assign Sequence Numbers differently, so a fingerprint of the operating system can be obtained by categorizing the relationship between the acknowledgement number and sequence number as follows: 1) the Sequence Number generated by the target is Zero, 2) the Sequence Number generated by the target is the same as the acknowledgement number in the probe, 3) the Sequence Number generated by the target is the acknowledgement number plus one, or 4) the Sequence Number is any other non-zero number.
CAPEC-322: TCP (ISN) Greatest Common Divisor Probe
This OS fingerprinting probe sends a number of TCP SYN packets to an open port of a remote machine. The Initial Sequence Number (ISN) in each of the SYN/ACK response packets is analyzed to determine the smallest number that the target host uses when incrementing sequence numbers. This information can be useful for identifying an operating system because particular operating systems and versions increment sequence numbers using different values. The result of the analysis is then compared against a database of OS behaviors to determine the OS type and/or version.
CAPEC-323: TCP (ISN) Counter Rate Probe
This OS detection probe measures the average rate of initial sequence number increments during a period of time. Sequence numbers are incremented using a time-based algorithm and are susceptible to a timing analysis that can determine the number of increments per unit time. The result of this analysis is then compared against a database of operating systems and versions to determine likely operation system matches.
CAPEC-324: TCP (ISN) Sequence Predictability Probe
This type of operating system probe attempts to determine an estimate for how predictable the sequence number generation algorithm is for a remote host. Statistical techniques, such as standard deviation, can be used to determine how predictable the sequence number generation is for a system. This result can then be compared to a database of operating system behaviors to determine a likely match for operating system and version.
CAPEC-325: TCP Congestion Control Flag (ECN) Probe
This OS fingerprinting probe checks to see if the remote host supports explicit congestion notification (ECN) messaging. ECN messaging was designed to allow routers to notify a remote host when signal congestion problems are occurring. Explicit Congestion Notification messaging is defined by RFC 3168. Different operating systems and versions may or may not implement ECN notifications, or may respond uniquely to particular ECN flag types.
CAPEC-326: TCP Initial Window Size Probe
This OS fingerprinting probe checks the initial TCP Window size. TCP stacks limit the range of sequence numbers allowable within a session to maintain the "connected" state within TCP protocol logic. The initial window size specifies a range of acceptable sequence numbers that will qualify as a response to an ACK packet within a session. Various operating systems use different Initial window sizes. The initial window size can be sampled by establishing an ordinary TCP connection.
CAPEC-327: TCP Options Probe
This OS fingerprinting probe analyzes the type and order of any TCP header options present within a response segment. Most operating systems use unique ordering and different option sets when options are present. RFC 793 does not specify a required order when options are present, so different implementations use unique ways of ordering or structuring TCP options. TCP options can be generated by ordinary TCP traffic.
CAPEC-328: TCP 'RST' Flag Checksum Probe
This OS fingerprinting probe performs a checksum on any ASCII data contained within the data portion or a RST packet. Some operating systems will report a human-readable text message in the payload of a 'RST' (reset) packet when specific types of connection errors occur. RFC 1122 allows text payloads within reset packets but not all operating systems or routers implement this functionality.
CAPEC-329: ICMP Error Message Quoting Probe
An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the amount of data returned or "Quoted" from the originating request that generated the ICMP error message.
CAPEC-330: ICMP Error Message Echoing Integrity Probe
An adversary uses a technique to generate an ICMP Error message (Port Unreachable, Destination Unreachable, Redirect, Source Quench, Time Exceeded, Parameter Problem) from a target and then analyze the integrity of data returned or "Quoted" from the originating request that generated the error message.
CAPEC-472: Browser Fingerprinting
An attacker carefully crafts small snippets of Java Script to efficiently detect the type of browser the potential victim is using. Many web-based attacks need prior knowledge of the web browser including the version of browser to ensure successful exploitation of a vulnerability. Having this knowledge allows an attacker to target the victim with attacks that specifically exploit known or zero day weaknesses in the type and version of the browser used by the victim. Automating this process via Java Script as a part of the same delivery system used to exploit the browser is considered more efficient as the attacker can supply a browser fingerprinting method and integrate it with exploit code, all contained in Java Script and in response to the same web page request by the browser.
CAPEC-497: File Discovery
An adversary engages in probing and exploration activities to determine if common key files exists. Such files often contain configuration and security parameters of the targeted application, system or network. Using this knowledge may often pave the way for more damaging attacks.
CAPEC-508: Shoulder Surfing
In a shoulder surfing attack, an adversary observes an unaware individual's keystrokes, screen content, or conversations with the goal of obtaining sensitive information. One motive for this attack is to obtain sensitive information about the target for financial, personal, political, or other gains. From an insider threat perspective, an additional motive could be to obtain system/application credentials or cryptographic keys. Shoulder surfing attacks are accomplished by observing the content "over the victim's shoulder", as implied by the name of this attack.
CAPEC-573: Process Footprinting
An adversary exploits functionality meant to identify information about the currently running processes on the target system to an authorized user. By knowing what processes are running on the target system, the adversary can learn about the target environment as a means towards further malicious behavior.
CAPEC-574: Services Footprinting
An adversary exploits functionality meant to identify information about the services on the target system to an authorized user. By knowing what services are registered on the target system, the adversary can learn about the target environment as a means towards further malicious behavior. Depending on the operating system, commands that can obtain services information include "sc" and "tasklist/svc" using Tasklist, and "net start" using Net.
CAPEC-575: Account Footprinting
An adversary exploits functionality meant to identify information about the domain accounts and their permissions on the target system to an authorized user. By knowing what accounts are registered on the target system, the adversary can inform further and more targeted malicious behavior. Example Windows commands which can acquire this information are: "net user" and "dsquery".
CAPEC-576: Group Permission Footprinting
An adversary exploits functionality meant to identify information about user groups and their permissions on the target system to an authorized user. By knowing what users/permissions are registered on the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command which can list local groups is "net localgroup".
CAPEC-577: Owner Footprinting
An adversary exploits functionality meant to identify information about the primary users on the target system to an authorized user. They may do this, for example, by reviewing logins or file modification times. By knowing what owners use the target system, the adversary can inform further and more targeted malicious behavior. An example Windows command that may accomplish this is "dir /A ntuser.dat". Which will display the last modified time of a user's ntuser.dat file when run within the root folder of a user. This time is synonymous with the last time that user was logged in.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-616: Establish Rogue Location
An adversary provides a malicious version of a resource at a location that is similar to the expected location of a legitimate resource. After establishing the rogue location, the adversary waits for a victim to visit the location and access the malicious resource.
CAPEC-643: Identify Shared Files/Directories on System
An adversary discovers connections between systems by exploiting the target system's standard practice of revealing them in searchable, common areas. Through the identification of shared folders/drives between systems, the adversary may further their goals of locating and collecting sensitive information/files, or map potential routes for lateral movement within the network.
CAPEC-646: Peripheral Footprinting
Adversaries may attempt to obtain information about attached peripheral devices and components connected to a computer system. Examples may include discovering the presence of iOS devices by searching for backups, analyzing the Windows registry to determine what USB devices have been connected, or infecting a victim system with malware to report when a USB device has been connected. This may allow the adversary to gain additional insight about the system or network environment, which may be useful in constructing further attacks.
CAPEC-651: Eavesdropping
An adversary intercepts a form of communication (e.g. text, audio, video) by way of software (e.g., microphone and audio recording application), hardware (e.g., recording equipment), or physical means (e.g., physical proximity). The goal of eavesdropping is typically to gain unauthorized access to sensitive information about the target for financial, personal, political, or other gains. Eavesdropping is different from a sniffing attack as it does not take place on a network-based communication channel (e.g., IP traffic). Instead, it entails listening in on the raw audio source of a conversation between two or more parties.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.