CVE-2026-92463: yshop-crm Authorization Bypass Vulnerability

CVE-2026-92463 Overview

CVE-2026-92463 is a missing authorization vulnerability [CWE-862] in yshop-crm through version 2.1.3. The flaw resides in the GET /admin-api/system/user/page endpoint, where the @PreAuthorize annotation is commented out in the source code. Any authenticated back-office user can invoke the endpoint without holding the system:user:list permission. When the authenticated account also carries a role with data scope ALL, the endpoint returns the full user directory. Exposed fields include login names, nicknames, departments, email addresses, mobile numbers, and last login information. Attackers can weaponize this directory listing for follow-on phishing, credential stuffing, and lateral movement inside the CRM.

Critical Impact

Authenticated attackers can enumerate every user account in a yshop-crm deployment, harvesting personally identifiable information and credential targets from a single unauthorized API call.

Affected Products

• yshop-crm through version 2.1.3
• The yshop-module-system-biz component (UserController) shipped with the affected releases
• Deployments where authenticated back-office roles are assigned data scope ALL

Discovery Timeline

• 2026-09-16 - CVE-2026-92463 published to NVD
• 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92463

Vulnerability Analysis

The yshop-crm project exposes administrative operations under /admin-api/system/user/page. This endpoint is intended to be gated by the Spring Security @PreAuthorize("@ss.hasPermission('system:user:list')") annotation on the UserController.getUserPage handler. In the affected releases the annotation is present in source but commented out, so the Spring method security interceptor never evaluates the required authority. The framework still requires a valid authentication token, so unauthenticated callers are rejected, but any low-privilege back-office user passes the check.

Downstream, AdminUserServiceImpl delegates result filtering to the DeptDataPermissionRule. When the caller's role is configured with data scope ALL, the rule returns unrestricted results across every department. The combination of the disabled annotation and permissive data scope collapses two independent access controls into a single failure mode, producing a full-directory disclosure.

Root Cause

The root cause is a broken authorization check [CWE-862]. Method-level authorization was designed but disabled by commenting out @PreAuthorize, leaving the controller relying only on authentication. The tenant-level data permission rule then applies no row filtering for ALL scope, so no defense-in-depth compensates for the missing method check.

Attack Vector

Exploitation requires network access to the /admin-api surface and valid credentials for any back-office account whose role includes data scope ALL. The attacker authenticates, obtains a session or bearer token, and issues a GET request to /admin-api/system/user/page with a large pageSize parameter. The response returns the paginated directory including login names, nicknames, department identifiers, email addresses, mobile numbers, and last login timestamps. A public proof-of-concept script demonstrates the enumeration flow; see the GitHub PoC for yshop-crm and the VulnCheck Advisory on yshop-crm for technical details.

// No verified exploit code block is reproduced here.
// Refer to the public proof-of-concept linked above for the exact request structure.

Detection Methods for CVE-2026-92463

Indicators of Compromise

• Requests to GET /admin-api/system/user/page originating from user accounts that do not hold the system:user:list permission.
• Repeated paginated calls to the same endpoint with increasing pageNo values or unusually large pageSize values.
• Application logs where UserController.getUserPage returns HTTP 200 for principals whose role definitions exclude system user listing.

Detection Strategies

• Correlate authenticated API access logs against the role-to-permission mapping to flag calls that would have been rejected by an active @PreAuthorize check.
• Build an alert on any single session pulling more than one page of /admin-api/system/user/page within a short window.
• Perform authenticated code review or SAST against the yshop-module-system-biz module to confirm the state of the @PreAuthorize annotation in deployed builds.

Monitoring Recommendations

• Forward yshop-crm application and access logs to a centralized analytics platform and retain them for outbound abuse investigations.
• Baseline normal usage of /admin-api/system/user/* endpoints per role and alert on deviations.
• Monitor identity providers and mail gateways for spikes in phishing directed at addresses that match the exposed user directory.

How to Mitigate CVE-2026-92463

Immediate Actions Required

• Restrict network exposure of /admin-api to trusted management networks or VPN segments until a patched build is deployed.
• Audit all back-office roles and remove data scope ALL from accounts that do not require organization-wide visibility.
• Rotate credentials for any account whose directory data may have been exposed and enforce multi-factor authentication on back-office logins.

Patch Information

No fixed version is listed in the NVD entry at the time of publication. Track the upstream GitHub Repository for yshop-crm for a release beyond 2.1.3 that restores the @PreAuthorize("@ss.hasPermission('system:user:list')") annotation on UserController.getUserPage. Operators building from source can re-enable the annotation locally as an interim fix and rebuild the yshop-module-system-biz artifact.

Workarounds

• Re-enable the commented-out @PreAuthorize annotation on the getUserPage handler in UserController.java and redeploy.
• Place a reverse proxy or web application firewall rule in front of /admin-api/system/user/page that enforces an allow-list of administrator source addresses.
• Reconfigure the DeptDataPermissionRule policy so that no production role is granted data scope ALL by default.

# Example NGINX rule limiting the vulnerable endpoint to a management CIDR
location = /admin-api/system/user/page {
    allow 10.10.0.0/24;   # admin jump network
    deny  all;
    proxy_pass http://yshop_backend;
}