Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-18T16:17:13.357Z",
  "pubdate": "2026-08-18T16:17:13.357Z",
  "executiveSummary": "An Insecure Direct Object Reference vulnerability exists in Vvveb prior to version 1.0.8.4 within the backend digital asset operations. The flaw enables a low-privileged Vendor to access, manipulate, and delete digital assets associated with other Vendors' products. The root cause stems from the lack of consistent ownership boundary enforcement on caller-controlled identifiers across specific controllers and data queries. Successful exploitation allows unauthorized users to disclose private product metadata, corrupt critical resource links, and induce permanent data loss. Attackers require low-privileged vendor access to execute the exploitation vector. The vulnerability is fully resolved in version 1.0.8.4 through proper authorization checks and boundary enforcement.",
  "technicalDetails": "The vulnerability resides in the backend digital asset management functionality of Vvveb prior to version 1.0.8.4. Specifically, the vulnerable components include the admin/controller/product/digital-asset.php and admin/controller/product/digital-assets.php controllers, alongside the data queries defined in admin/sql/sqlite/digital_asset.sql. The root cause of the vulnerability is an Insecure Direct Object Reference (IDOR) resulting from the lack of consistent validation regarding resource ownership. When interacting with digital assets, the application processes a caller-controlled digital_asset_id parameter without verifying whether the currently authenticated admin_id holds valid authorization or ownership rights over the requested asset.\nExploitation requires a low-privileged authenticated session as a Vendor. The attack flow proceeds as follows: an authenticated adversarial Vendor intercepts or crafts HTTP requests directed at the backend digital asset controllers. By manipulating the digital_asset_id parameter within the request payload, the attacker bypasses logical segmentation boundaries designed to isolate vendor data. Because the underlying SQL queries in admin/sql/sqlite/digital_asset.sql fail to constrain operations using the session-derived admin_id, the database executes the operations globally or against arbitrary identifiers supplied by the caller.\nThis architectural oversight permits an attacker to perform unauthorized operations, including listing assets, reading sensitive asset names and associated file metadata, editing asset metadata, and executing delete operations against asset records belonging to other vendors. Post-exploitation impact encompasses the exposure of proprietary product metadata, the corruption of resource links leading to broken functionalities, and significant data loss within the affected Vvveb instance. The vulnerability affects network-exposed administrative interfaces requiring active authentication with low-level privileges."
}