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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-08-18T17:16:57.687Z",
  "pubdate": "2026-08-18T17:16:57.687Z",
  "executiveSummary": "An access control vulnerability exists in Vvveb prior to version 1.0.8.4 within the backend product question operations. The vulnerability stems from insufficient authorization checks during product question management, allowing a low-privileged Vendor to manipulate questions associated with products belonging to other Vendors. The root cause resides in the admin/sql/sqlite/product_question.sql queries, which accept a caller-controlled product_question_id and fail to validate that the target product_question.product_id corresponds to the product.admin_id of the currently authenticated session.\nSuccessful exploitation of this security flaw enables a malicious or compromised low-privileged Vendor to read pending question content and moderation data, modify question statuses, alter question text, or entirely delete questions across the platform. This leads to severe integrity and confidentiality violations concerning product Q&A visibility and moderation data. The risk implication is significant within multi-vendor environments where strict tenant isolation is required. Exploitation requires authenticated low-privileged access to the backend management interface and the ability to supply arbitrary product_question_id parameters to the vulnerable database operations.",
  "technicalDetails": "The vulnerability is characterized as an Insecure Direct Object Reference (IDOR) leading to Broken Object Level Authorization (BOLA) within the backend administrative modules of Vvveb. The affected component is the product question management subsystem, specifically implemented via SQL queries located in admin/sql/sqlite/product_question.sql. Prior to version 1.0.8.4, the application fails to enforce proper authorization checks verifying ownership of the resource being modified or queried.\nDuring typical operations, when an administrator or vendor attempts to perform actions on product questions—such as reading, updating, or deleting—the backend executes SQL queries relying directly on a caller-controlled product_question_id parameter. The execution flow lacks a relational verification step to ensure that the product_question.product_id associated with the requested identifier maps correctly to the admin_id of the currently authenticated user session. Consequently, the database layer executes the requested queries without validating multi-vendor boundaries.\nThe attack flow proceeds as follows: 1. An attacker authenticates to the Vvveb backend with low-privileged Vendor credentials. 2. The attacker identifies or enumerates valid product_question_id values belonging to other Vendors' products. 3. The attacker crafts HTTP requests targeting the product question management endpoints, supplying the arbitrary product_question_id parameters. 4. The backend application processes the input via the vulnerable SQL queries in admin/sql/sqlite/product_question.sql without checking tenant ownership. 5. The database executes the read, update, or delete operations against cross-tenant records.\nPost-exploitation impact includes the unauthorized exposure of sensitive pre-publication question content and moderation metadata, the subversion of platform integrity through altered or falsified Q&A entries, and the unauthorized deletion of customer-vendor communications. The vulnerability affects Vvveb versions prior to 1.0.8.4, requires low-privileged authentication, and involves internal backend database logic executed via the administrative interface."
}