CVE-2026-108854 in Wanwu
Summary
by MITRE • 10/11/2026
Wanwu before 0.6.3 contains an insecure direct object reference vulnerability that allows any authenticated enabled user to delete other users' legacy AppKeys by supplying a numeric apiId. Attackers can iterate sequential key IDs against DELETE /v1/appspace/app/key to revoke AppKeys across organizations, breaking MCP and OpenAPI clients until owners issue new keys.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Wanwu versions prior to 0.6.3 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or IDOR within the OWASP Top Ten framework. This flaw stems from the application's reliance on sequential numeric identifiers for API keys without implementing adequate authorization checks to verify that the requesting user owns the specific resource being targeted. By accepting a simple integer parameter representing the apiId in the DELETE /v1/appspace/app/key endpoint, the system fails to validate whether this identifier corresponds to an AppKey belonging to the authenticated user making the request. This architectural oversight allows any enabled and authenticated user to bypass intended isolation boundaries between different organizational tenants or individual accounts within the platform.
The operational impact of this vulnerability is severe due to its potential for automated exploitation through ID enumeration. Attackers can systematically iterate through sequential key IDs, attempting to delete AppKeys associated with other users across various organizations. This capability effectively enables a denial-of-service condition against legitimate clients that rely on these credentials for authentication and authorization. Specifically, the destruction of legacy AppKeys disrupts connectivity for Model Context Protocol MCP clients and OpenAPI-based integrations, which depend on valid API keys to establish sessions and execute requests. The consequence is not merely data loss but a complete interruption of service until the affected owners generate new credentials, causing significant downtime and operational friction.
From a technical perspective, this flaw aligns with CWE-639, which describes vulnerabilities related to authorization bypasses via direct object references. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, as it requires initial authentication but then exploits the lack of proper resource-level permissions to perform unauthorized actions. The simplicity of the attack vector means that even low-skilled adversaries can execute this abuse using standard HTTP clients or automated scripts without needing complex exploit development skills. The sequential nature of the apiId further exacerbates the risk by making enumeration predictable and efficient, allowing attackers to sweep through large numbers of potential targets rapidly.
Mitigation strategies must focus on implementing robust authorization checks at the application logic layer rather than relying solely on input validation. Developers should ensure that every request involving a resource identifier includes a verification step confirming that the authenticated user has explicit ownership or administrative rights over that specific AppKey before processing the deletion. Additionally, replacing sequential numeric IDs with non-sequential, cryptographically random identifiers such as UUIDs can significantly increase the difficulty of enumeration attacks by removing predictability from the address space. Implementing rate limiting on the DELETE endpoint and monitoring for anomalous patterns of key deletions across multiple accounts can also provide defensive layers against automated abuse attempts until a permanent patch is deployed in version 0.6.3 or later.