Description

UnicomAI Wanwu through 0.6.5 contains a missing authorization vulnerability that allows any authenticated enabled user to revoke other users' AppKeys for arbitrary apps via the unpublish endpoint. Attackers can supply a target appId and appType from the exploration marketplace to delete other users' api_key rows across organizations, cutting off MCP and OpenAPI client access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-11T14:17:05.233Z",
  "pubdate": "2026-10-11T14:17:05.233Z",
  "executiveSummary": "UnicomAI Wanwu versions through 0.6.5 are affected by a critical missing authorization vulnerability. This security flaw resides within the unpublish endpoint, which fails to perform adequate access control checks to verify if the requesting user possesses the necessary permissions to manage the specified application resources.\nThe vulnerability allows any authenticated user within the system to revoke the AppKeys of arbitrary applications owned by other users or organizations. By manipulating the appId and appType parameters during a request to the unpublish endpoint, an attacker can trigger a database deletion operation that removes api_key rows associated with targeted applications.\nThe risk implications are significant, as this capability facilitates unauthorized disruption of service by severing MCP and OpenAPI client connectivity for third-party systems. Exploitation is trivial, requiring only a valid user account and knowledge of the target application identifiers obtainable from the exploration marketplace. The impact includes widespread service interruption, loss of API access, and potential operational paralysis for organizations relying on the affected integrations.",
  "technicalDetails": "The root cause of this vulnerability is an Insecure Direct Object Reference (IDOR) pattern coupled with a failure in the server-side authorization logic within the unpublish endpoint. The application fails to validate the ownership or administrative rights of the authenticated session against the requested resource during the execution of the unpublish workflow.\nThe vulnerable component is the unpublish API endpoint, which is designed to handle the decommissioning of applications. In the affected versions (through 0.6.5), the endpoint processes requests to delete persistent API credentials without verifying that the requester is the authorized owner of the target appId. Consequently, the backend logic proceeds to execute a destructive database query that removes the api_key record from the underlying storage, effectively revoking access for legitimate users.\nThe exploitation flow is straightforward and does not require elevated administrative privileges. An attacker performs the following steps: 1. Identification: The attacker browses the exploration marketplace to identify the target appId and associated appType of a specific application owned by another user or entity. 2. Request Crafting: The attacker constructs an HTTP request targeting the unpublish endpoint, injecting the harvested appId and appType into the request parameters. 3. Unauthorized Execution: Upon receiving the request, the server performs a lookup for the api_key record linked to the provided identifiers and performs a DELETE operation against the database.\nThis vulnerability is particularly impactful due to its cross-organization reach. Because the authorization check is absent, the attacker is not constrained to their own organization's scope. The payload behavior is limited to the destruction of access credentials, which results in an immediate denial of service (DoS) for all clients leveraging the affected MCP or OpenAPI configurations. There is no requirement for interaction with the target user, and the lack of authorization controls ensures that the action is performed synchronously and successfully if the identifiers are valid. The vulnerability effectively turns a management feature into a weaponized tool for resource destruction."
}