Yshop CRM CVE-2026-92458

Exploitation requires a valid authenticated back-office (admin-api) account with low privileges (PR:L) - it is NOT remotely exploitable by an anonymous attacker. The specific limiting factor is that the flawed StoreProductController onSale handler skips the permission check, so any authenticated back-office user, regardless of their assigned role, can invoke GET /admin-api/product/store-product/sale against arbitrary sequential product IDs. Impact is confined to modifying product sale status (integrity only); no data disclosure or service outage results. Affected deployments are yshop-crm through version 2.1.3.

This is a genuinely low-to-moderate risk issue despite the CRITICAL-sounding CWE-862 label. The vendor CVSS 4.0 base score is 5.3 (Medium), and the vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) tells a consistent, well-calibrated story: network-reachable, low complexity, but requiring an existing authenticated low-privilege back-office account (PR:L) and delivering only limited integrity impact (VI:L) with NO confidentiality or availability impact. In plain terms, an already-authenticated staff user can toggle products on/off sale beyond their intended permission scope - a broken-access-control/IDOR-style flaw, not a pre-auth breach. A public POC exists (VulnCheck-referenced GitHub script), which raises operational likelihood for anyone with insider or compromised back-office credentials, but there is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of active or widespread exploitation. Signals are consistent rather than conflicting: the modest CVSS and integrity-only impact align with the description of a permission-check gap affecting only product sale status. The one notable metadata conflict is the 'Authentication Bypass' tag, which mischaracterizes the flaw - this is missing authorization for an ALREADY-authenticated user, not an authentication bypass. Net: real but bounded; prioritize as a business-logic/access-control fix rather than an emergency patch.

A low-privileged back-office user (or an attacker who has phished/compromised such an account) sends GET requests to /admin-api/product/store-product/sale iterating over sequential product IDs, toggling items off-sale to sabotage the storefront or re-enabling withdrawn products. A public Python POC (C05_store_product_sale_toggle.py) automates this, so exploitation is trivial for anyone holding valid back-office credentials; the low complexity (AC:L) and lack of user interaction make scripted catalog-wide manipulation straightforward.