Vvveb CMS versions 1.0.8.6 and earlier contain a path traversal vulnerability in the backup controller's nextRestore() and nextBackup() functions. These functions accept a file parameter that is concatenated to the backup directory path without proper sanitization, allowing an authenticated administrator to read arbitrary files or write SQL dump content to arbitrary locations. This flaw contrasts with other related functions that correctly sanitize file names. The issue has been patched in a subsequent commit.
Vvveb CMS versions prior to 1.0.8.6 contain a Server-Side Request Forgery (SSRF) vulnerability. The SSRF guard only resolves IPv4 addresses and does not inspect IPv6 addresses, allowing authenticated admin users to bypass private-range checks using IPv6 literals or domains with only AAAA records. This enables reading of internal-only services and cloud metadata, including IAM credentials. The issue is patched in version 1.0.8.6.
Vvveb CMS versions prior to 1.0.8.6 contain a cross-site scripting (XSS) vulnerability due to improper sanitization of HTML input. Specifically, the HTML sanitizer fails to remove event-handler attributes when a tag includes a greater-than character inside a quoted attribute value. This allows low-privilege users (authors or contributors) to inject JavaScript payloads into post or product content. When other users, including administrators, view or preview this content, the malicious script executes, potentially leading to admin account takeover. The vulnerability has been fixed in version 1.0.8.6.
CVE-2026-55231 is a path traversal vulnerability in givanz Vvveb CMS versions prior to 1.0.8.6. An authenticated admin-panel user with backup access (site_admin role or higher) can exploit a flawed path sanitizer to read and delete arbitrary files on the server. This allows exposure of sensitive files such as database credentials and system files, and deletion of critical configuration files to force a site reinstall and potential takeover. The vulnerability is patched in version 1.0.8.6.
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, app/controller/user/profile.php accepts the user[bio] field and passes stored content through sanitizeHTML() in system/functions.php, whose on* event-handler regular expression omits the forward-slash delimiter and whose do-while condition compares the string to itself, so forbidden nested tags are removed only once. An Author-role or higher user can submit solidus-prefixed event-handler markup or nested forbidden tags that survive sanitization. The stored bio is rendered without sufficient output encoding on /author/{username}, in the admin user-management view, and potentially in comment displays, causing attacker-controlled JavaScript to execute when unauthenticated visitors, administrators, or other users view the content. This can expose browser-session data and permit victim-context account actions, defacement, or phishing. This issue is fixed in version 1.0.8.5.
CVE-2026-54612 is a path traversal vulnerability in givanz Vvveb CMS versions from 1.0.0 up to but not including 1.0.8.5. An authenticated user with Editor role permissions can exploit this flaw to write arbitrary PHP files outside the intended theme directory. This can lead to persistent webshell placement and full compromise of the application’s confidentiality, integrity, and availability. The vulnerability is fixed in version 1.0.8.5.
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 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. 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.
A Server-Side Request Forgery (SSRF) vulnerability exists in givanz Vvveb prior to version 1.0.8.5. An authenticated admin user with editor permissions can exploit the oEmbedProxy() handler by supplying a crafted URL parameter that bypasses hostname validation and causes the server to make HTTP/HTTPS requests to internal or reserved IP addresses. This can lead to disclosure of internal service responses or cloud instance metadata and credentials. The vulnerability is fixed in version 1.0.8.5.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend product review operations allow a low-privileged Vendor to manage reviews under another Vendor's products. The admin/sql/sqlite/product_review.sql queries accept a caller-controlled product_review_id and do not verify product_review.product_id against product.admin_id for the current admin_id. An attacker can read pending review content, ratings, author information, and moderation state, change review status, edit review content, or delete reviews, manipulating product review visibility and integrity. This issue is fixed in version 1.0.8.4.
Vvveb CMS versions prior to 1.0.8.4 contain an authorization bypass vulnerability in the backend post revision operations. Low-privileged Authors can access, restore, or delete post revisions belonging to other Authors due to improper validation of user-controlled parameters without enforcing the current admin_id. This can lead to exposure of draft content, unauthorized content modification, and loss of audit history. The issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend product question operations allow a low-privileged Vendor to manage questions under another Vendor's products. The admin/sql/sqlite/product_question.sql queries accept a caller-controlled product_question_id and do not verify product_question.product_id against product.admin_id for the current admin_id. An attacker can read pending question content and moderation data, change question status, edit question content, or delete questions, manipulating product Q&A visibility and integrity. This issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend product revision operations allow a low-privileged Vendor to access revisions for products owned by another Vendor. The admin/controller/product/revisions.php route reuses admin/controller/content/revisions.php, while admin/sql/sqlite/product_content_revision.sql trusts caller-controlled product_id, language_id, and created_at values without applying the current admin_id to revision reads, restores, and deletes. An attacker can read historic product content, restore a revision over another Vendor's live product content, or delete revision records, exposing private copy, corrupting product pages, and removing audit history. This issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend product operations allow a low-privileged Vendor to access products owned by another Vendor. The admin/controller/product/products.php controller accepts a caller-controlled product_id for duplicate and delete actions, and admin/sql/sqlite/product.sql loads and mutates products without consistently applying the current admin_id when view_other_products or edit_other_products is absent. An attacker can read product details, duplicate products, or delete products and related catalog data, exposing commercial information and causing unauthorized copies, catalog pollution, data loss, or business disruption. This issue is fixed in version 1.0.8.4.
Vvveb CMS versions prior to 1.0.8.4 contain an authorization bypass vulnerability allowing low-privileged Authors to access, duplicate, or delete posts owned by other Authors. This occurs because the backend post operations permit user-controlled filters that override admin restrictions and inconsistent enforcement of ownership in the database. Exploitation can expose private drafts and cause content loss or disruption. The issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend comment operations allow a low-privileged Author to manage comments under another Author's posts. The admin/controller/content/comment.php and admin/controller/content/comments.php controllers and the admin/sql/sqlite/comment.sql queries accept a caller-controlled comment_id without verifying comment.post_id against post.admin_id for the current admin_id. An attacker can read pending comment content and commenter email addresses, change moderation status, edit comment content, or delete comments, breaking author and moderation boundaries. This issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend digital asset operations allow a low-privileged Vendor to access digital assets linked to another Vendor's products. The admin/controller/product/digital-asset.php and admin/controller/product/digital-assets.php controllers and the admin/sql/sqlite/digital_asset.sql data queries use a caller-controlled digital_asset_id without consistently enforcing the current admin_id ownership boundary. An attacker can list assets, read asset names and file metadata, edit asset metadata, or delete asset records, which can disclose private product metadata, corrupt resource links, and cause data loss. This issue is fixed in version 1.0.8.4.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, the checkout endpoint accepts a user-controlled cart_id and uses it to enter the payment flow without verifying cart ownership. A logged-in attacker can therefore reuse another user's cart data in their own checkout session. This vulnerability is fixed in 1.0.8.3.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, the backend admin/auth-token endpoint allows an authenticated administrator to load another administrator's REST API token list by supplying that user's admin_id. This can disclose sensitive API tokens belonging to other administrators. This vulnerability is fixed in 1.0.8.3.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, there is an authenticated SQL injection issue in the frontend user order history page in Vvveb CMS. A normal frontend user can log in and access /user/orders. The order_by and direction request parameters are accepted from the URL, propagated through the Orders component, and directly concatenated into the SQL ORDER BY clause in OrderSQL::getAll(). Because of this, attacker-controlled input reaches SQL structure without a whitelist or safe query construction step. This vulnerability is fixed in 1.0.8.3.
Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, there is an unauthenticated reflected cross-site scripting (XSS) issue in the public product return form in Vvveb CMS. The customer_order_id POST parameter is inserted into the Order %s not found! error message when the order lookup fails, and that message is rendered in the frontend template without HTML escaping. As a result, attacker-controlled HTML/JavaScript executes in the submitting user's browser. This vulnerability is fixed in 1.0.8.3.