UnicomAI Wanwu CVE-2026-108856

Exploitation requires an authenticated Wanwu account (PR:L) and knowledge of the target victim's MCP server UUID, which must be supplied with appType=mcpserver to the POST /v1/appspace/app/key endpoint; this UUID requirement is the primary limiting factor and drives the High attack complexity. The flaw is reachable remotely over the network with no user interaction, and applies to the default behavior of the AppKey-minting endpoint in versions through 0.6.5 (the authorization check in the OpenAPI auth middleware does not bind key creation to the requesting user's ownership of the target MCP server). Realistic impact is further bounded by what the victim's downstream MCP tools and upstream authentication permit.

This is a genuinely low-priority issue, and the signals are internally consistent rather than conflicting. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) yields only 2.3 (Low): exploitation requires an already-authenticated account (PR:L), high attack complexity (AC:H) because the attacker must know or obtain a victim's MCP server UUID, and the impact is limited (confidentiality and integrity Low, availability None, no scope change to other systems). It is NOT in CISA KEV, so there is no confirmed active exploitation, and no public exploit code is identified - a detailed technical write-up (hackmd) and source-line references exist, but a write-up is not weaponized exploit code. EPSS is not provided in the input, so probabilistic exploitation likelihood cannot be quantified here. The one factor that can elevate real-world impact beyond the raw score is the nature of the asset: by minting an AppKey against another user's MCP server, the attacker invokes that server's tools using the victim's upstream authentication - so the practical blast radius depends entirely on what those downstream MCP tools can do (data access, actions). Bottom line: low technical severity, meaningfully gated by prior authentication and knowledge of a victim UUID; monitor but do not prioritize for emergency patching.

An attacker who holds a low-privileged but valid account on a shared Wanwu deployment obtains or guesses the UUID of another tenant's registered MCP server, then calls POST /v1/appspace/app/key with appType=mcpserver and the victim's UUID to mint an AppKey it should not be authorized to create. Using that key, the attacker opens MCP sessions and invokes the victim's tools under the victim's upstream credentials, potentially reading data or performing actions the downstream MCP server is authorized for. No public exploit code is identified, though a technical write-up documents the flaw.