CVE-2026-54613: Vvveb: Path Traversal in Revision Backup Reader/Deleter via Unsanitized theme Parameter
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.5, getThemeFolder() in admin/controller/editor/revisions.php returns the attacker-controlled theme parameter without sanitization, and backupFolder() concatenates it beneath DIRTHEMES before editor/revisions/load or editor/revisions/delete operates on a named .html file. sanitizeBackupFileName() strips traversal characters only from the separate file parameter and does not protect the theme directory component. An authenticated user with the default Editor role and editor/ permission can submit traversal sequences that redirect filegetcontents() or unlink() to a reachable backup subdirectory outside the web root. A valid admin session and CSRF token are required, the read is limited to .html files in backup directories, and deletion additionally requires filesystem write permission. This can disclose sensitive exported site content or remove backup data. This issue is fixed in version 1.0.8.5.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Vvvebto a version that resolves this vulnerability.Fixed in 1.0.8.5 - Configuration
Update the logic so that the theme parameter used by getThemeFolder()/backupFolder() is sanitized as well (current sanitizeBackupFileName() only strips traversal from the separate file parameter and does not protect the theme directory component).
Vvveb editor/revisions.php sanitizeBackupFileName() = ensure theme directory component is sanitized
Event History
Frequently Asked Questions
Which users can exploit this issue?
An authenticated user with the default Editor role and editor/* permission can exploit it. They also need a valid admin session and CSRF token.
What data can be accessed or deleted?
Reads are limited to .html files in reachable backup directories outside the web root, which may expose exported site content. Deletion targets backup data and additionally depends on the application having filesystem write permission.
Are default role permissions affected?
Yes. The default Editor role is affected when it has editor/* permission.
What should be done if an immediate upgrade is not possible?
Restrict editor/* permission to trusted users and review Editor-role access. Limit filesystem write permissions for backup locations to reduce the deletion impact.
How can I determine whether the instance is affected?
Versions prior to 1.0.8.5 are affected. Review revision load and delete activity for authenticated Editor users submitting traversal sequences in the theme parameter.