EUVD-2026-80664
GHSA-qwxr-xhwf-5r52
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege back-office user
-
ExploitInvoke receiveCustomer lead-claim endpoint
-
ExecutionOverwrite ownerUserId to self, bypassing authorization
-
ImpactBulk-reassign competitors' leads with no logging
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated back-office user account on yshop-crm (PR:L) - any valid low-privilege staff login suffices; no admin role is needed. Exploitation targets the CrmCluesController receiveCustomer (lead-claim) endpoint over the network with no user interaction. The limiting factor is the authentication requirement: the attacker must first hold or obtain valid back-office credentials. Once authenticated, the missing authorization check means no additional configuration, feature toggle, or elevated privilege is needed - leads from other employees can be reassigned by overwriting ownerUserId, and the absence of access logging or quota validation removes any built-in brake on bulk abuse. |
| Impact | This is a genuine but bounded-severity issue best characterized as broken access control (CWE-862, missing authorization) rather than a critical pre-auth flaw. The CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) is well-calibrated: the PR:L requirement means an attacker must already hold valid back-office credentials, and the impact is integrity-only (VI:H) - leads are reassigned by overwriting the ownerUserId field, with no confidentiality (VC:N) or availability (VA:N) impact and no scope change. Publicly available POC exploit code is documented (github-poc C06_crm_clues_receive.py) and the finding is credibly attributed to VulnCheck, which raises the real-world likelihood that low-privilege insiders or attackers who have already phished/obtained a staff account can trivially abuse it. However, there is no CISA KEV listing and no EPSS score provided, so there is no evidence of active or widespread exploitation - the risk profile is targeted/insider-abuse rather than mass exploitation. Net: prioritize where yshop-crm is deployed with multiple back-office users, but this is not an internet-wide emergency given the authentication prerequisite and integrity-only, non-scope-changing impact. |
| Exploit ScenarioDerived | A logged-in back-office employee (or an attacker who has compromised any low-privilege staff account) directly invokes the CrmCluesController receiveCustomer lead-claim endpoint and reassigns other employees' sales leads to themselves by overwriting the ownerUserId field. Because there is no authorization check, access logging, or quota validation, the actor can bulk-steal high-value leads. Public POC exploit code (C06_crm_clues_receive.py) demonstrates the request. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to claim and reassign sales leads belonging to other employees by invoking the CrmCluesController receiveCustomer lead-claim endpoint with a manipulated ownerUserId value. The flaw is a broken access control (CWE-862) issue that requires only a valid low-privilege staff login and no administrative role, feature toggle, or user interaction, with the practical impact limited to integrity of lead ownership data (no confidentiality or availability impact). Publicly available exploit code exists in the form of a Python proof-of-concept targeting the endpoint, and the absence of access logging or quota validation on the operation removes any built-in brake on bulk lead theft, though no confirmed active exploitation (CISA KEV) has been observed at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis; no fixed version is listed in the CPE data or references, so the primary recommendation is to treat the lead-claim endpoint as unsafe until the vendor publishes a fix and to monitor https://github.com/guchengwuyue/yshop-crm and https://www.vulncheck.com/advisories/yshop-crm-through-2.1.3-missing-authorization-via-crm-lead-claim-endpoint for an updated release. Because the flaw is server-side missing authorization, the durable fix is a code change: in CrmCluesController#receiveCustomer / CrmCluesServiceImpl (around the ownerUserId assignment at CrmCluesServiceImpl.java#L113) enforce an explicit ownership/role check so a caller can only claim leads assigned to them or explicitly released to the pool, and never trust a client-supplied ownerUserId. Until that lands, organizations running yshop-crm can apply compensating controls with known trade-offs: restrict network access to the back-office CRM API (reverse-proxy/IP allowlist or VPN-only access) so only trusted staff segments can reach the endpoint - this reduces exposure but does not stop a malicious insider with valid credentials; disable or remove the "receive customer"/lead-claim menu action and the associated endpoint for non-sales-management roles if the workflow can tolerate it; and enable reverse-proxy or WAF-level logging, alerting, and per-user rate limiting on requests to the crmclues receive/claim path to detect bulk ownerUserId reassignment attempts and reconstruct an audit trail the application itself does not provide. Note that rate limiting and logging are detective, not preventive, and that relying on the UI to hide the action is not a control because the endpoint can be invoked directly, as demonstrated by the public Python POC at https://github.com/LinYuanyi1/cve-request-poc/blob/master/yshop-crm/C06_crm_clues_receive.py.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
yshop-crm is an open-source CRM application written in Java and built on the Spring Boot / yixiang framework (the CPE cpe:2.3:a:guchengwuyue:yshop-crm:*:*:*:*:*:*:*:* identifies the guchengwuyue distribution). The vulnerable logic lives in the administrative controller CrmCluesController (yshop-module-crm-biz, path co/yixiang/yshop/module/crm/controller/admin/crmclues/CrmCluesController.java, around line 80) and its service implementation CrmCluesServiceImpl (around line 113), which together implement a "receive customer" / lead-claim action. The root cause class is CWE-862 (Missing Authorization): the endpoint validates that the caller is authenticated but does not verify that the caller has the authority to claim the specific lead being processed, so the ownerUserId field supplied in the request is trusted and written directly, effectively transferring lead ownership. Because the operation is a normal state-changing business action rather than a memory-safety or injection flaw, the assessed impact is purely integrity-focused (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N), and the attack surface is a standard HTTP request to the back-office API once credentials are held. There is no separate authentication bypass in the cryptographic sense; the weakness is authorization granularity - any valid back-office session is sufficient, and the lack of per-action audit logging or per-user claim quotas means bulk reassignment attempts would not be throttled or recorded by the application itself.
Know when Yshop Crm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Authenticated back-office user (PR:L) exploits a missing authorization check remotely (AV:N/AC:L) to tamper with lead ownership data (I:H); no confidentiality or availability impact and no scope change.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
yshop-crm through 2.1.3 contains a missing authorization vulnerability in the CrmCluesController receiveCustomer endpoint that allows authenticated back-office users to claim sales leads without proper permission checks. Attackers can invoke the lead-claim endpoint to reassign leads from other employees to themselves by overwriting the ownerUserId field, with no access logging or quota validation to prevent bulk lead theft.
Technical POC Analysis
Evidence caveat: the file supplied as "PATCHED SOURCE" (C06crmcluesreceive.py) is in fact the Python exploit script, not a diff or fixed source.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 PoC candidate from github (unverified)
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
yshop-crm, the sales CRM used through version 2.1.3, permits any staff member with an ordinary back-office login to take over and reassign sales leads owned by other employees, and publicly available exploit code exists while no vendor fix has been released. The exposure is to data integrity rather than data loss or outage: lead ownership records, pipeline attribution, and the commission and forecasting decisions built on them can be silently rewritten or harvested in bulk because the operation is unlogged and unthrottled. Leadership should care because this strikes directly at revenue accountability, creates internal dispute and potential customer-relationship leakage risk, and cannot be closed today by simply applying a patch.
No vendor-released patch identified at time of analysis. Interim mitigations: gate the receiveCustomer lead-claim endpoint at the WAF/reverse proxy to trusted networks or named accounts, disable or feature-flag ownerUserId reassignment for non-administrative roles, enforce least privilege on lead-management roles, add access logging and quota/rate validation on lead-claim operations with alerting on bulk or off-hours reassignment, and reconcile lead-ownership exports against a baseline to detect tampering.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Missing authorization in yshop-crm through 2.1.3 lets any authenticated back-office user, regardless of role or privileg
Authenticated back-office users of yshop-crm through 2.1.3 can enumerate the complete user directory via GET /admin-api/
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user - including low-privilege ope
Missing authorization in yshop-crm 2.1.3 and earlier lets any authenticated back-office (admin-api) user delete arbitrar
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to issue arbitrary invoices b
Missing authorization in yshop-crm through 2.1.3 allows any authenticated back-office user to read CRM approval-workflow
Authenticated back-office users can abuse yshop-crm through 2.1.3 to send SMS and email to arbitrary customers via POST
Missing authorization in the StoreProductController onSale handler of Yshop CRM through 2.1.3 allows any authenticated b
Insecure direct object reference in yshop-crm through 2.1.3 allows an authenticated sales user to read, overwrite, delet
Exploit-DB