Critical Command Injection in AgentScope MCP Workspace
A high-severity vulnerability tracked as **CVE-2026-123022** has been disclosed in agentscope-ai AgentScope, affecting versions up to 2.0.11. The flaw permits unauthenticated remote attackers to execute arbitrary operating system commands on servers running the AgentScope agent framework.
Vulnerability Details
The vulnerability resides in the MCP (Model Context Protocol) workspace API endpoint, specifically in the file `src/agentscope/mcp/_config.py` within the `subprocess.Popen` function call. According to the public advisory, the `StdioMCPConfig.command` field is declared as a string with no validators and no allowlist or trusted-directory restriction.
The `POST /workspace/mcp` endpoint accepts caller-supplied stdio MCP configurations whose `command` field names an arbitrary local executable. When the configuration is saved, the server spawns that process. The vulnerability is classified as CWE-78 (OS Command Injection).
Attack Vector
The endpoint enforces no server-side authentication or authorization. The caller-supplied `X-User-ID` header—described in the source code as “Temporary header-based identity”—is accepted as identity context and can be trivially spoofed. An attacker who can reach the AgentScope API (which defaults to binding on 0.0.0.0:8000 in LocalWorkspace mode) can register a stdio MCP entry that executes an arbitrary local executable with attacker-controlled arguments.
For stateful MCPs, the `add_mcp()` function calls `mcp_client.connect()` immediately on save, so the configured process starts before MCP protocol negotiation completes.
Impact and Severity
The National Vulnerability Database assigned this vulnerability a CVSS score of **7.3 (High)**. The public advisory from the security researcher who discovered the flaw assessed it as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which would yield a score of 9.8 (Critical) if the PR:N (no privileges required) metric is confirmed.
Successful exploitation grants the attacker remote code execution as the OS user running the AgentScope server, enabling:
- Disclosure of local files and environment variables, including LLM API keys
- Modification or deletion of application data
- Installation of further payloads
- Denial of service
No credentials, user interaction, or special preconditions are required beyond network reachability.
Proof of Concept
The vulnerability was dynamically verified on 2026-07-08 against agentscope version 2.0.4 on Windows 11. The researcher registered a command `”cmd”` with arguments `[“/c”,echo POC_MARKER > poc_marker.txt]`, which successfully created the marker file containing `POC_MARKER`. The subsequent HTTP 500 error or timeout is the expected MCP handshake failure—`subprocess.Popen` had already spawned the attacker’s process by that point.
Affected Versions and Status
The vulnerability affects AgentScope versions up to and including **2.0.11**. According to the NVD listing, a pull request to fix this issue has been submitted but awaits acceptance. Pull request #3448 on the AgentScope GitHub repository proposes adding an opt-in allowlist for stdio MCP commands through a new `allowed_stdio_commands` parameter in `create_app()`.
When set, a stdio MCP whose command is not listed would be rejected with HTTP 403 before the workspace starts it. The proposed fix includes:
- `None` (default): unchanged behavior, no breaking change
- `[“npx”, “uvx”]`: only listed commands accepted
- `[]`: stdio MCPs refused entirely on the endpoint
Matching is exact (no basename/path normalization). HTTP MCPs are not affected by the allowlist.
Disclosure Timeline
The issue was initially reported privately via GitHub Private Vulnerability Reporting on **2026-07-08** (advisory GHSA-h4fc-fmm3-h8hg). As of 2026-08-30, the advisory remained in Triage status with no maintainer response, prompting the researcher to file a public bug report as issue #3312 on **2026-10-14**. The pull request #3448 was opened on **2026-10-23**.
Workarounds
Until a patch is released and applied, administrators can mitigate the risk by:
- Binding the AgentScope service to `127.0.0.1` instead of `0.0.0.0`
- Blocking `POST /workspace/mcp` at the network or reverse-proxy layer
- Using Docker or E2B workspace backends, which contain the spawned process in a sandbox (though the command still executes within the sandbox)
Recommendations
Organizations running AgentScope in production should immediately implement the workarounds listed above if the service is exposed to untrusted networks. Monitor the official AgentScope repository for the acceptance and release of pull request #3448 or an alternative fix, and apply updates as soon as they become available.
The researcher’s full advisory notes that this vulnerability is separate from another authentication issue (issue #3314) concerning X-User-ID header spoofing, which is addressed by a different pull request (#3329).
