AgentScope 2.0.11 Still Runs Any MCP Command, and pip-audit Misses It

Updated November 7, 2026. Lab on agentscope 2.0.11 from PyPI (Linux, Python 3.13), agent service bound to 127.0.0.1 only.

AgentScope, the open-source multi-agent framework from agentscope-ai with about 35,500 GitHub stars, received three CVEs on November 5, 2026. The worst AgentScope vulnerability, CVE-2026-123022, lets any caller who can reach the agent service register a stdio MCP server whose command the service spawns at once, and no released version fixes it. A second flaw, CVE-2026-123024, means the service trusts whatever user ID the caller puts in an X-User-ID header.

On November 7 we ran the latest release, 2.0.11, in a loopback-only lab. A forged header plus one POST to /workspace/mcp created our marker file in 0.03 seconds, and pip-audit reported no known vulnerabilities for the same package. Teams running the AgentScope agent service on a reachable interface should block POST /workspace/mcp and put an authenticating proxy in front of it today. Library-only users who never start the agent service are outside these two flaws.

What the Three AgentScope CVEs Cover

The three AgentScope CVEs cover the agent service layer, the FastAPI app started through create_app, plus one built-in tool. CVE-2026-123022 is command injection through the MCP workspace API, CVE-2026-123024 is missing authentication on the same service, and CVE-2026-123023 is an authorization error in the Bash tool. The VulDB CNA published all three on November 5, 2026.

CVE	Component	Affected	Fixed in	Record score (3.1 / 4.0)	Researcher score
CVE-2026-123022	MCP workspace API, subprocess.Popen via stdio config	Up to 2.0.11	No release; PR 3448 open	7.3 / 5.5	9.8 (CVSS 3.1)
CVE-2026-123024	Agent service, get_current_user_id in deps.py	Up to 2.0.11	No release; PR 3329 open	7.3 / 5.5	9.8 (CVSS 3.1)
CVE-2026-123023	Bash tool, tee in SAFE_COMMANDS	Up to 2.0.8	2.0.9 (commit 6b43b13)	7.3 / 5.5	8.1 (CVSS 3.1)

Independent researcher Yongbo Yu reported the issues privately through GitHub on July 8, 2026, according to issue 3312, and opened public issues 3312, 3313, and 3314 on October 14 after the private advisories sat in triage with no maintainer response. The MCP workspace issue now carries a triage/confirmed label. A separate contributor reproduced it against a live main deployment on October 15.

How the MCP Workspace Flaw Runs Code Before Any Handshake

The MCP workspace flaw runs code because AgentScope treats the stdio command field as trusted input. POST /workspace/mcp accepts a stdio MCP configuration and connects it at once, which spawns the named process through subprocess.Popen before the MCP handshake. The request can fail with HTTP 500 after the process has already run.

The Model Context Protocol (MCP) is the open standard agents use to call external tools, and a stdio MCP server is a local program the client starts and talks to over standard input and output. In AgentScope 2.0.11, the StdioMCPConfig.command field is a plain string with no allowlist, per the GHSA-m997-8g56-6phf record and the researcher write-up. Docker and E2B workspace backends keep the spawned process inside their sandbox, but the process still runs there.

Our probe registered /usr/bin/touch on a marker file inside the lab folder as the MCP server command. The service answered HTTP 500 Internal Server Error in 0.03 seconds, and the marker file existed 1 second later. For the AgentScope MCP workspace endpoint, an error response is not evidence that nothing ran. Log triage that only counts 2xx responses on /workspace/mcp will miss successful attempts.

Why the X-User-ID Header Makes It Unauthenticated

The AgentScope agent service has no login step. The get_current_user_id dependency in deps.py rejects only an empty X-User-ID header and returns whatever string the caller sends, and its own description calls it a temporary header-based identity that JWT auth will replace. Anyone who can reach the port can act as any user.

In our lab, a request with no header got 422 Field required, while the same request with X-User-ID: alice@example.com created an agent as that user with a 201. A follow-up request with the same header listed the agent, and a request as a different made-up user saw none, which shows tenant data is keyed only on the header value. The 2.0.11 OpenAPI schema lists 89 of 100 operations taking X-User-ID and defines no security scheme.

Issue 3314 states that the header-keyed data includes stored credentials such as LLM API keys, plus sessions, knowledge bases, and schedules. We did not store credentials in the lab, so that scope comes from the researcher report rather than our test. The header problem also removes any authentication barrier in front of the MCP workspace endpoint, which is why CVE-2026-123022 and CVE-2026-123024 work as one chain.

The Official Example Widens Exposure Beyond 0.0.0.0

The official agent_service example widens exposure in two ways. It starts uvicorn on 0.0.0.0:8000, which listens on every network interface, and it adds CORS middleware that allows every origin, method, and header. Binding the AgentScope service to 127.0.0.1 removes direct network access but leaves that permissive CORS policy in place.

