Vvveb CMS CVE-2026-49223

Exploitation requires an authenticated low-privileged Vendor account (confirmed by CVSS PR:L) on a Vvveb CMS instance running any version prior to 1.0.8.4. The deployment must be configured as a multi-vendor marketplace with at least two distinct Vendor accounts managing separate products, as a single-vendor instance has no cross-vendor review boundary to violate. The attacker must be able to supply or enumerate valid product_review_id values belonging to another Vendor's products. No special network position, elevated privileges beyond the Vendor role, victim user interaction, or non-standard configuration is required beyond the multi-vendor deployment model. Limiting factors: single-vendor deployments have no cross-vendor impact surface; impact is scoped to review data only and does not enable broader system compromise or code execution.

The CVSS 7.6 High vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L) reflects a network-accessible, low-complexity flaw requiring only a standard Vendor account. Integrity impact is rated High because an attacker can edit review content, change moderation status, and delete reviews entirely; confidentiality impact is Low (review ratings, author info, and moderation state are exposed); availability impact is Low (review data can be destroyed). Real-world risk is bounded by two factors: the platform must be deployed in a multi-vendor configuration with distinct Vendor accounts, limiting exposure to marketplace-style instances, and no KEV listing or POC code indicates active or automated exploitation. EPSS data was not provided in the source intelligence, so exploitation probability is inferred from CVSS metrics alone - the AC:L and PR:L combination suggests exploitation would be straightforward for any authenticated Vendor. This is a genuine high-priority issue for multi-vendor deployments but carries reduced urgency for single-vendor configurations.

An authenticated Vendor user with a legitimate account on a multi-vendor Vvveb storefront crafts API requests to the product review management backend, substituting product_review_id values from competitor Vendors' products - obtainable via enumeration or knowledge of review IDs. The backend SQL executes without any admin_id ownership check, allowing the attacker to suppress unfavorable competitor reviews by changing their status, inject false content by editing review text, or delete reviews entirely to manipulate product ratings and visibility. No public proof-of-concept code has been identified, though the attack is mechanically straightforward given a valid Vendor session and knowledge of the parameter structure.