Vvveb vulnerabilities

Vvveb before version 1.0.8.2 contains an unrestricted file upload vulnerability in the media upload handler that allows authenticated users with media-upload permissions to bypass extension restrictions by uploading a .htaccess file. This enables attackers to upload .phtml files containing arbitrary PHP code and execute the payload through an unauthenticated HTTP GET request.

Vvveb before version 1.0.8.2 contains an XML external entity (XXE) injection vulnerability in the admin Tools/Import feature that allows authenticated site_admin users to read arbitrary files and modify database records.

Vvveb before version 1.0.8.2 contains an authenticated remote code execution vulnerability in the admin code editor that allows low-privilege authenticated users to execute arbitrary code through insufficient file extension restrictions.

Vvveb before version 1.0.8.2 contains a hard-coded credentials vulnerability in its docker-compose-apache.yaml configuration that allows unauthenticated attackers to access the bundled phpMyAdmin container with pre-configured database credentials.

Vvveb prior to version 1.0.8.1 contains a code injection vulnerability in the installation endpoint where the subdir POST parameter is written unsanitized into the env.php configuration file. Attackers can inject arbitrary PHP code by breaking out of the string context in the define statement, leading to unauthenticated remote code execution as the web server user.

Vvveb prior to version 1.0.8.6 contains an SSRF vulnerability because host validation only handles IPv4, not IPv6. An authenticated admin-panel user can exploit the oEmbed proxy to read internal services and cloud metadata, including IAM credentials.

Vvveb prior to version 1.0.8.6 has a flawed path sanitizer that allows an authenticated user with backup access to read and delete arbitrary files on the server. This can expose database credentials, read system files, and delete config/db.php to enable full site takeover.

Vvveb prior to version 1.0.8.6 has an HTML sanitizer that fails to strip event-handler attributes when a tag contains a greater-than character inside a quoted attribute value. A low-privilege content author can store malicious JavaScript that executes in browsers of visitors and administrators, potentially leading to admin account takeover.

In Vvveb prior to 1.0.8.5, getThemeFolder() returns the attacker-controlled theme parameter without sanitization, and backupFolder() concatenates it beneath DIR_THEMES 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 file_get_contents() or unlink() to a reachable backup subdirectory outside the web root.

In Vvveb CMS from 1.0.0 to 1.0.8.5, saveGlobalElements() concatenates the attacker-controlled file portion of data-v-save-global to the active theme directory, enabling path traversal. An authenticated user with the default Editor role can write arbitrary PHP content outside the theme directory, allowing persistent webshell placement.

In Vvveb prior to 1.0.8.5, the oEmbedProxy() handler accepts an attacker-controlled url parameter and passes it to getUrl(), while validateUrl() only checks the hostname string, not its resolved addresses. An authenticated admin-panel user can trigger requests to private, loopback, link-local, or reserved addresses.

In Vvveb prior to 1.0.8.5, sanitizeHTML() has a flawed on* event-handler regex and a faulty loop condition, so forbidden nested tags are removed only once. A user with Author role or higher can store malicious JavaScript in the bio field that executes for other users.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to access products owned by another Vendor. The product controller does not verify ownership for duplicate and delete actions, enabling reading, duplicating, and deleting products and related data.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to access revisions for products owned by another Vendor. SQL queries do not verify product ownership for revision reads, restores, and deletes.

Vvveb before version 1.0.8.4 allows a low-privileged Author to access revisions for posts owned by another Author. SQL queries do not verify post ownership for revision lists, reads, restores, and deletes.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to manage reviews under another Vendor's products. SQL queries do not verify product ownership for reviews.

Vvveb before version 1.0.8.4 allows a low-privileged Vendor to manage questions under another Vendor's products. SQL queries do not verify product ownership for questions.

Vvveb before version 1.0.8.4 has a vulnerability in backend comment operations that allows a low-privileged Author to manage comments under another Author's posts. Lack of ownership verification enables reading comment content, email addresses, changing moderation status, editing or deleting comments.

Vvveb before version 1.0.8.4 has a vulnerability in backend post operations that allows a low-privileged Author to access posts owned by another Author. Lack of consistent ownership enforcement enables viewing metadata, duplicating or deleting posts, potentially exposing private drafts and causing data loss.

Vvveb before version 1.0.8.4 has a vulnerability in backend digital asset operations that allows a low-privileged Vendor to access digital assets linked to another Vendor's products. Lack of ownership boundary enforcement enables listing assets, reading names and file metadata, editing metadata, or deleting asset records.

