Vvveb CMS CVE-2026-49225

Exploitation requires an authenticated session with the Vendor role (confirmed by CVSS PR:L). The attack is relevant only to Vvveb installations where multiple Vendor accounts coexist - single-vendor deployments have no cross-tenant revision records to target, eliminating the attack surface entirely. No special or non-default configuration is required beyond the standard multi-vendor setup; the revision controller is active by default in all affected versions. The attacker must identify or enumerate numeric product IDs belonging to other Vendors, which is typically feasible via sequential ID patterns on public-facing storefront URLs. Exploitation is limited to Vvveb versions prior to 1.0.8.4 across all three database backends. The CVSS UI:N rating confirms no victim interaction is required once a target product ID is known.

The NVD CVSS 3.1 score of 8.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L) accurately reflects the technical severity. Network accessibility (AV:N) and low complexity (AC:L) make the flaw trivially exploitable from any browser given a valid session. The dual High ratings for Confidentiality and Integrity are well-founded: an attacker can exfiltrate historical draft content from rival Vendors and silently overwrite live product pages by restoring old revisions. The Low availability rating reflects the narrower impact of deleting audit-trail records rather than disrupting service. No EPSS data was provided in the source intelligence; the vulnerability is absent from CISA KEV and no public exploit code has been identified, meaning exploitation probability from automated or opportunistic actors is currently unconfirmed. Real-world risk is meaningfully bounded by two factors: the requirement for an existing Vendor account on the target platform, and the flaw's relevance only to multi-vendor deployments - single-vendor installations have no cross-tenant attack surface to exploit. Defenders running shared Vvveb storefronts with multiple Vendors should treat this as a high-priority remediation despite the absence of confirmed active exploitation.

An authenticated Vendor on a shared Vvveb storefront identifies competitor product IDs - often sequential integers discoverable via public-facing product URLs - then issues revision list, restore, or delete requests substituting those foreign product IDs. The attacker reads proprietary draft copy and historical pricing from rival Vendor revisions, then restores an outdated revision over the competitor's current live product page, corrupting its storefront presence, before issuing a delete call to remove the revision records and erase the audit trail. No public exploit has been identified at time of analysis, but the attack requires only a valid browser session and basic product ID enumeration.