CWE-346
Allowed-with-ReviewOrigin Validation Error
Abstraction: Class · Status: Draft
The product does not properly verify that the source of data or communication is valid.
779 vulnerabilities reference this CWE, most recent first.
GHSA-VHFM-8GX7-F4CP
Vulnerability from github – Published: 2023-06-13 21:30 – Updated: 2024-04-04 04:48The underlying feedback mechanism of
Rockwell Automation's FactoryTalk System Services that transfers the FactoryTalk Policy Manager rules to relevant devices on the network does not verify that the origin of the communication is from a legitimate local client device. This may allow a threat actor to craft a malicious website that, when visited, will send a malicious script that can connect to the local WebSocket endpoint and wait for events as if it was a valid client device. If successfully exploited, this would allow a threat actor to receive information including whether FactoryTalk Policy Manager is installed and potentially the entire security policy.
{
"affected": [],
"aliases": [
"CVE-2023-2639"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-13T21:15:10Z",
"severity": "MODERATE"
},
"details": "The underlying feedback mechanism of \n\nRockwell Automation\u0027s\u00a0FactoryTalk System Services that transfers the FactoryTalk Policy Manager rules to relevant devices on the network does not verify that the origin of the communication is from a legitimate local client device.\u00a0 This may allow a threat actor to craft a malicious website that, when visited, will send a malicious script that can connect to the local WebSocket endpoint and wait for events as if it was a valid client device. If successfully exploited, this would allow a threat actor to receive information including whether FactoryTalk Policy Manager is installed and potentially the entire security policy.\u00a0\n\n\n",
"id": "GHSA-vhfm-8gx7-f4cp",
"modified": "2024-04-04T04:48:04Z",
"published": "2023-06-13T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2639"
},
{
"type": "WEB",
"url": "https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1139683"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VJM9-GQ46-WC5J
Vulnerability from github – Published: 2025-12-18 18:30 – Updated: 2026-02-11 15:30A Cross-Origin Resource Sharing (CORS) misconfiguration vulnerability exists in Dify v1.9.1 in the /console/api/setup endpoint. The endpoint implements an insecure CORS policy that reflects any Origin header and enables Access-Control-Allow-Credentials: true, permitting arbitrary external domains to make authenticated requests.
{
"affected": [],
"aliases": [
"CVE-2025-63386"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T16:15:54Z",
"severity": "CRITICAL"
},
"details": "A Cross-Origin Resource Sharing (CORS) misconfiguration vulnerability exists in Dify v1.9.1 in the /console/api/setup endpoint. The endpoint implements an insecure CORS policy that reflects any Origin header and enables Access-Control-Allow-Credentials: true, permitting arbitrary external domains to make authenticated requests.",
"id": "GHSA-vjm9-gq46-wc5j",
"modified": "2026-02-11T15:30:21Z",
"published": "2025-12-18T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63386"
},
{
"type": "WEB",
"url": "https://github.com/langgenius/dify/pull/32224"
},
{
"type": "WEB",
"url": "https://gist.github.com/Cristliu/1610daac87c711ac3e0250c58f5cc4f9"
},
{
"type": "WEB",
"url": "https://gist.github.com/Cristliu/8ad993126be05c9210c71cc7d49fa112"
},
{
"type": "WEB",
"url": "https://github.com/langgenius/dify/discussions"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VJQH-VXPX-8294
Vulnerability from github – Published: 2025-06-26 21:31 – Updated: 2025-06-26 21:31Autel MaxiCharger AC Wallbox Commercial Origin Validation Error Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Autel MaxiCharger AC Wallbox Commercial. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.
The specific flaw exists within the handling of bluetooth pairing requests. The issue results from insufficient validation of the origin of commands. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26353.
{
"affected": [],
"aliases": [
"CVE-2025-5824"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-25T18:15:23Z",
"severity": "MODERATE"
},
"details": "Autel MaxiCharger AC Wallbox Commercial Origin Validation Error Authentication Bypass Vulnerability. This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of Autel MaxiCharger AC Wallbox Commercial. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the handling of bluetooth pairing requests. The issue results from insufficient validation of the origin of commands. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-26353.",
"id": "GHSA-vjqh-vxpx-8294",
"modified": "2025-06-26T21:31:13Z",
"published": "2025-06-26T21:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5824"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-343"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-VJX2-FP9G-Q2MC
Vulnerability from github – Published: 2026-07-14 09:31 – Updated: 2026-07-14 21:31In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3. An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.
When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.
{
"affected": [],
"aliases": [
"CVE-2026-15076"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T09:16:40Z",
"severity": "HIGH"
},
"details": "In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server\u0027s domain, in violation of RFC 6265 section 5.3.\nAn attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain.\n\n\n\n\nWhen the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker\u0027s account. Sensitive data included in the victim application\u0027s requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.",
"id": "GHSA-vjx2-fp9g-q2mc",
"modified": "2026-07-14T21:31:35Z",
"published": "2026-07-14T09:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15076"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/work_items/162"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/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"
}
]
}
GHSA-VM32-9RQF-RH3R
Vulnerability from github – Published: 2024-12-10 22:42 – Updated: 2024-12-10 22:42Summary
pnpm seems to mishandle overrides and global cache: 1. Overrides from one workspace leak into npm metadata saved in global cache 2. npm metadata from global cache affects other workspaces 3. installs by default don't revalidate the data (including on first lockfile generation)
This can make workspace A (even running with ignore-scripts=true) posion global cache and execute scripts in workspace B
Users generally expect ignore-scripts to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it).
Here, that expectation is broken
Details
See PoC.
In it, overrides from a single run of A get leaked into e.g. ~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json and persistently affect all other projects using the cache
PoC
Postinstall code used in PoC is benign and can be inspected in https://www.npmjs.com/package/ponyhooves?activeTab=code, it's just a console.log
- Remove store and cache
On mac:
rm -rf ~/Library/Caches/pnpm ~/Library/pnpm/storeThis step is not required in general, but we'll be using a popular package for PoC that's likely cached - Create
A/package.json:json { "name": "A", "pnpm": { "overrides": { "rimraf>glob": "npm:ponyhooves@1" } }, "dependencies": { "rimraf": "6.0.1" } }Install it withpnpm i --ignore-scripts(the flag is not required, but the point of the demo is to show that it doesn't help) - Create
B/package.json:json { "name": "B", "dependencies": { "rimraf": "6.0.1" } }Install it withpnpm i
Result:
Packages: +3
+++
Progress: resolved 3, reused 3, downloaded 0, added 3, done
node_modules/.pnpm/ponyhooves@1.0.1/node_modules/ponyhooves: Running postinstall script, done in 51ms
dependencies:
+ rimraf 6.0.1
Done in 1.4s
Also, that code got leaked into another project and it's lockfile now!
Impact
Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs
As a work-around, use separate cache and store dirs in each workspace
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-53866"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-426"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-10T22:42:41Z",
"nvd_published_at": "2024-12-10T18:15:42Z",
"severity": "MODERATE"
},
"details": "### Summary\n\npnpm seems to mishandle overrides and global cache:\n1. Overrides from one workspace leak into npm metadata saved in global cache\n2. npm metadata from global cache affects other workspaces\n3. installs by default don\u0027t revalidate the data (including on first lockfile generation)\n\nThis can make workspace A (even running with `ignore-scripts=true`) posion global cache and execute scripts in workspace B\n\nUsers generally expect `ignore-scripts` to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it).\n\nHere, that expectation is broken\n\n### Details\n\nSee PoC.\n\nIn it, overrides from a single run of A get leaked into e.g. `~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json` and persistently affect all other projects using the cache\n\n### PoC\n\nPostinstall code used in PoC is benign and can be inspected in \u003chttps://www.npmjs.com/package/ponyhooves?activeTab=code\u003e, it\u0027s just a `console.log`\n\n1. Remove store and cache\n On mac: `rm -rf ~/Library/Caches/pnpm ~/Library/pnpm/store`\n This step is not required in general, but we\u0027ll be using a popular package for PoC that\u0027s likely cached\n2. Create `A/package.json`:\n ```json\n {\n \"name\": \"A\",\n \"pnpm\": { \"overrides\": { \"rimraf\u003eglob\": \"npm:ponyhooves@1\" } },\n \"dependencies\": { \"rimraf\": \"6.0.1\" }\n }\n ```\n Install it with `pnpm i --ignore-scripts` (the flag is not required, but the point of the demo is to show that it doesn\u0027t help)\n4. Create `B/package.json`:\n ```json\n {\n \"name\": \"B\",\n \"dependencies\": { \"rimraf\": \"6.0.1\" }\n }\n ```\n Install it with `pnpm i`\n\nResult:\n```console\nPackages: +3\n+++\nProgress: resolved 3, reused 3, downloaded 0, added 3, done\nnode_modules/.pnpm/ponyhooves@1.0.1/node_modules/ponyhooves: Running postinstall script, done in 51ms\n\ndependencies:\n+ rimraf 6.0.1\n\nDone in 1.4s\n```\n\nAlso, that code got leaked into another project and it\u0027s lockfile now! \n\n### Impact\n\nGlobal state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs\n\nAs a work-around, use separate cache and store dirs in each workspace\n",
"id": "GHSA-vm32-9rqf-rh3r",
"modified": "2024-12-10T22:42:41Z",
"published": "2024-12-10T22:42:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-vm32-9rqf-rh3r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53866"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/commit/11afcddea48f25ed5117a87dc1780a55222b9743"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "pnpm no-script global cache poisoning via overrides / `ignore-scripts` evasion"
}
GHSA-VM4V-PX5Q-M49V
Vulnerability from github – Published: 2022-05-24 17:02 – Updated: 2024-04-04 02:41An issue was discovered in TitanHQ WebTitan before 5.18. It contains a Remote Code Execution issue through which an attacker can execute arbitrary code as root. The issue stems from the hotfix download mechanism, which downloads a shell script via HTTP, and then executes it as root. This is analogous to CVE-2019-6800 but for a different product.
{
"affected": [],
"aliases": [
"CVE-2019-19019"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-02T17:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in TitanHQ WebTitan before 5.18. It contains a Remote Code Execution issue through which an attacker can execute arbitrary code as root. The issue stems from the hotfix download mechanism, which downloads a shell script via HTTP, and then executes it as root. This is analogous to CVE-2019-6800 but for a different product.",
"id": "GHSA-vm4v-px5q-m49v",
"modified": "2024-04-04T02:41:28Z",
"published": "2022-05-24T17:02:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19019"
},
{
"type": "WEB",
"url": "https://write-up.github.io/webtitan"
},
{
"type": "WEB",
"url": "https://www.webtitan.com/resources/product-updates"
}
],
"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-VMF9-XX9W-86WX
Vulnerability from github – Published: 2026-06-18 13:52 – Updated: 2026-06-18 13:52PraisonAI ToolsMCPServer legacy SSE transport accepts attacker Host/Origin and exposes registered tools
Summary
praisonaiagents.mcp.ToolsMCPServer.run_sse() builds a Starlette MCP
HTTP+SSE server around mcp.server.sse.SseServerTransport. The server exposes
/sse and /messages/, but it does not validate Origin, does not validate
Host, and does not require any authentication.
This is reachable through supported PraisonAI code paths that wrap configured MCP server tools and re-expose them over legacy SSE:
praisonai mcp run <name> --transport ssepraisonai serve mcp --name <name> --transport sse- direct use of
ToolsMCPServer(...).run_sse(...)orlaunch_tools_mcp_server(..., transport="sse")
A malicious website can use DNS rebinding against a local or internal
PraisonAI SSE MCP server and send requests with attacker-controlled Host and
Origin headers. The local PoV binds only to 127.0.0.1, sends an attacker
Host and Origin, lists the registered tool, and invokes it successfully.
The same attacker Origin is rejected by PraisonAI's current Streamable HTTP
transport with HTTP 403. The vulnerability is therefore a sibling transport
guard gap in the legacy SSE wrapper, not intended behavior.
Affected product
- Repository:
MervinPraison/PraisonAI - Packages:
praisonaiagentspraisonai- Primary component:
src/praisonai-agents/praisonaiagents/mcp/mcp_server.py - CLI wrappers:
src/praisonai/praisonai/cli/commands/mcp.pysrc/praisonai/praisonai/cli/commands/serve.py- Latest verified release/current head:
praisonaiagents 1.6.58PraisonAI 4.6.58- repo head
1ad58ca02975ff1398efeda694ea2ab78f20cf3e
Suggested affected ranges:
praisonaiagents >= 0.6.0, <= 1.6.58praisonai >= 3.10.0, <= 4.6.58
No fixed version is known at submission time.
Confirmed source sweep:
v3.0.0 ToolsMCPServer.run_sse helper present, no Origin/Host/auth checks
v3.10.0 praisonai mcp run --transport sse wraps configured tools into helper
v3.12.3 praisonai serve mcp --name --transport sse wraps configured tools
v4.0.0 same vulnerable helper and CLI wrapping paths
v4.4.12 same vulnerable helper and CLI wrapping paths
v4.5.0 same vulnerable helper and CLI wrapping paths
v4.5.56 same vulnerable helper and CLI wrapping paths
v4.5.139 same vulnerable helper and CLI wrapping paths
v4.6.57 same vulnerable helper and CLI wrapping paths
v4.6.58 same vulnerable helper and dynamic PoV succeeds
Impact
If a PraisonAI user starts a local or internal legacy SSE MCP server with registered tools, an attacker who gets that user to visit a malicious website can use DNS rebinding to interact with the SSE server through the browser. The attacker can discover exposed tools and invoke them as the local user.
Impact depends on the configured tools. In realistic PraisonAI MCP deployments, registered tools may access local files, repositories, issue trackers, cloud APIs, internal services, or other automation targets. This can lead to confidentiality, integrity, and availability impact for the resources reachable by the exposed tools.
The PoV is local-only and harmless. It exposes one marker tool that writes a canary string to a temporary directory.
Root cause
Current ToolsMCPServer.run_sse() constructs a Starlette app directly:
sse_path = "/sse"
messages_path = "/messages/"
sse_transport = SseServerTransport(messages_path)
async def handle_sse(request: Request):
async with sse_transport.connect_sse(
request.scope, request.receive, request._send
) as (read_stream, write_stream):
await mcp._mcp_server.run(
read_stream,
write_stream,
mcp._mcp_server.create_initialization_options()
)
app = Starlette(
debug=self._debug,
routes=[
Route(sse_path, endpoint=handle_sse),
Mount(messages_path, app=sse_transport.handle_post_message),
]
)
uvicorn.run(app, host=host, port=port)
There is no middleware or route-level check for:
OriginHostAuthorization- API key
- allowed origins / allowed hosts
The configured CLI wrapper exposes this path:
from praisonaiagents.mcp import MCP, ToolsMCPServer
cmd_string = " ".join(cmd)
mcp = MCP(cmd_string, timeout=60, env=server.env or {})
tools = mcp.get_tools()
mcp_server = ToolsMCPServer(name=name, tools=tools)
mcp_server.run_sse(host=host, port=port)
By contrast, the current Streamable HTTP transport validates Origin and
returns HTTP 403 for an invalid origin:
origin = request.headers.get("Origin")
if not self._validate_origin(origin):
return JSONResponse(..., status_code=403)
Local-only PoV
Run from the harness checkout:
uv run --with mcp --with starlette --with uvicorn --with httpx --with anyio \
python submission-bundle/praisonai-prai-cand-015-mcp-sse-host-origin-bypass/poc/pov_prai_cand_015_sse_mcp_host_origin_bypass.py \
--repo-src artifacts/repos/praisonai-v4.6.58/src
Observed current-head result:
{
"candidate": "PRAI-CAND-015",
"http_stream_control": {
"attacker_origin": "http://attacker.example.test",
"rejects_attacker_origin": true,
"status_code": 403,
"transport": "current_http_stream"
},
"source_checks": {
"has_auth_check": false,
"has_host_check": false,
"has_origin_check": false,
"has_sse_transport": true,
"route_count": 2
},
"sse_probe": {
"attacker_headers": {
"Host": "attacker.example.test:62380",
"Origin": "http://attacker.example.test:62380"
},
"bind_host": "127.0.0.1",
"marker_value": "executed-from-attacker-origin",
"marker_written": true,
"server_started": true,
"tool_call_content": [
"recorded:executed-from-attacker-origin"
],
"tool_call_error": false,
"tool_names": [
"record_marker"
],
"vulnerable": true
},
"vulnerable": true
}
The PoV:
- imports the current
ToolsMCPServer; - registers one marker tool;
- monkey-patches
uvicorn.runonly to capture the exact Starlette app created byrun_sse(); - starts that app on
127.0.0.1; - connects to
/ssewith attacker-controlledHostandOrigin; - lists tools and calls the marker tool;
- runs a control against PraisonAI's current Streamable HTTP transport and
confirms the same attacker
Originis rejected with HTTP 403.
Why this is not intended behavior
This is not only a trust-model disagreement.
PraisonAI's MCP documentation describes Streamable HTTP, WebSocket, and legacy SSE as supported MCP transport mechanisms. The same documentation says the MCP module's security properties include origin validation, authentication headers, and secure session IDs. The transport guide also has a dedicated security section for origin validation as DNS rebinding prevention and authentication.
The official MCP specification warns that HTTP transports need origin validation to prevent DNS rebinding, should bind locally for local servers, and should implement authentication. It also says that without those protections, remote websites can interact with local MCP servers.
The upstream MCP Python SDK advisory GHSA-9h52-p55h-vw2f / CVE-2025-66416
classifies unauthenticated localhost HTTP/SSE MCP servers without DNS rebinding
protection as a High severity issue because malicious websites can invoke tools
or access resources exposed by the local MCP server. That advisory also says
custom low-level SseServerTransport configurations should explicitly configure
transport security settings when running unauthenticated localhost servers.
PraisonAI's current Streamable HTTP implementation already enforces an Origin guard and rejects the exact attacker Origin used in the PoV. The issue is that the legacy SSE sibling path lacks the same boundary.
Suggested severity
Suggested severity: High.
Rationale:
AV: the attack uses browser-origin HTTP requests to a local/internal service.AC: practical exploitation requires DNS rebinding or equivalent browser origin setup.PR: no PraisonAI credentials are required by the SSE server.UR: the user must visit an attacker-controlled page.S: the vulnerable transport exposes tools that operate on resources outside the HTTP transport itself.C/I/A: exposed tools may read, mutate, or disrupt local/internal resources depending on the configured MCP server.
Suggested fix
Bring legacy SSE server security in line with the current Streamable HTTP transport, or disable the legacy SSE server path.
Recommended changes:
- Add explicit allowed-origin and allowed-host validation to both
/sseand/messages/. - Reject invalid
Originwith HTTP 403 before opening the SSE stream or accepting POST messages. - Validate
Hostfor local and internal deployments to mitigate DNS rebinding even when browsers omit or varyOrigin. - Require authentication for all non-stdio MCP HTTP transports, including SSE.
- Add
--api-key,--allowed-origins, and--allowed-hostsoptions topraisonai mcp runandpraisonai serve mcpwhen--transport sseis used. - Where the installed MCP SDK supports it, configure the SDK transport-security
settings for low-level
SseServerTransportusage instead of mounting it without Host/Origin protection. - Consider deprecating or disabling
--transport sseserver mode in favor of the current Streamable HTTP implementation. - Add regression tests proving that attacker
HostandOriginvalues are rejected on both/sseand/messages/, and that current Streamable HTTP and legacy SSE enforce the same boundary.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.58"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonaiagents"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "1.6.59"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.58"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0"
},
{
"fixed": "4.6.59"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-346",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:52:40Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# PraisonAI ToolsMCPServer legacy SSE transport accepts attacker Host/Origin and exposes registered tools\n\n## Summary\n\n`praisonaiagents.mcp.ToolsMCPServer.run_sse()` builds a Starlette MCP\nHTTP+SSE server around `mcp.server.sse.SseServerTransport`. The server exposes\n`/sse` and `/messages/`, but it does not validate `Origin`, does not validate\n`Host`, and does not require any authentication.\n\nThis is reachable through supported PraisonAI code paths that wrap configured\nMCP server tools and re-expose them over legacy SSE:\n\n- `praisonai mcp run \u003cname\u003e --transport sse`\n- `praisonai serve mcp --name \u003cname\u003e --transport sse`\n- direct use of `ToolsMCPServer(...).run_sse(...)` or\n `launch_tools_mcp_server(..., transport=\"sse\")`\n\nA malicious website can use DNS rebinding against a local or internal\nPraisonAI SSE MCP server and send requests with attacker-controlled `Host` and\n`Origin` headers. The local PoV binds only to `127.0.0.1`, sends an attacker\n`Host` and `Origin`, lists the registered tool, and invokes it successfully.\n\nThe same attacker `Origin` is rejected by PraisonAI\u0027s current Streamable HTTP\ntransport with HTTP 403. The vulnerability is therefore a sibling transport\nguard gap in the legacy SSE wrapper, not intended behavior.\n\n## Affected product\n\n- Repository: `MervinPraison/PraisonAI`\n- Packages:\n - `praisonaiagents`\n - `praisonai`\n- Primary component:\n `src/praisonai-agents/praisonaiagents/mcp/mcp_server.py`\n- CLI wrappers:\n - `src/praisonai/praisonai/cli/commands/mcp.py`\n - `src/praisonai/praisonai/cli/commands/serve.py`\n- Latest verified release/current head:\n - `praisonaiagents 1.6.58`\n - `PraisonAI 4.6.58`\n - repo head `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n\nSuggested affected ranges:\n\n- `praisonaiagents \u003e= 0.6.0, \u003c= 1.6.58`\n- `praisonai \u003e= 3.10.0, \u003c= 4.6.58`\n\nNo fixed version is known at submission time.\n\nConfirmed source sweep:\n\n```text\nv3.0.0 ToolsMCPServer.run_sse helper present, no Origin/Host/auth checks\nv3.10.0 praisonai mcp run --transport sse wraps configured tools into helper\nv3.12.3 praisonai serve mcp --name --transport sse wraps configured tools\nv4.0.0 same vulnerable helper and CLI wrapping paths\nv4.4.12 same vulnerable helper and CLI wrapping paths\nv4.5.0 same vulnerable helper and CLI wrapping paths\nv4.5.56 same vulnerable helper and CLI wrapping paths\nv4.5.139 same vulnerable helper and CLI wrapping paths\nv4.6.57 same vulnerable helper and CLI wrapping paths\nv4.6.58 same vulnerable helper and dynamic PoV succeeds\n```\n\n## Impact\n\nIf a PraisonAI user starts a local or internal legacy SSE MCP server with\nregistered tools, an attacker who gets that user to visit a malicious website\ncan use DNS rebinding to interact with the SSE server through the browser. The\nattacker can discover exposed tools and invoke them as the local user.\n\nImpact depends on the configured tools. In realistic PraisonAI MCP deployments,\nregistered tools may access local files, repositories, issue trackers, cloud\nAPIs, internal services, or other automation targets. This can lead to\nconfidentiality, integrity, and availability impact for the resources reachable\nby the exposed tools.\n\nThe PoV is local-only and harmless. It exposes one marker tool that writes a\ncanary string to a temporary directory.\n\n## Root cause\n\nCurrent `ToolsMCPServer.run_sse()` constructs a Starlette app directly:\n\n```python\nsse_path = \"/sse\"\nmessages_path = \"/messages/\"\nsse_transport = SseServerTransport(messages_path)\n\nasync def handle_sse(request: Request):\n async with sse_transport.connect_sse(\n request.scope, request.receive, request._send\n ) as (read_stream, write_stream):\n await mcp._mcp_server.run(\n read_stream,\n write_stream,\n mcp._mcp_server.create_initialization_options()\n )\n\napp = Starlette(\n debug=self._debug,\n routes=[\n Route(sse_path, endpoint=handle_sse),\n Mount(messages_path, app=sse_transport.handle_post_message),\n ]\n)\n\nuvicorn.run(app, host=host, port=port)\n```\n\nThere is no middleware or route-level check for:\n\n- `Origin`\n- `Host`\n- `Authorization`\n- API key\n- allowed origins / allowed hosts\n\nThe configured CLI wrapper exposes this path:\n\n```python\nfrom praisonaiagents.mcp import MCP, ToolsMCPServer\ncmd_string = \" \".join(cmd)\nmcp = MCP(cmd_string, timeout=60, env=server.env or {})\ntools = mcp.get_tools()\nmcp_server = ToolsMCPServer(name=name, tools=tools)\nmcp_server.run_sse(host=host, port=port)\n```\n\nBy contrast, the current Streamable HTTP transport validates `Origin` and\nreturns HTTP 403 for an invalid origin:\n\n```python\norigin = request.headers.get(\"Origin\")\nif not self._validate_origin(origin):\n return JSONResponse(..., status_code=403)\n```\n\n## Local-only PoV\n\nRun from the harness checkout:\n\n```bash\nuv run --with mcp --with starlette --with uvicorn --with httpx --with anyio \\\n python submission-bundle/praisonai-prai-cand-015-mcp-sse-host-origin-bypass/poc/pov_prai_cand_015_sse_mcp_host_origin_bypass.py \\\n --repo-src artifacts/repos/praisonai-v4.6.58/src\n```\n\nObserved current-head result:\n\n```json\n{\n \"candidate\": \"PRAI-CAND-015\",\n \"http_stream_control\": {\n \"attacker_origin\": \"http://attacker.example.test\",\n \"rejects_attacker_origin\": true,\n \"status_code\": 403,\n \"transport\": \"current_http_stream\"\n },\n \"source_checks\": {\n \"has_auth_check\": false,\n \"has_host_check\": false,\n \"has_origin_check\": false,\n \"has_sse_transport\": true,\n \"route_count\": 2\n },\n \"sse_probe\": {\n \"attacker_headers\": {\n \"Host\": \"attacker.example.test:62380\",\n \"Origin\": \"http://attacker.example.test:62380\"\n },\n \"bind_host\": \"127.0.0.1\",\n \"marker_value\": \"executed-from-attacker-origin\",\n \"marker_written\": true,\n \"server_started\": true,\n \"tool_call_content\": [\n \"recorded:executed-from-attacker-origin\"\n ],\n \"tool_call_error\": false,\n \"tool_names\": [\n \"record_marker\"\n ],\n \"vulnerable\": true\n },\n \"vulnerable\": true\n}\n```\n\nThe PoV:\n\n1. imports the current `ToolsMCPServer`;\n2. registers one marker tool;\n3. monkey-patches `uvicorn.run` only to capture the exact Starlette app created\n by `run_sse()`;\n4. starts that app on `127.0.0.1`;\n5. connects to `/sse` with attacker-controlled `Host` and `Origin`;\n6. lists tools and calls the marker tool;\n7. runs a control against PraisonAI\u0027s current Streamable HTTP transport and\n confirms the same attacker `Origin` is rejected with HTTP 403.\n\n## Why this is not intended behavior\n\nThis is not only a trust-model disagreement.\n\nPraisonAI\u0027s MCP documentation describes Streamable HTTP, WebSocket, and legacy\nSSE as supported MCP transport mechanisms. The same documentation says the MCP\nmodule\u0027s security properties include origin validation, authentication headers,\nand secure session IDs. The transport guide also has a dedicated security\nsection for origin validation as DNS rebinding prevention and authentication.\n\nThe official MCP specification warns that HTTP transports need origin\nvalidation to prevent DNS rebinding, should bind locally for local servers, and\nshould implement authentication. It also says that without those protections,\nremote websites can interact with local MCP servers.\n\nThe upstream MCP Python SDK advisory `GHSA-9h52-p55h-vw2f` / `CVE-2025-66416`\nclassifies unauthenticated localhost HTTP/SSE MCP servers without DNS rebinding\nprotection as a High severity issue because malicious websites can invoke tools\nor access resources exposed by the local MCP server. That advisory also says\ncustom low-level `SseServerTransport` configurations should explicitly configure\ntransport security settings when running unauthenticated localhost servers.\n\nPraisonAI\u0027s current Streamable HTTP implementation already enforces an Origin\nguard and rejects the exact attacker Origin used in the PoV. The issue is that\nthe legacy SSE sibling path lacks the same boundary.\n\n\n## Suggested severity\n\nSuggested severity: High.\n\nRationale:\n\n- `AV`: the attack uses browser-origin HTTP requests to a local/internal\n service.\n- `AC`: practical exploitation requires DNS rebinding or equivalent browser\n origin setup.\n- `PR`: no PraisonAI credentials are required by the SSE server.\n- `UR`: the user must visit an attacker-controlled page.\n- `S`: the vulnerable transport exposes tools that operate on resources\n outside the HTTP transport itself.\n- `C/I/A`: exposed tools may read, mutate, or disrupt local/internal\n resources depending on the configured MCP server.\n\n## Suggested fix\n\nBring legacy SSE server security in line with the current Streamable HTTP\ntransport, or disable the legacy SSE server path.\n\nRecommended changes:\n\n1. Add explicit allowed-origin and allowed-host validation to both `/sse` and\n `/messages/`.\n2. Reject invalid `Origin` with HTTP 403 before opening the SSE stream or\n accepting POST messages.\n3. Validate `Host` for local and internal deployments to mitigate DNS rebinding\n even when browsers omit or vary `Origin`.\n4. Require authentication for all non-stdio MCP HTTP transports, including SSE.\n5. Add `--api-key`, `--allowed-origins`, and `--allowed-hosts` options to\n `praisonai mcp run` and `praisonai serve mcp` when `--transport sse` is used.\n6. Where the installed MCP SDK supports it, configure the SDK transport-security\n settings for low-level `SseServerTransport` usage instead of mounting it\n without Host/Origin protection.\n7. Consider deprecating or disabling `--transport sse` server mode in favor of\n the current Streamable HTTP implementation.\n8. Add regression tests proving that attacker `Host` and `Origin` values are\n rejected on both `/sse` and `/messages/`, and that current Streamable HTTP and\n legacy SSE enforce the same boundary.",
"id": "GHSA-vmf9-xx9w-86wx",
"modified": "2026-06-18T13:52:40Z",
"published": "2026-06-18T13:52:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmf9-xx9w-86wx"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI ToolsMCPServer legacy SSE transport accepts attacker Host/Origin and exposes registered tools"
}
GHSA-VQ57-688W-8QM4
Vulnerability from github – Published: 2021-12-14 00:00 – Updated: 2021-12-16 00:02IBM Spectrum Protect Plus 10.1.0.0 through 10.1.8.x uses Cross-Origin Resource Sharing (CORS) which could allow an attacker to carry out privileged actions and retrieve sensitive information due to a misconfiguration in access control headers. IBM X-Force ID: 214956.
{
"affected": [],
"aliases": [
"CVE-2021-39063"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-13T19:15:00Z",
"severity": "CRITICAL"
},
"details": "IBM Spectrum Protect Plus 10.1.0.0 through 10.1.8.x uses Cross-Origin Resource Sharing (CORS) which could allow an attacker to carry out privileged actions and retrieve sensitive information due to a misconfiguration in access control headers. IBM X-Force ID: 214956.",
"id": "GHSA-vq57-688w-8qm4",
"modified": "2021-12-16T00:02:37Z",
"published": "2021-12-14T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39063"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/214956"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6525346"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-VQ5P-C2V7-53V5
Vulnerability from github – Published: 2025-05-18 00:30 – Updated: 2025-05-18 00:30A vulnerability has been found in itwanger paicoding 1.0.0/1.0.1/1.0.2/1.0.3 and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /paicoding-core/src/main/java/com/github/paicoding/forum/core/util/CrossUtil.java. The manipulation leads to permissive cross-domain policy with untrusted domains. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-4839"
],
"database_specific": {
"cwe_ids": [
"CWE-346"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-17T22:15:19Z",
"severity": "LOW"
},
"details": "A vulnerability has been found in itwanger paicoding 1.0.0/1.0.1/1.0.2/1.0.3 and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /paicoding-core/src/main/java/com/github/paicoding/forum/core/util/CrossUtil.java. The manipulation leads to permissive cross-domain policy with untrusted domains. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-vq5p-c2v7-53v5",
"modified": "2025-05-18T00:30:26Z",
"published": "2025-05-18T00:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4839"
},
{
"type": "WEB",
"url": "https://github.com/ShenxiuSec/cve-proofs/blob/main/POC-20250510-02.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.309307"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.309307"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.574826"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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"
}
]
}
GHSA-VQP6-RC3H-83CP
Vulnerability from github – Published: 2022-11-21 22:34 – Updated: 2022-11-21 22:34A vulnerability identified in the Tailscale Windows client allows a malicious website to reconfigure the Tailscale daemon tailscaled, which can then be used to remotely execute code.
Affected platforms: Windows Patched Tailscale client versions: v1.32.3 or later, v1.33.257 or later (unstable)
What happened?
In the Tailscale Windows client, the local API was bound to a local TCP socket, and communicated with the Windows client GUI in cleartext with no Host header verification. This allowed an attacker-controlled website visited by the node to rebind DNS to an attacker-controlled DNS server, and then make local API requests in the client, including changing the coordination server to an attacker-controlled coordination server.
Who is affected?
All Windows clients prior to version v.1.32.3 are affected.
What should I do?
If you are running Tailscale on Windows, upgrade to v1.32.3 or later to remediate the issue.
What is the impact?
An attacker-controlled coordination server can send malicious URL responses to the client, including pushing executables or installing an SMB share. These allow the attacker to remotely execute code on the node.
Reviewing all logs confirms this vulnerability was not triggered or exploited.
Credits
We would like to thank Emily Trau and Jamie McClymont (CyberCX) for reporting this issue. Further detail is available in their blog post.
References
For more information
If you have any questions or comments about this advisory, contact Tailscale support.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "tailscale.com"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.32.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41924"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-21T22:34:00Z",
"nvd_published_at": "2022-11-23T19:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability identified in the Tailscale Windows client allows a malicious website to reconfigure the Tailscale daemon `tailscaled`, which can then be used to remotely execute code.\n\n**Affected platforms:** Windows\n**Patched Tailscale client versions:** v1.32.3 or later, v1.33.257 or later (unstable)\n\n### What happened?\nIn the Tailscale Windows client, the local API was bound to a local TCP socket, and communicated with the Windows client GUI in cleartext with no Host header verification. This allowed an attacker-controlled website visited by the node to rebind DNS to an attacker-controlled DNS server, and then make local API requests in the client, including changing the coordination server to an attacker-controlled coordination server.\n\n### Who is affected?\nAll Windows clients prior to version v.1.32.3 are affected.\n\n### What should I do?\nIf you are running Tailscale on Windows, upgrade to v1.32.3 or later to remediate the issue.\n\n### What is the impact?\nAn attacker-controlled coordination server can send malicious URL responses to the client, including pushing executables or installing an SMB share. These allow the attacker to remotely execute code on the node.\n\nReviewing all logs confirms this vulnerability was not triggered or exploited. \n\n### Credits\nWe would like to thank [Emily Trau](https://github.com/emilytrau) and [Jamie McClymont (CyberCX)](https://twitter.com/JJJollyjim) for reporting this issue. Further detail is available in [their blog post](https://emily.id.au/tailscale).\n\n### References\n* [TS-2022-004](https://tailscale.com/security-bulletins/#ts-2022-004)\n* [Researcher blog post](https://emily.id.au/tailscale)\n\n### For more information\nIf you have any questions or comments about this advisory, [contact Tailscale support](https://tailscale.com/contact/support/).\n",
"id": "GHSA-vqp6-rc3h-83cp",
"modified": "2022-11-21T22:34:00Z",
"published": "2022-11-21T22:34:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tailscale/tailscale/security/advisories/GHSA-vqp6-rc3h-83cp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41924"
},
{
"type": "WEB",
"url": "https://emily.id.au/tailscale"
},
{
"type": "PACKAGE",
"url": "https://github.com/tailscale/tailscale"
},
{
"type": "WEB",
"url": "https://github.com/tailscale/tailscale/releases/tag/v1.32.3"
},
{
"type": "WEB",
"url": "https://tailscale.com/security-bulletins/#ts-2022-004"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "Tailscale Windows daemon is vulnerable to RCE via CSRF"
}
No mitigation information available for this CWE.
CAPEC-111: JSON Hijacking (aka JavaScript Hijacking)
An attacker targets a system that uses JavaScript Object Notation (JSON) as a transport mechanism between the client and the server (common in Web 2.0 systems using AJAX) to steal possibly confidential information transmitted from the server back to the client inside the JSON object by taking advantage of the loophole in the browser's Same Origin Policy that does not prohibit JavaScript from one website to be included and executed in the context of another website.
CAPEC-141: Cache Poisoning
An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.
CAPEC-142: DNS Cache Poisoning
A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.
CAPEC-160: Exploit Script-Based APIs
Some APIs support scripting instructions as arguments. Methods that take scripted instructions (or references to scripted instructions) can be very flexible and powerful. However, if an attacker can specify the script that serves as input to these methods they can gain access to a great deal of functionality. For example, HTML pages support <script> tags that allow scripting languages to be embedded in the page and then interpreted by the receiving web browser. If the content provider is malicious, these scripts can compromise the client application. Some applications may even execute the scripts under their own identity (rather than the identity of the user providing the script) which can allow attackers to perform activities that would otherwise be denied to them.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.
CAPEC-510: SaaS User Request Forgery
An adversary, through a previously installed malicious application, performs malicious actions against a third-party Software as a Service (SaaS) application (also known as a cloud based application) by leveraging the persistent and implicit trust placed on a trusted user's session. This attack is executed after a trusted user is authenticated into a cloud service, "piggy-backing" on the authenticated session, and exploiting the fact that the cloud service believes it is only interacting with the trusted user. If successful, the actions embedded in the malicious application will be processed and accepted by the targeted SaaS application and executed at the trusted user's privilege level.
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-75: Manipulating Writeable Configuration Files
Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-89: Pharming
A pharming attack occurs when the victim is fooled into entering sensitive data into supposedly trusted locations, such as an online bank site or a trading platform. An attacker can impersonate these supposedly trusted sites and have the victim be directed to their site rather than the originally intended one. Pharming does not require script injection or clicking on malicious links for the attack to succeed.