CVE-2026-92459: yshop-crm Auth Bypass Vulnerability

CVE-2026-92459 Overview

CVE-2026-92459 is a missing authorization vulnerability in yshop-crm through version 2.1.3. The flaw resides in the receiveCustomer endpoint of the CrmCluesController class. Authenticated back-office users can claim sales leads assigned to other employees by invoking the lead-claim endpoint and overwriting the ownerUserId field. The endpoint enforces no permission checks, access logging, or quota validation. Any user with a valid session can reassign leads in bulk to their own account. The weakness maps to CWE-862: Missing Authorization and impacts data integrity within the customer relationship management (CRM) workflow.

Critical Impact
Authenticated back-office users can steal sales leads from other employees at scale, undermining CRM data integrity and sales attribution.

Affected Products

yshop-crm through version 2.1.3
yshop-module-crm-biz module containing CrmCluesController
Deployments exposing the receiveCustomer administrative endpoint

Discovery Timeline

2026-09-16 - CVE-2026-92459 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92459

Vulnerability Analysis

yshop-crm is an open-source Java-based CRM platform built on Spring Boot. The CrmCluesController exposes a receiveCustomer endpoint that transfers ownership of a sales lead (referred to internally as a "clue") to the requesting user. The controller invokes the service layer without validating whether the caller has the authority to modify the target lead.

Any authenticated back-office account can send a request that overwrites the ownerUserId field for an arbitrary lead identifier. The service implementation persists the change without checking role membership, team boundaries, or the current owner of the record. No audit event is generated, and no rate limiting or quota applies to the operation.

The primary impact is loss of integrity for CRM lead data. An attacker with a low-privilege account can enumerate lead identifiers and reassign them in a loop, transferring competitor pipelines onto their own account.

Root Cause

The root cause is the absence of an authorization check in the receiveCustomer handler in CrmCluesController.java and the corresponding CrmCluesServiceImpl.java method. The code trusts the authenticated principal and writes the caller identifier into ownerUserId regardless of the previous owner or team assignment. This matches the CWE-862 pattern where a critical operation lacks an access control decision.

Attack Vector

Exploitation requires network access to the administrative interface and valid credentials for any back-office user. The attacker sends an authenticated HTTP request to the lead-claim endpoint with a target lead identifier. The server processes the request and updates ownership without further checks. A proof-of-concept script is published in the LinYuanyi1 cve-request-poc repository. Additional technical context is available in the VulnCheck advisory for yshop-crm.

No verified sanitized code example is available. The vulnerability logic is documented in the CrmCluesController source and CrmCluesServiceImpl source.

Detection Methods for CVE-2026-92459

Indicators of Compromise

Bursts of HTTP requests to the CRM receiveCustomer lead-claim endpoint from a single authenticated user.
Database rows where ownerUserId on crm_clues records changes to the same account within a short window.
Sales pipeline reports showing sudden lead transfers that do not correspond to legitimate reassignment workflows.

Detection Strategies

Add server-side logging to the receiveCustomer handler to capture caller, target lead identifier, previous owner, and new owner.
Compare ownerUserId changes against expected assignment rules or team boundaries and alert on out-of-team transfers.
Correlate application logs with database audit trails to identify accounts claiming volumes of leads inconsistent with baseline behavior.

Monitoring Recommendations

Track request rate per session against the lead-claim endpoint and alert on thresholds indicative of bulk enumeration.
Review CRM ownership change reports weekly to identify unauthorized reassignments.
Enable web application firewall (WAF) logging in front of the yshop-crm admin interface for retrospective analysis.

How to Mitigate CVE-2026-92459

Immediate Actions Required

Restrict access to the yshop-crm administrative interface to trusted network segments and known operators.
Audit recent ownerUserId changes on the crm_clues table and roll back unauthorized transfers.
Reduce standing back-office privileges and remove inactive accounts that could be abused for lead theft.
Monitor the yshop-crm repository for a patched release.

Patch Information

At the time of publication, no vendor patch is referenced in the NVD entry for versions through 2.1.3. Operators should track the yshop-crm GitHub repository and the VulnCheck advisory for fix availability. Until a patch ships, apply the workarounds below.

Workarounds

Add a server-side authorization check in CrmCluesServiceImpl to verify the caller owns the lead or holds a role permitted to reassign it.
Introduce role-based access control on the receiveCustomer route so only supervisors or lead-distribution roles may invoke it.
Implement per-user quotas and rate limits on lead-claim operations to blunt bulk abuse.
Enable structured audit logging for every ownership change to support detection and forensics.

bash

# Configuration example: restrict admin interface via reverse proxy
# nginx snippet limiting the CRM lead-claim endpoint to internal ranges
location /admin/crm/clues/receive {
    allow 10.0.0.0/8;
    deny all;
    limit_req zone=crm_claim burst=5 nodelay;
    proxy_pass http://yshop_backend;
}