Vvveb CMS EUVD-2026-108691

Requires a valid authenticated administrator session (PR:H) because the nextRestore and nextBackup actions live in the admin backup controller (admin/index.php?module=tools/backup). No non-default configuration is needed - the flaw is present in default installations of Vvveb 1.0.8.6 and prior, since these two functions never call sanitizeFileName() on the file GET parameter. Exploitation is limited by that administrator-authentication requirement; the sibling functions restore(), delete(), and download() are not affected because they do sanitize input. The write primitive (nextBackup) is further constrained to paths where the web server process has write permission and appends a fixed '.sql' suffix to the attacker-chosen path.

This is a genuine but access-gated issue, not a drive-by threat. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N, base 8.7) is driven high by the scope change and dual high confidentiality/integrity impact, but PR:H is the decisive limiter: exploitation requires an already-authenticated administrator. The vuln.today decision label is 'this_week' (prioritize, but not act_now/emergency). No CISA KEV listing is present in the input and no EPSS probability was supplied, so widespread automated exploitation cannot be asserted - both signals are simply absent rather than low. The vendor GHSA advisory includes PoC curl commands, confirming the mechanism (unsanitized file GET parameter concatenated to DIR_BACKUP), though the demonstrated output shows stat/fopen 'No such file or directory' warnings rather than a successful file read. Net: a real post-authentication path-traversal flaw in a niche CMS; priority is moderate and bounded by the admin-privilege prerequisite, consistent with the 'this_week' label rather than emergency patching.

An authenticated Vvveb administrator (or an attacker who has hijacked an admin session) sends a crafted GET request to the backup controller's nextRestore or nextBackup action with a file parameter containing '../' sequences. Via nextRestore they cause the server to open and SQL-process arbitrary server-readable files; via nextBackup they append SQL dump content (potentially user credentials and session data) to arbitrary writable paths with a .sql suffix. A public PoC reference exists in the vendor advisory; it is not verified as a fully working read primitive, since the demonstration output shows file-not-found warnings.