Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as any enabled user
-
ExploitHarvest victim appId/appType from exploration marketplace
-
ExecutionInvoke DELETE unpublish endpoint for victim app
-
ImpactServer deletes other orgs' api_key rows, cutting off MCP/OpenAPI access
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a valid, enabled, authenticated user account on the Wanwu platform (PR:L) - exploitation is not possible unauthenticated. Given such an account, no non-default configuration is needed: the attacker simply supplies a target appId and appType (obtainable from the exploration marketplace) to the unpublish endpoint (DELETE /v1/appspace/app/publish), and the server deletes api_key rows belonging to other users across organizations without verifying ownership. The primary limiting factors are the need for an enabled account and a multi-tenant deployment where other users'/organizations' apps exist to target; impact is confined to revoking API keys (DoS of MCP/OpenAPI access) rather than reading or exfiltrating data. |
| Impact | This is a genuine but moderate-severity access-control flaw, not a critical priority. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) is internally consistent with the description: network-reachable, low attack complexity, requires a low-privilege authenticated account (PR:L), no user interaction, with limited integrity/availability impact and no confidentiality exposure - matching CWE-862 Missing Authorization. The real-world damage is a cross-tenant denial of service (deleting other users' api_key rows), not data theft or code execution, which caps the severity. No EPSS score, KEV listing, or POC/exploit code was provided in the input; a HackMD technical write-up and the vendor source-code line references exist but do not themselves constitute weaponized exploit code. SSVC-style reasoning: exploitation status is 'none/public-write-up only', technical impact is partial, and while the action is trivially scriptable, the prerequisite of a valid enabled account on a niche open-source platform limits mass exploitation. Net: a real multi-tenant authorization bug worth patching for operators of this platform, but low likelihood of widespread opportunistic exploitation. |
| Exploit ScenarioDerived | An attacker who holds any valid, enabled low-privilege account on a shared Wanwu instance browses the exploration marketplace to obtain another organization's appId and appType, then calls the unpublish endpoint for that app. Because the server never checks ownership, the victim's api_key rows are deleted, immediately severing their MCP and OpenAPI client integrations. No public exploit code was identified at time of analysis, though a detailed technical write-up describing the flaw exists. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
Missing authorization in UnicomAI Wanwu through 0.6.5 lets any authenticated, enabled user revoke other users' AppKeys by submitting a target appId and appType - values obtainable from the exploration marketplace - to the unpublish endpoint, which then deletes api_key rows belonging to other users across organizations and cuts off their MCP and OpenAPI client access. Exploitation requires a valid enabled account on the platform (CVSS PR:L, so authenticated, not unauthenticated) and a multi-tenant deployment where other users' or organizations' apps exist to target; the impact is confined to credential revocation (integrity/availability of API access), not data disclosure. Scored 5.3 under CVSS 4.0 with the independent assessment landing at CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L, this is a genuine but moderate-severity access-control flaw; no public exploit code and no confirmed active exploitation were identified at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis: the supplied references point to affected source code in the v0.6.5 tree and to a VulnCheck advisory, but no fixed version or upstream fix commit is provided, so upgrade instructions cannot be given with confidence and any claim of an available fix would be unverified. The most direct compensating control is to enforce server-side ownership and tenant authorization on DELETE /v1/appspace/app/publish so the target appId is resolved from the authenticated session and the caller's user/organization must match the app's owner before any api_key rows are deleted - the trade-off is that this must be implemented in the application code (or an interposing gateway that rewrites/validates the request), and a naive gateway rule that hard-blocks the endpoint will also break legitimate self-service unpublish for app owners. As an interim containment, restrict the unpublish endpoint at the reverse proxy or API gateway to administrator roles or to internal network ranges, accepting that normal owner-driven unpublish workflows become manual for other users. Deployments that are single-tenant or that restrict accounts to fully trusted users have a substantially reduced blast radius, since the attack requires a multi-tenant environment with other users' apps to target. Additionally, monitor audit logs for delete operations on api_key records and for anomalous bulk key revocations, and issue short-lived, rotatable AppKeys so that a revoked credential can be restored quickly with limited operational disruption to MCP and OpenAPI clients. Per the supplied data, no public exploit code and no confirmed active exploitation exist, so these measures can be scheduled rather than treated as an emergency, though exposed multi-tenant instances should still prioritize the authorization check.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-862 (Missing Authorization) in the Wanwu application platform's server-side handling of the app unpublish flow. Wanwu is a Go-based multi-tenant LLM application platform whose app-service layer manages per-app API credentials; the referenced upstream code at internal/app-service/client/orm/app.go lines 48-68 performs API-key row operations without validating that the calling user owns or belongs to the tenant that owns the targeted app. Because the unpublish endpoint accepts caller-supplied appId and appType parameters rather than deriving the target from the authenticated session, an enabled user can address any app - including those in other organizations - and the ORM delete path removes the corresponding api_key rows. The CPE cpe:2.3:a:unicomai:wanwu:*:*:*:*:*:*:*:* is wildcarded, consistent with all released versions up to and including 0.6.5 being affected. The 4.0 vector shows no confidentiality or scope impact (VC:N/SC:N) with only low integrity and availability impact (VI:L/VA:L), which matches an attack that destroys credential records rather than exposing or modifying application data.
Know when Wanwu gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
Network-reachable endpoint with low complexity, but requires a low-privilege authenticated account (PR:L); unauthorized deletion of others' keys yields limited integrity and availability impact and no confidentiality loss.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Authenticated low-privileged users on UnicomAI Wanwu deployments running versions before 0.6.3 can permanently delete ot
Authenticated, enabled users of UnicomAI Wanwu (also tracked as unicomai/wanwu) before version 0.6.3 can revoke other or
Authorization bypass in UnicomAI Wanwu through 0.6.5 allows any authenticated user to mint an AppKey bound to another us
EUVD-2026-97006
GHSA-fhx6-5hpr-jhgm
NVD
CVE.org
EPSS
Exploit-DB