CVE-2026-49228: Vvveb CMS Auth Bypass Vulnerability

CVE-2026-49228 Overview

CVE-2026-49228 is an Insecure Direct Object Reference (IDOR) vulnerability in Vvveb, a content management system with a page builder used for websites, blogs, and ecommerce stores. Versions prior to 1.0.8.4 fail to enforce vendor ownership checks on product operations in the administrative backend. A low-privileged Vendor account can read, duplicate, or delete products belonging to other Vendors. The flaw resides in admin/controller/product/products.php and the SQL layer at admin/sql/sqlite/product.sql, which accept caller-controlled product_id values without consistently scoping queries by admin_id. The issue is tracked as [CWE-639] and fixed in version 1.0.8.4.

Critical Impact
Authenticated low-privileged vendors can access, duplicate, or delete products owned by other vendors, resulting in commercial data exposure, catalog pollution, and business disruption.

Affected Products

Vvveb CMS versions prior to 1.0.8.4
Vvveb backend product management module (admin/controller/product/products.php)
Vvveb SQL definitions for product operations (admin/sql/sqlite/product.sql, admin/sql/mysqli/product.sql)

Discovery Timeline

2026-08-18 - CVE-2026-49228 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-49228

Vulnerability Analysis

The vulnerability is a broken access control flaw in Vvveb's multi-vendor product management workflow. The controller at admin/controller/product/products.php handles duplicate and delete actions using a product_id supplied by the caller. The underlying SQL routines in admin/sql/sqlite/product.sql and admin/sql/mysqli/product.sql load and mutate product records without consistently constraining queries by the authenticated admin_id. When a Vendor lacks the view_other_products or edit_other_products capability, the code should scope operations to records owned by that Vendor. Instead, ownership enforcement was inconsistent, allowing cross-tenant reads, duplicates, and deletions.

Root Cause

The root cause is missing authorization on primary keys. Vvveb accepted a user-controlled product_id and passed it directly into SQL routines that did not always require the current admin_id as a filter. Capability checks for view_other_products and edit_other_products were not applied uniformly across list, read, duplicate, and delete paths, which is characteristic of [CWE-639] Authorization Bypass Through User-Controlled Key.

Attack Vector

An attacker requires a valid low-privileged Vendor account in the admin backend. Using that session, the attacker submits requests targeting product_id values owned by other Vendors. The backend returns product details, creates duplicates, or deletes the referenced products along with related catalog data. Exploitation is remote over the network and requires no user interaction from the victim vendor.

php

// Patch excerpt: admin/controller/product/products.php
$products = new ProductSQL();
$options  = ['product_id' => $product_id] + $this->global;

$editCapability = 'edit_other_products';

if (Admin::hasCapability($editCapability)) {
    unset($options['admin_id']);
} else {
}

$result   = $products->delete($options);

if ($result && isset($result['product'])) {
// Source: https://github.com/givanz/Vvveb/commit/6db5257ce9fec0d570da63a06f54b98e857603cc

The patch adds a hasCapability('edit_other_products') check. When the capability is absent, the caller's admin_id remains in the query options, restricting the delete to products owned by that Vendor. A parallel change in admin/sql/mysqli/product.sql adds an admin_id parameter to the product get procedure so ownership can be enforced at the SQL layer.

Detection Methods for CVE-2026-49228

Indicators of Compromise

Unexpected product duplication or deletion events in the Vvveb admin audit log attributed to Vendor accounts that do not own the target products.
HTTP POST requests to admin/index.php or the product controller referencing product_id values outside the acting Vendor's normal catalog range.
Sudden gaps in another Vendor's product catalog or unauthorized cloned product entries appearing under a different admin_id.

Detection Strategies

Compare product_id parameters submitted by Vendor sessions against the admin_id that owns each product in the database. Flag mismatches when the Vendor lacks view_other_products or edit_other_products.
Alert on high-volume product delete or duplicate operations originating from a single Vendor session within a short window.
Review web server access logs for enumeration patterns against product identifiers in Vvveb admin endpoints.

Monitoring Recommendations

Enable database-level auditing on the Vvveb product table for INSERT, UPDATE, and DELETE statements executed by application accounts.
Retain Vvveb admin activity logs centrally and correlate authenticated user identifiers with modified resource ownership.
Baseline normal per-vendor product operation volume and alert on deviations.

How to Mitigate CVE-2026-49228

Immediate Actions Required

Upgrade Vvveb to version 1.0.8.4 or later, which enforces admin_id scoping and capability checks across product operations.
Audit all Vendor accounts and remove the view_other_products and edit_other_products capabilities unless explicitly required.
Review recent product duplicate and delete events for unauthorized cross-vendor activity and restore any affected catalog data from backups.

Patch Information

The fix is available in Vvveb Release 1.0.8.4. The remediation is implemented in commit 6db5257 and detailed in GitHub Security Advisory GHSA-j5jv-wvpg-gfh9. The patch adds Admin::hasCapability('edit_other_products') checks before removing admin_id from query options and threads admin_id through SQL procedures such as the product get routine.

Workarounds

If patching is not immediately possible, disable or suspend low-privileged Vendor accounts that do not need to manage products.
Restrict access to the Vvveb admin interface using network-level controls such as IP allowlisting or VPN-only access.
Take a full backup of the products database so unauthorized deletions or duplications can be reversed while remediation is pending.

bash

# Verify installed Vvveb version and upgrade
grep -R "VERSION" /var/www/vvveb/system/ | grep -i version
cd /var/www/vvveb
git fetch --tags
git checkout 1.0.8.4