CVE-2026-49222: Vvveb CMS Privilege Escalation Vulnerability

CVE-2026-49222 Overview

CVE-2026-49222 is an Insecure Direct Object Reference (IDOR) vulnerability in Vvveb, a PHP-based content management system with page builder capabilities for websites, blogs, and ecommerce stores. Versions prior to 1.0.8.4 fail to verify that a product question belongs to the vendor performing the action. A low-privileged Vendor account can read, edit, or delete product questions owned by other vendors. The flaw is tracked as CWE-639: Authorization Bypass Through User-Controlled Key and is fixed in version 1.0.8.4.

Critical Impact
Authenticated low-privileged vendors can manipulate product Q&A visibility and integrity across the multi-tenant Vvveb backend, compromising moderation controls and vendor content isolation.

Affected Products

Vvveb CMS versions prior to 1.0.8.4
Vvveb backend product question module (admin/sql/sqlite/product_question.sql, admin/sql/mysqli/product_question.sql, admin/sql/pgsql/product_question.sql)
Multi-vendor deployments of Vvveb ecommerce sites

Discovery Timeline

2026-08-18 - CVE-2026-49222 published to NVD
2026-08-18 - Last updated in NVD database
Fixed release - Vvveb 1.0.8.4 published on GitHub
Advisory - GHSA-cjhq-xqq3-6xv8 issued by the Vvveb project

Technical Details for CVE-2026-49222

Vulnerability Analysis

The vulnerability resides in Vvveb backend product question operations. Stored procedures in admin/sql/sqlite/product_question.sql, along with the MySQL and PostgreSQL equivalents, accept a caller-controlled product_question_id parameter. The procedures do not cross-check product_question.product_id against product.admin_id for the current session's admin_id. As a result, a Vendor authenticated to the backend can act on question records owned by another Vendor. Impacted operations include reading pending question content, viewing moderation metadata, changing question status, editing question text, and deleting questions outright.

Root Cause

The root cause is a missing tenant-ownership check between the question record and the requesting administrator. The SQL procedures trusted the incoming identifier without joining through product.admin_id. This is a classic IDOR pattern [CWE-639] in which authorization is enforced by knowledge of an identifier rather than by a server-side ownership verification.

Attack Vector

Exploitation requires an authenticated Vendor account on the Vvveb admin interface and network access to the backend. The attacker enumerates or guesses product_question_id values and submits standard backend requests to list, retrieve, update, or delete question records belonging to other vendors. No user interaction is required, attack complexity is low, and the impact concentrates on integrity of Q&A content and moderation state.

text

// Security patch excerpt - admin/sql/mysqli/product_question.sql
CREATE PROCEDURE getAll(
    -- variables
-   IN  language_id INT,
-   IN  site_id INT,
-   IN  product_id INT,
-   IN  user_id INT,
-   IN  status INT,
+   IN language_id INT,
+   IN site_id INT,
+   IN product_id INT,
+   IN slug CHAR,
+   IN user_id INT,
+   IN admin_id INT,
+   IN status INT,

    -- pagination
    IN start INT,

Source: Vvveb commit 1f2b117. The patch adds an admin_id parameter so the procedure can scope results to the vendor's own products and enforces an edit_other_product capability check for cross-vendor operations. The equivalent fix is applied to the PostgreSQL procedure in admin/sql/pgsql/product_question.sql.

Detection Methods for CVE-2026-49222

Indicators of Compromise

Backend admin requests to product-question endpoints referencing product_question_id values that do not map to products owned by the requesting admin_id.
Unexpected changes to product_question.status, question text, or deletions performed by non-owner vendor accounts.
Spikes of sequential product_question_id access from a single authenticated vendor session, indicating enumeration.

Detection Strategies

Correlate application logs by joining question access events with product.admin_id and flag mismatches against the acting session identity.
Deploy database audit rules on the product_question table to record UPDATE and DELETE statements originating from backend procedures without a matching ownership predicate.
Add web application firewall or reverse-proxy rules to log all /admin/ product-question routes with the authenticated user, product identifier, and question identifier for offline analysis.

Monitoring Recommendations

Alert on any vendor account modifying more than a low threshold of question records within a short window.
Track lateral IDOR patterns by monitoring authenticated backend sessions accessing resources across multiple admin_id owners.
Retain webserver and application logs for at least 90 days to support retroactive review after upgrade.

How to Mitigate CVE-2026-49222

Immediate Actions Required

Upgrade Vvveb to version 1.0.8.4 or later on all production and staging environments.
Audit product_question records for unauthorized status changes, edits, or deletions performed before the upgrade.
Rotate credentials for any Vendor accounts that show anomalous cross-tenant activity in the review.

Patch Information

The fix is available in Vvveb 1.0.8.4. The remediation commit 1f2b117 introduces an admin_id parameter into the product-question stored procedures across SQLite, MySQL, and PostgreSQL backends. It also adds an edit_other_product capability check so that only privileged administrators can act on questions belonging to other vendors. Refer to the GHSA-cjhq-xqq3-6xv8 advisory for full details.

Workarounds

Restrict backend access to trusted networks or VPN until the upgrade is applied.
Temporarily disable Vendor role accounts that do not require product-question management.
Place a reverse proxy rule in front of /admin/ product-question routes to block requests where the referenced product_question_id does not resolve to a product owned by the session's vendor.

bash

# Upgrade Vvveb to the fixed release
git fetch --tags
git checkout 1.0.8.4
# Apply database schema updates that add the admin_id parameter
php install/upgrade.php
# Verify running version
grep -R "VERSION" system/core/ | head