Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-11T14:17:05.100Z",
  "pubdate": "2026-10-11T14:17:05.100Z",
  "executiveSummary": "Wanwu versions prior to 0.6.3 contain an Insecure Direct Object Reference (IDOR) vulnerability within the API management interface. This security flaw enables any authenticated, enabled user to unauthorizedly delete AppKeys belonging to other users or organizations. By manipulating a numeric apiId parameter, an attacker can systematically revoke API credentials. The vulnerability poses a significant risk to service availability, as the unauthorized deletion of these keys results in immediate disruption of MCP (Model Context Protocol) and OpenAPI client connectivity. The exploit is trivial to execute, requiring only a valid user session and the ability to iterate through sequential API identifiers. This vulnerability fundamentally breaks the access control model intended to isolate resource management between distinct users and organizational tenants, allowing for widespread service degradation.",
  "technicalDetails": "The vulnerability resides in the API endpoint 'DELETE /v1/appspace/app/key', which handles the lifecycle management of legacy AppKeys. The root cause is a failure in server-side authorization logic, specifically the absence of an ownership check between the authenticated user session and the requested 'apiId'.\nThe application processes the deletion request by accepting a numeric 'apiId' parameter provided in the request body or path. Because the system fails to validate whether the requester possesses sufficient permissions or ownership over the specified 'apiId', the backend service proceeds to remove the credential from the database upon receipt of the DELETE request.\nThe attack flow follows a predictable pattern: An attacker with valid, authenticated access to the Wanwu platform identifies the target API endpoint. Given the sequential nature of the 'apiId' values, an attacker can employ a script to iterate through numeric IDs. By sending crafted HTTP DELETE requests to '/v1/appspace/app/key' with incrementing 'apiId' values, the attacker can successfully delete keys across the entire platform, including those belonging to other organizations. No administrative privileges are required, only standard user-level authentication.\nThis vulnerability effectively bypasses multi-tenant isolation, as the backend does not enforce scope verification during the deletion routine. The consequence of successful exploitation is a complete denial of service for any external system relying on the deleted AppKeys. Affected OpenAPI clients and MCP integrations lose their ability to authenticate, leading to persistent service outages until the legitimate owner identifies the deletion and generates a new key. The lack of rate limiting or proper authorization checks on this specific API method allows an attacker to clear a large number of credentials in a short temporal window, significantly amplifying the operational impact."
}