yshop-crm EUVD-2026-102995

Requires a valid authenticated account with sales-user privileges to the yshop-crm admin CRM module; exploitation is then performed by supplying arbitrary/enumerated id parameters to the CRM customer get, update, delete, and do-open endpoints, which authenticate the session but fail to verify that the requested customer record belongs to the calling user. The primary limiting factor is the need for prior authentication (PR:L) - this is not exploitable by an unauthenticated internet attacker. No special non-default configuration or user interaction is required; any environment running yshop-crm at or below 2.1.3 with provisioned sales accounts is affected.

This is a genuine but moderate-priority issue, best characterized as medium real-world risk rather than a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L) scores 5.3 (Medium) and is internally consistent with the description: remote, low-complexity, but requiring an authenticated low-privilege account (PR:L), which is the single largest limiting factor. No EPSS score, CISA KEV listing, or explicit POC flag was supplied in the input, so there is no signal of active or widespread exploitation - exploitation status is 'no public exploit identified at time of analysis'. However, a detailed third-party write-up (hackmd) and a VulnCheck advisory plus direct source-code line references are present, meaning the vulnerability mechanics are fully public and trivially reproducible even without packaged exploit code, which effectively lowers the barrier to opportunistic abuse by anyone with a valid sales account. The signals are consistent (no conflict between CVSS network vector and the description), but note that the impact is bounded: it is a per-record IDOR limited to CRM customer data, not system compromise, so the VC/VI/VA:L (not H) ratings are appropriate. Bottom line: a credible insider/low-privilege-account threat with confirmed exploitability details public, but low technical impact per action and no evidence of mass exploitation.

An authenticated sales user (or an attacker who has phished/obtained any sales-tier credential) iterates customer id values in requests to the CRM customer get/update/delete/do-open endpoints. Because the application checks authentication but not record ownership, the attacker reads other reps' customer contact details, tampers with or deletes records, or releases customers into the public pool. The exact vulnerable controller and service methods are documented in the referenced source code and hackmd write-up, so reproduction requires no custom exploit development.