Vvveb before version 1.0.8.3 contains an unrestricted file upload vulnerability in the plugin upload endpoint that allows super_admin users to execute arbitrary PHP code by uploading a malicious plugin ZIP file. Attackers can craft a ZIP containing a plugin.php with a valid Slug header and a public/index.php file with arbitrary PHP code, which executes as the web server user once accessed via subsequent unauthenticated HTTP requests to the plugin's public path.

Vvveb before version 1.0.8.3 contains an uncontrolled recursion vulnerability in the admin controller dispatch cycle where Base::init() repeatedly invokes permission() on error handlers, causing infinite recursion until PHP memory limits are exhausted. Attackers can send sustained requests to forbidden admin URLs from a low-privilege account to exhaust PHP memory on all workers and cause denial of service to legitimate traffic.

Vvveb before version 1.0.8.3 contains a directory listing information disclosure vulnerability that allows unauthenticated attackers to enumerate files and directories by accessing multiple paths lacking proper index directives in .htaccess files. Attackers can access directories such as admin asset paths, plugins, themes, and media folders to view filenames, file sizes, modification timestamps, and unrendered admin templates containing sensitive route maps.

Vvveb before version 1.0.8.3 contains a stored cross-site scripting vulnerability in the customer signup flow. The Signup::addUser() controller copies raw POST username values into the display_name field before sanitization, allowing attackers to inject HTML and script markup.

Vvveb before version 1.0.8.2 contains an unauthenticated reflected cross-site scripting vulnerability in the visual editor preview renderer. Attackers can exploit the 'r' query parameter and '_component_ajax' POST parameter to inject and execute arbitrary JavaScript in the context of the Vvveb origin.

Vvveb before version 1.0.8.2 contains an information disclosure vulnerability in the cron controller that allows unauthenticated attackers to retrieve the application's secret cron key. Attackers can access the cron controller without authentication and retrieve the exposed secret key from the response, enabling them to trigger scheduled task execution outside of the intended schedule.

Vvveb prior to version 1.0.8.1 contains a stored cross-site scripting vulnerability that allows authenticated users with media upload and rename permissions to bypass MIME type validation by prepending a GIF89a header to HTML/JavaScript payloads, then renaming the file to .html extension. This enables arbitrary JavaScript execution in an administrator's browser session, potentially leading to backdoor account creation and malicious plugin uploads for remote code execution.

Vvveb prior to version 1.0.8.1 contains a server-side request forgery (SSRF) vulnerability in the oEmbedProxy action of the editor/editor module. The url parameter is passed directly to getUrl() via curl without scheme or destination validation. Authenticated backend users can supply file:// URLs to read arbitrary files readable by the web server process or http:// URLs targeting internal network addresses to probe internal services, with response bodies returned directly to the caller.

Vvveb prior to version 1.0.8.1 contains a privilege escalation vulnerability in the admin user profile save endpoint. Authenticated users can modify privileged fields on their own profile by injecting role_id=1, escalating to Super Administrator privileges and enabling remote code execution via plugin upload.

A path traversal vulnerability was identified in givanz Vvveb up to 1.0.7.3 in the sanitizeFileName function of system/functions.php in the Code Editor component. Manipulation of the File argument allows access to files outside the intended directory. The attack can be launched remotely and the exploit is publicly available.

A vulnerability was determined in givanz Vvveb up to 1.0.7.3. This affects the function Import of the file admin/controller/tools/import.php of the component Raw SQL Handler. This manipulation causes sql injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized.

A weakness has been identified in givanz Vvveb up to 1.0.7.2. This vulnerability affects unknown code. Executing manipulation can lead to cross-site request forgery. The attack can be executed remotely. The exploit has been made available to the public and could be exploited. Once again the project maintainer reacted very professional: "I accept the existence of these vulnerabilities. (...) I fixed the code to remove these vulnerabilities and will push the code to github and make a new release."

A security flaw has been discovered in givanz Vvveb up to 1.0.7.2. This affects an unknown part of the Image Handler component. Manipulation results in information disclosure. Remote exploitation is possible and the exploit has been released publicly.

A vulnerability was identified in Vvveb (up to version 1.0.7.2) in an unknown function of the SVG file handler component. The cross-site scripting (XSS) flaw can be exploited remotely. The exploit is publicly available and might be used.

A vulnerability in givanz Vvveb up to 1.0.7.2 affects an unknown functionality of the Configuration File Handler component. Manipulation leads to information disclosure. The attack can be initiated remotely, and the exploit is publicly available.