We copied the example CORS settings into our loopback app and sent a preflight for POST /workspace/mcp from https://attacker.example. The service answered 200 with Access-Control-Allow-Origin: * and x-user-id listed as an allowed header. Teams that bind AgentScope to 127.0.0.1 but keep the example CORS block are relying on the browser alone to stop a malicious page from calling the service. Recent Chrome releases add local network access checks that may block or prompt for such requests; we did not test a browser end to end, so treat this as an exposure to close rather than a proven exploit.

Severity Scores Disagree, and Scanners Stay Silent

The CVE records and the researcher disagree on impact, and common dependency scanners do not flag the package yet. The VulDB-assigned records score each AgentScope flaw 7.3 under CVSS 3.1 and 5.5 under CVSS 4.0 with low impact, while the researcher scored the two unpatched flaws 9.8. pip-audit reports nothing for 2.0.11.

Both sets of scores share the same exploitability terms: network attack vector, low complexity, no privileges, and no user interaction. The gap sits in impact. The records rate confidentiality, integrity, and availability as Low, while the researcher rates all three High because the spawned process runs as the service operating system user, and our marker test is consistent with that reading for any deployment where that user can read secrets or write files.

The GitHub Advisory Database entries are marked Unreviewed and show “No package listed,” with affected and patched versions Unknown. pip-audit 2.10.1 returned “No known vulnerabilities found” for agentscope==2.0.11 against both its PyPI and OSV sources on November 7, and an OSV API query for the PyPI package returned zero results. A clean dependency scan is not evidence that an AgentScope deployment is safe this week.

What the Open Fix PRs Change

Two community pull requests target the unpatched AgentScope flaws, and neither is merged. PR 3329 adds an opt-in shared API key gate through an AGENTSCOPE_API_KEY environment variable. PR 3448 adds an opt-in allowed_stdio_commands list that rejects unlisted stdio commands with 403 before the workspace starts them.

We applied both PR diffs to the installed 2.0.11 package, and each applied without conflicts. With the key set and allowed_stdio_commands set to npx and uvx, a request without the key got 401, the touch probe got 403 with no marker file, and the cross-origin preflight got 401. Stock 2.0.11 failed all three checks.

Both changes have limits their own authors state. PR 3329 is a gateway gate rather than identity, and in our lab a caller holding the shared key still created an agent as alice@example.com. PR 3448 matches command names exactly, and its author notes it does not sandbox the process or cover stdio entries stored in a user library before the list was switched on.

An allowlist that includes npx still lets the caller choose which npm package npx runs, so a list of package runners narrows the AgentScope attack surface rather than closing it. That point is our inference from how npx works, not a tested bypass. An empty list, which PR 3448 supports, refuses stdio MCP registration on that endpoint entirely.

What AgentScope Operators Should Do Now

AgentScope operators should treat any network-reachable agent service on 2.0.11 or earlier as exposed until a fixed release ships. Block POST /workspace/mcp at the proxy, require authentication in front of the service, strip inbound X-User-ID headers, and upgrade to at least 2.0.9 for the Bash tool fix.

1. Find every running agent service: search deployments for create_app from agentscope.app or a copy of the agent_service example, and check which interface uvicorn binds.
2. Bind to 127.0.0.1 or a private interface, and replace allow_origins=["*"] with the named front-end origin you actually use.
3. Put an authenticating reverse proxy in front that strips any inbound X-User-ID and injects a verified one, the stopgap issue 3314 recommends.
4. Deny POST /workspace/mcp at the proxy unless an administrator path needs it, and alert on every request to that route, including ones that return 500.
5. Upgrade to 2.0.9 or later for CVE-2026-123023, then watch the AgentScope releases page for a build that merges 3329, 3448, or a maintainer fix.
6. Rotate LLM provider keys and other credentials the service stored if it was ever reachable from an untrusted network.

Choose network-layer blocking today when you run the AgentScope agent service for more than one user, because the fix PRs are opt-in and unmerged. Choose to carry the two PRs as local patches only when you can maintain a fork and retest every upgrade yourself. Neither path helps a service that already ran on 0.0.0.0 with secrets in its environment, so rotate those first. Python library users who never start the agent service are outside CVE-2026-123022 and CVE-2026-123024, though they should still take the 2.0.9 Bash tool fix.

How This Fits the Agent Framework Security Pattern

AgentScope joins a run of agent frameworks whose service layers shipped before their authentication did. The pattern is consistent: a convenience API for registering tools or MCP servers becomes a process launcher once the service listens on a network. MCP gateway controls and tool allowlists belong in front of every self-hosted agent service, whichever framework it runs.

Langflow fixes covered in our Langflow 1.13.0 auto-login analysis included unauthenticated RCE through MCP tool enumeration. Our FastMCP security advisories coverage tracked client RCE from malicious servers, and the MCP Inspector 2.14.0 security note covered registry imports that hid stdio flags. Teams comparing frameworks can check service and permission models in our open-source AI agent frameworks guide and multi-agent frameworks comparison.

For controls outside any single framework, our AI agent security tools guide and MCP gateways roundup cover allowlists, audit logs, and identity at the tool boundary. A gateway built on a fixed server registry refuses free-form process definitions from API callers by design, which is the control AgentScope 2.0.11 lacks on /workspace/mcp.

FAQ