Vvveb CMS CVE-2026-49228

Exploitation requires an active authenticated session with at minimum Vendor-level privileges in the Vvveb backend - unauthenticated access is not possible. The vulnerability is specifically present in multi-vendor deployments where more than one Vendor account exists, because the authorization failure is cross-tenant (Vendor A operating on Vendor B's products). The attacker must know or enumerate a valid product_id belonging to another Vendor. Exploitation is limited by the authentication barrier (PR:L per CVSS), meaning external unauthenticated attackers cannot exploit this directly. The edit_other_products and view_other_products capabilities, when explicitly granted to a Vendor, legitimize cross-vendor access and do not represent exploitation - the vulnerability is the absence of enforcement when those capabilities are NOT granted.

The CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately captures the technical severity: remote exploitation requires only a Vendor-level session, involves no complexity, and delivers full read/write/delete impact on product data. However, the real-world priority is contextually bounded by the niche deployment footprint of Vvveb and the requirement for multi-vendor architecture - single-vendor deployments are exposed to data loss but not cross-tenant data theft. EPSS data was not provided; without it, exploitation probability cannot be quantified. No public exploit code and no CISA KEV listing means this is not confirmed actively exploited. That said, the attack is straightforward enough that any operator running Vvveb in a marketplace configuration - even a small regional deployment - should treat this as urgent and patch immediately, since the primitive IDOR requires only authenticated access and knowledge of sequential product IDs. The C:H rating is justified by product detail disclosure (commercial pricing, catalog structure), and A:H is warranted because delete cascades across six related tables (product_to_taxonomy_item, product_to_site, product_option_value, product_option, product_content, product_image, product), which is recoverable only from backup.

A malicious Vendor authenticates to the Vvveb backend using legitimate credentials and identifies a competitor's product_id - either through enumeration of sequential integer IDs or by observing product URLs in the storefront. The attacker sends a crafted POST request to the products controller specifying the competitor's product_id in a duplicate or delete action. Without the admin_id constraint in the SQL layer, the operation succeeds, allowing the attacker to exfiltrate product details, flood the competitor's catalog with duplicates, or permanently delete the competitor's products and all associated relational data across six tables. No public proof-of-concept exists at time of analysis, but the technique requires no special tooling beyond a browser or curl.