nopCommerce CVE-2026-117605

Exploitation requires an authenticated vendor account on a nopCommerce installation running in multi-vendor mode - the vulnerable code path is only reachable when GetCurrentVendorAsync() returns a vendor (currentVendor != null), so single-admin stores without the vendor/marketplace feature are not affected. The attacker must hold vendor-level credentials (PR:L) and reach the admin ProductController AddPopup endpoints over the network. Limiting factors: it is not remote-unauthenticated (a valid vendor login is mandatory), impact is confined to the integrity of another vendor's related-product, cross-sell and associated/grouped-product listings, and there is no confidentiality or availability impact. Fixed by upgrading to nopCommerce 5.00.0 or later, which the vendor's patch commit enforces.

This is a genuine but modest-severity authorization flaw (CWE-639, insecure direct object reference), not a high-CVSS-but-hollow finding - the vendor-assigned CVSS 4.0 score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N) accurately reflects a low-impact, integrity-only issue. The signals are internally consistent: network-reachable, low attack complexity, but requiring low-privilege authentication (PR:L) and yielding only limited integrity impact (VI:L) with no confidentiality or availability consequence. No EPSS score was supplied, the CVE is not in CISA KEV, and no exploit/PoC reference is tagged in the input, so there is no evidence of active exploitation; the vuln.today decision label is 'this_month', indicating routine prioritization rather than emergency response. The patch is confirmed available via the vendor commit. Real-world risk is bounded: an authenticated vendor on a multi-vendor nopCommerce store can tamper with another vendor's product-relationship listings, which is a trust/data-integrity problem within a marketplace rather than a path to code execution or data theft. Prioritize as a standard monthly patch cycle item, consistent with the 'this_month' decision label - not an emergency.

On a nopCommerce multi-vendor store, a malicious but legitimately registered vendor logs into the admin area and sends a request to the RelatedProductAddPopup, CrossSellProductAddPopup or AssociatedProductAddPopup handler, supplying a competitor's product id as model.ProductId. Because the handlers never verify that the parent product belongs to the requesting vendor, the attacker's products are injected into the victim vendor's related, cross-sell and grouped-product listings. No public working exploit is identified at the time of analysis, though the trigger is straightforward given a valid vendor account.