CVE-2026-49225: Vvveb CMS Privilege Escalation Vulnerability

CVE-2026-49225 Overview

CVE-2026-49225 is an Insecure Direct Object Reference [CWE-639] vulnerability in Vvveb, an open-source content management system (CMS) with a page builder for websites, blogs, and ecommerce stores. Versions prior to 1.0.8.4 allow a low-privileged Vendor account to access product revision records owned by other Vendors. 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.

Critical Impact
An authenticated Vendor can read, restore, or delete revisions of products owned by other Vendors, exposing private content, corrupting live product pages, and destroying audit history.

Affected Products

Vvveb CMS versions prior to 1.0.8.4
Vvveb backend product revision controller (admin/controller/product/revisions.php)
Vvveb SQL revision handlers for SQLite, MySQL, and PostgreSQL backends

Discovery Timeline

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

Technical Details for CVE-2026-49225

Vulnerability Analysis

The flaw is a broken authorization issue in Vvveb's multi-vendor product revision workflow. The product revision controller reuses the generic content revision controller, which was never scoped to enforce per-Vendor ownership on product data. Downstream SQL routines accept product_id, language_id, and created_at values directly from the caller and use them to select, restore, or delete revision rows.

Because the SQL routines never filter by the authenticated admin_id, any Vendor session can supply another Vendor's product_id to access rows that should be out of scope. Reading a revision returns historic product copy, pricing text, and descriptions belonging to a competitor. Restoring a revision overwrites live product content on the victim's page, and deleting revisions erases audit history that would otherwise support recovery or forensic review.

Root Cause

The root cause is missing owner-scope enforcement in revision queries. The revision SQL definitions omit an admin parameter, so the server has no way to bind revision reads and writes to the current Vendor's identity. The patched routines add an IN admin INT parameter and an edit_other_product capability check, ensuring only administrators with elevated permission can operate on revisions across Vendors.

Attack Vector

An attacker requires a low-privileged Vendor account in the Vvveb admin panel and network access to the backend. The attacker calls the product revisions endpoint with a product_id belonging to another Vendor to enumerate revisions, restore an arbitrary historical revision, or delete revision records. No user interaction is required beyond the attacker's own authenticated session.

text

 IN language_id INT,
 IN created_at INT,
 IN content INT,
+IN admin INT,
 IN start INT,
 IN limit INT,
 OUT fetch_all,

Source: GitHub commit e7413a2 - the patch adds an admin parameter to admin/sql/mysqli/product_content_revision.sql and admin/sql/pgsql/product_content_revision.sql, enabling the edit_other_product capability check on revision list, restore, and delete operations.

Detection Methods for CVE-2026-49225

Indicators of Compromise

Requests to admin/controller/product/revisions.php where the referenced product_id is not owned by the authenticated Vendor's admin_id.
Unexpected revision restore or delete actions in Vvveb audit logs performed by non-owning Vendor accounts.
Vendor product content changing without corresponding edits by the owning Vendor.

Detection Strategies

Correlate web server access logs with the Vvveb admin database to flag revision endpoint calls where the session admin_id does not match the product owner.
Alert on high-frequency enumeration of sequential product_id values against the revisions route.
Monitor for revision delete operations, which are rare in normal Vendor workflows and should be treated as high-signal events.

Monitoring Recommendations

Enable verbose logging on admin/controller/product/revisions.php and forward events to a central log store for retention and correlation.
Baseline normal per-Vendor revision activity and alert on deviations, particularly restores of revisions older than the Vendor's tenancy.
Snapshot product content tables regularly so unauthorized restores can be identified and reversed.

How to Mitigate CVE-2026-49225

Immediate Actions Required

Upgrade Vvveb to version 1.0.8.4 or later, which enforces the edit_other_product capability on revision operations.
Audit recent revision list, restore, and delete activity to identify cross-Vendor access before the patch was applied.
Rotate credentials and review permissions for all Vendor accounts on multi-tenant Vvveb installations.

Patch Information

The fix is available in Vvveb 1.0.8.4. The corrective changes are described in GHSA-gmrp-ccwf-xggq and implemented in commit e7413a2, which adds an admin parameter and edit_other_product capability check to product revision SQL routines across the MySQL, PostgreSQL, and SQLite backends.

Workarounds

Restrict access to the Vvveb admin panel to trusted network ranges until the upgrade to 1.0.8.4 is complete.
Temporarily disable multi-Vendor tenancy or reduce Vendor accounts to a single trusted operator where feasible.
Apply a reverse-proxy rule that blocks direct calls to the product revisions route for non-administrator sessions.

bash

# Upgrade Vvveb to the patched release
cd /path/to/vvveb
git fetch --tags
git checkout 1.0.8.4
# Verify the patched SQL routine includes the admin parameter
grep -n "IN admin INT" admin/sql/mysqli/product_content_revision.sql