CVE-2026-112904 in Vvveb
Summary
by MITRE • 10/23/2026
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. In versions 1.0.8.6 and prior, the nextRestore() and nextBackup() functions in the backup controller accept a file GET parameter and concatenate it directly to DIR_BACKUP without calling sanitizeFileName(). This allows an authenticated administrator to read arbitrary files on the server (via nextRestore) and write SQL dump content to arbitrary locations (via nextBackup). This is inconsistent with the sibling functions restore(), delete(), and download() which all correctly call sanitizeFileName() first. This issue has been patched via commit aa29cb0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
Vvveb CMS, a widely utilized platform for constructing websites, blogs, and e-commerce stores through its integrated page builder functionality, contains critical security vulnerabilities in versions 1.0.8.6 and earlier that compromise the integrity of server-side file operations. The core issue resides within the backup controller module, specifically affecting the nextRestore() and nextBackup() functions which handle data restoration and backup creation processes respectively. These endpoints accept a filename parameter via HTTP GET requests but fail to implement adequate input validation or sanitization before processing user-supplied values. This architectural flaw creates a significant attack surface for authenticated administrators who possess valid credentials within the system, allowing them to manipulate file paths in ways that bypass intended security boundaries and interact with arbitrary locations on the underlying operating system.
The technical mechanism of this vulnerability relies on path traversal techniques enabled by improper string concatenation. In both affected functions, the user-controlled filename parameter is directly concatenated with a predefined directory constant, DIR_BACKUP, without invoking the sanitizeFileName() function that is correctly implemented in sibling methods such as restore(), delete(), and download(). This inconsistency indicates an oversight during development where security controls were not uniformly applied across all similar operations. By supplying maliciously crafted input containing relative path sequences like dot-dot-slash or absolute paths depending on server configuration, an attacker can redirect file read or write operations outside the intended backup directory. For instance, using nextRestore() allows reading arbitrary files from the server filesystem by navigating up directories to access sensitive configuration files, source code, or other confidential data stored in accessible locations.
The operational impact of this vulnerability is severe due to its potential for both information disclosure and remote code execution facilitation through file write capabilities. The ability to read arbitrary files via nextRestore() enables an authenticated attacker to extract database credentials, API keys, session secrets, and application source code that may contain further vulnerabilities or sensitive business logic. This aligns with the Common Weakness Enumeration category CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as the system fails to restrict file access to the designated safe directory. Furthermore, the nextBackup() function’s capability to write SQL dump content to arbitrary locations presents an even greater risk. An attacker can craft specific payloads to overwrite critical application files or place malicious scripts in web-accessible directories if path traversal allows escaping the backup folder entirely. This corresponds closely with CWE-436: Interpretation Error, where user input is incorrectly interpreted as a file path rather than a simple filename string.
From an offensive security perspective, this vulnerability maps directly to MITRE ATT&CK techniques involving File and Directory Discovery for reconnaissance via nextRestore(), and potentially Command and Control or Execution if the write capability allows placing web shells in accessible directories. The lack of consistent sanitization across similar functions suggests that other endpoints might share these weaknesses, requiring a comprehensive audit rather than isolated fixes. Organizations running affected versions must prioritize immediate remediation to prevent unauthorized access to sensitive server resources and potential compromise of the entire hosting environment through file manipulation attacks.
Mitigation strategies focus on applying the patch released in commit aa29cb0 which addresses this inconsistency by ensuring that sanitizeFileName() is called for all backup-related operations, including nextRestore() and nextBackup(). This function typically strips null bytes, removes path traversal sequences like dot-dot-slash, and validates that the resulting filename contains only alphanumeric characters and safe punctuation. Administrators should verify their Vvveb CMS installation version and upgrade to a patched release immediately if they are running 1.0.8.6 or any earlier version. Additionally, implementing defense-in-depth measures such as restricting file write permissions for web server processes, employing Web Application Firewalls with path traversal detection rules, and conducting regular code reviews to ensure consistent security control application across all similar functions can further reduce the risk of exploitation in case future vulnerabilities arise from similar coding patterns.