yshop-crm EUVD-2026-80665

Exploitation requires a valid authenticated back-office account of any privilege level (PR:L) with network access to the admin API; the vulnerable endpoint is GET /admin-api/crm/operatelog/page in yshop-crm through 2.1.3, which omits the permission/authorization check that should restrict audit-log access. No user interaction, special configuration, or elevated role is needed beyond a low-privilege operator login. The primary limiting factor is that the attacker must already be authenticated to the back office - there is no pre-authentication path - so realistic risk centers on malicious insiders or reuse of a compromised operator credential; impact is limited to disclosure of the operation log (no data modification or service disruption).

This is a broken-authorization information-disclosure flaw (CWE-862), not a system-takeover bug. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 and is well-calibrated: network-reachable, low complexity, no user interaction, but gated by PR:L - the attacker must already hold a valid authenticated back-office account, and impact is confidentiality-only (VI:N/VA:N, no integrity or availability effect). A public POC exists (VulnCheck advisory plus a GitHub exploit script), which meaningfully raises real-world exploitability for anyone with any low-privilege operator login. No CISA KEV listing and no EPSS score were provided, so there is no evidence of active exploitation - the signals are 'publicly available exploit code exists' rather than confirmed in-the-wild use. The dominant limiting factor is the PR:L requirement: this is a privilege-escalation-of-data / horizontal access-control gap usable by insiders or by an attacker who has already phished/compromised one back-office credential, not a pre-auth mass-exploitation candidate. Net: a real but moderate priority - patch promptly where the product is deployed, but it is a bounded internal-data-leak issue, not a critical unauthenticated RCE.

A low-privileged back-office user (or an attacker who has stolen any operator credential) sends an authenticated GET request to /admin-api/crm/operatelog/page, which fails to check permissions and returns the installation-wide operation audit log. The response leaks operator names/nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers for the entire deployment. A public Python POC (LinYuanyi1/cve-request-poc) automates this request, so exploitation requires only a valid session and minimal skill.