Vvveb CMS EUVD-2026-114083

Requires a valid authenticated administrator account on a Vvveb instance prior to 1.0.8.7 - including an admin WITHOUT the 'view_other_admin' or 'edit_other_admin' capabilities, which is precisely the point of the bug. The attacker reaches admin/auth-token.php and supplies another administrator's admin_id as a GET parameter: index() reads that admin's token and save() overwrites it, because neither performs the ownership/capability check that the sibling user/user.php controller does. Limiting factors that reduce real-world risk below the raw 9.0: valid admin credentials/session are mandatory (no unauthenticated path), and the privilege-escalation payoff only materializes when the targeted victim admin holds a higher role than the attacker; no special non-default configuration or user interaction is needed.

This is a genuinely high-severity issue (CVSS 9.0) carrying an 'act_now' priority label from vuln.today, but the signals must be read together rather than at face value. The CVSS vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L) and CWE-285 describe a network-reachable, low-complexity broken-authorization flaw whose chief limiter is PR:H - exploitation requires an already-authenticated administrator account, so the realistic attacker is a lower-privileged or malicious insider admin, a compromised admin session, or a second admin in a multi-tenant install, not an anonymous internet attacker. No EPSS score is provided in the input, and there is no CISA KEV listing, so there is no quantitative exploitation-probability signal and no evidence of active exploitation; the 'act_now' label therefore appears driven by the critical CVSS and the vendor-published technical detail rather than by observed in-the-wild activity. A public PoC reference exists in the GHSA advisory (a step-by-step manual walkthrough with screenshots); it is not verified as working exploit code, but it does show the trigger is trivial - changing the admin_id parameter in the URL. Net: a real priority for any Vvveb operator running multiple admin accounts because it yields admin-to-admin privilege escalation, but the PR:H precondition meaningfully narrows the exposed population compared with an unauthenticated 9.0. Missing data to note explicitly: no EPSS, no KEV confirmation, and the PoC is demonstrative steps rather than confirmed weaponized exploit code.

A low-privilege administrator on a Vvveb instance (one lacking the 'view_other_admin'/'edit_other_admin' capabilities) browses to the admin/auth-token page and simply edits the admin_id value in the URL to that of a higher-privileged administrator, revealing and then overwriting that admin's REST API token. The attacker uses the stolen token (Authorization: Bearer) to call the REST API with the victim's full permission level, escalating privileges, while optionally overwriting the victim's token to lock them out of API-driven integrations. A public PoC walkthrough demonstrating these exact steps exists in the vendor advisory, though it is not verified as working exploit code.