CVE-2026-108856 in Wanwu
Summary
by MITRE • 10/11/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in UnicomAI Wanwu versions up to 0.6.5 represents a critical authorization bypass flaw within the application key management subsystem. This security defect specifically affects the endpoint POST /v1/appspace/app/key, which is designed for authenticated users to generate new Application Keys (AppKeys). The core technical failure lies in the server-side validation logic that fails to enforce proper ownership checks when binding an AppKey to a Model Context Protocol (MCP) server. Instead of verifying that the requesting user possesses administrative or owner privileges over the target MCP server identified by its UUID, the system accepts any valid authentication token and associates it with the specified resource identifier provided in the request payload. This lack of access control verification allows an authenticated attacker to arbitrarily select a victim's MCP server UUID and assign their own AppKey to that specific server instance.
The operational impact of this vulnerability is severe as it effectively compromises the isolation between different users within the multi-tenant architecture of UnicomAI Wanwu. By successfully exploiting this flaw, an attacker can mint credentials that are bound to a victim's infrastructure without possessing any prior authorization for that resource. Once the AppKey is generated and linked to the victim's MCP server UUID, the attacker gains the ability to open new Model Context Protocol sessions using these stolen credentials. These sessions inherit the upstream authentication context of the victim, meaning the system treats requests made with the forged key as if they were originating from the legitimate owner of the MCP server. This undermines the fundamental security principle that API keys should only grant access to resources explicitly owned or authorized by the key holder.
The exploitation chain allows for significant lateral movement and data exfiltration risks within the platform's ecosystem. Since Model Context Protocol servers often expose tools, functions, or data sources to AI agents, an attacker utilizing a victim-bound AppKey can invoke these server-side tools as if they were the legitimate user. This capability enables unauthorized access to sensitive data processed by those tools, potential manipulation of external systems connected via the MCP interface, and abuse of computational resources associated with the victim's account. The vulnerability essentially transforms standard authentication into a mechanism for privilege escalation across resource boundaries, allowing attackers to impersonate other tenants or users within the same deployment instance without needing their credentials directly.
From a classification perspective, this issue aligns closely with CWE-284 Improper Access Control and specifically CVE-style authorization bypass scenarios where object-level permissions are not validated against the requester's identity. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts, as attackers leverage legitimate authentication tokens to gain unauthorized access to specific resources, and potentially T1552 Unsecured Credentials if the AppKeys themselves become targets for further exploitation or persistence mechanisms. The flaw highlights a common architectural weakness in API design where resource identifiers are accepted from client inputs without rigorous server-side ownership verification against the authenticated session context.
Mitigation strategies must focus on implementing strict object-level access control checks at the application layer before any key generation occurs. Developers should modify the POST /v1/appspace/app/key endpoint to verify that the authenticated user has explicit permission, such as owner or admin rights, over the MCP server UUID provided in the request body. If the user lacks these permissions, the system must reject the request with an appropriate authorization error rather than proceeding with key generation. Additionally, implementing principle of least privilege for API endpoints and conducting regular security audits focused on cross-resource access patterns can help prevent similar vulnerabilities. For existing deployments running version 0.6.5 or earlier, immediate patching to a fixed release is required to close this gap in the authorization logic and restore proper tenant isolation within the UnicomAI Wanwu platform.