CVE-2026-108855 in Wanwu
Summary
by MITRE • 10/11/2026
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.
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 failure in server-side access control mechanisms, specifically classified under CWE-284 Improper Access Control. This flaw manifests as an insecure direct object reference or broken function level authorization issue where the application fails to verify that the authenticated user initiating the request is the legitimate owner of the resource being modified. In this specific context, the unpublish endpoint, which is designed to manage application visibility and lifecycle states within the exploration marketplace, lacks sufficient validation checks on the appId parameter provided by the client. Consequently, an attacker who has successfully authenticated with a valid enabled account can manipulate API requests to target arbitrary applications belonging to other users or even different organizational tenants.
The technical mechanism of this exploitation involves sending a crafted HTTP request to the unpublish endpoint while supplying a target appId and appType that do not belong to the requesting user's identity context. The backend logic processes this request without cross-referencing the provided identifier against the authorized resources associated with the session token or API key used for authentication. This oversight allows the system to execute deletion operations on api_key rows across organizational boundaries, effectively stripping other users of their credentials required to interact with the platform. Such a design flaw indicates that the application relies heavily on client-supplied identifiers rather than maintaining server-side state mappings between user identities and their associated resources, a common anti-pattern in RESTful API development when proper middleware or service-layer authorization checks are omitted.
The operational impact of this vulnerability is severe, as it directly compromises the availability and integrity of critical integration points for downstream systems. By revoking AppKeys for arbitrary apps, an attacker can effectively cut off access for Model Context Protocol (MCP) clients and OpenAPI-based services that depend on these credentials to function. This denial of service effect disrupts business continuity for affected organizations, potentially halting automated workflows, data synchronization processes, or AI-driven applications that rely on uninterrupted API connectivity. Furthermore, the ability to delete keys across organizations suggests a potential lateral movement vector where an attacker in one tenant could degrade the operational capacity of another, leading to significant financial and reputational damage due to service outages and loss of trust in the platform's security posture.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1530 Data from Cloud Storage Object or potentially T1498 Network Denial of Service if viewed through the lens of resource exhaustion via credential invalidation, though it is more accurately described as an unauthorized action leading to data loss. The exploitation requires only authenticated access, which lowers the barrier for entry compared to unauthenticated attacks but still poses a significant risk in multi-tenant environments where trust boundaries are critical. Attackers with compromised credentials or insider threats can leverage this flaw to sabotage competitors or disrupt internal operations without needing elevated privileges beyond standard user status.
Mitigation strategies must prioritize immediate remediation of the authorization logic within the unpublish endpoint. Developers should implement strict ownership verification by ensuring that every request modifying a resource checks if the authenticated user's identity matches the owner ID stored in the database for the specified appId and appType. Additionally, implementing role-based access control (RBAC) policies can restrict such destructive actions to administrators only, reducing the attack surface available to standard users. Input validation should also be enforced to ensure that supplied identifiers correspond to existing records before any deletion logic is triggered. Long-term fixes involve adopting a security-first development lifecycle with regular code reviews focused on access control patterns and utilizing automated static analysis tools configured to detect CWE-284 violations in API endpoints.