Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-10-11T14:17:05.370Z",
  "pubdate": "2026-10-11T14:17:05.370Z",
  "executiveSummary": "UnicomAI Wanwu through version 0.6.5 is susceptible to an authorization bypass vulnerability within the API endpoint responsible for managing application keys.\nThe vulnerability originates from improper access control validation during the key issuance process. Specifically, the system fails to verify that the requesting user possesses legitimate ownership or authorization over a target Model Context Protocol (MCP) server when creating an AppKey.\nBy manipulating the request parameters sent to the /v1/appspace/app/key endpoint, an authenticated attacker can successfully mint an AppKey associated with a victim's MCP server UUID.\nThis flaw allows an attacker to masquerade as the legitimate owner of an MCP server, thereby gaining unauthorized access to the victim’s MCP sessions and associated tools.\nBecause the system utilizes the victim's upstream authentication when tools are invoked, the attacker can execute sensitive operations with the privileges of the victim, leading to potential data exfiltration, unauthorized service execution, and systemic compromise of the integration ecosystem.\nThe risk is critical for multi-tenant environments where MCP servers are shared or managed under distinct user identities, as it enables lateral movement and resource hijacking without administrative intervention.",
  "technicalDetails": "The vulnerability resides in the server-side logic handling the POST /v1/appspace/app/key request. During the process of creating an AppKey for an application space, the application expects an input parameter defining the target MCP server UUID. The root cause of the flaw is an authorization logic failure where the application performs the minting operation without cross-referencing the requesting user's identity against the ownership records of the specified MCP server UUID.\nIn a legitimate request, the authenticated user supplies their own MCP server credentials to generate an AppKey for integrating tools. In this attack scenario, an authenticated attacker identifies the victim's MCP server UUID—which may be exposed or guessable through other enumerative API calls—and explicitly sets the appType parameter to 'mcpserver'. Upon receiving this request, the backend service incorrectly assumes that the creation request is authorized based solely on the attacker’s authenticated session state, failing to perform a secondary ownership check to ensure the attacker has the rights to associate an AppKey with the target UUID.\nThe attack flow follows these specific steps: First, the attacker authenticates to their own legitimate account within the UnicomAI Wanwu environment. Second, the attacker discovers or targets a victim's unique MCP server UUID. Third, the attacker crafts a POST request to the /v1/appspace/app/key endpoint, injecting the victim's UUID and setting the application type to 'mcpserver'. Fourth, the server processes the request and returns a valid AppKey that is cryptographically or logically bound to the victim’s server configuration. Finally, the attacker utilizes this issued AppKey to initialize an MCP session. As the system proceeds to invoke the victim's upstream authentication tokens during subsequent tool execution calls, the attacker effectively acts as the victim within the context of that MCP server.\nThis vulnerability is particularly dangerous because the underlying authentication mechanism treats the attacker's requests as authorized sessions belonging to the victim. The exposure is internal to the API framework, requiring the attacker to hold an account on the platform but no administrative or special privileges. Post-exploitation, the attacker can leverage the victim’s tool access to manipulate data or interact with downstream services that trust the victim's authenticated session context, resulting in full unauthorized access to the target MCP resources."
}