CVE-2026-92460 in yshop-crm
Summary
by MITRE • 09/16/2026
yshop-crm through 2.1.3 fails to enforce authorization on the GET /admin-api/crm/operatelog/page endpoint, allowing any authenticated back-office user to access the installation-wide audit trail. Attackers can query the operation log to retrieve operator names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers without proper permission checks.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in yshop-crm versions through 2.1.3 represents a critical failure in access control mechanisms within the administrative interface of the application. Specifically, the GET /admin-api/crm/operatelog/page endpoint lacks sufficient authorization enforcement to restrict access based on user roles or permissions. This flaw allows any authenticated back-office user, regardless of their specific privileges or departmental scope, to query and retrieve data from the system-wide audit trail. In a properly secured environment, such sensitive operational logs should be accessible only to users with explicit administrative rights or security oversight responsibilities, ensuring that access is granted on a need-to-know basis rather than universally to all authenticated personnel.
From a technical perspective, this issue stems from an improper implementation of role-based access control (RBAC) or object-level authorization checks within the backend logic handling the specified API endpoint. The server processes requests for audit log data without verifying whether the requesting user possesses the necessary clearance level to view such information. This oversight results in a broad exposure of sensitive operational metadata, including operator names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers. By bypassing these permission checks, an attacker with valid credentials for any back-office role can systematically extract this data through automated scripting or manual queries, effectively turning the audit log into a reconnaissance tool rather than a security monitoring resource.
The operational impact of this vulnerability is significant, as it facilitates unauthorized information disclosure and aids in further attack phases such as social engineering or targeted exploitation. The retrieved operator names and nicknames can be used to identify key personnel for phishing attacks or impersonation attempts. Client IP addresses and User-Agent strings provide valuable context about the network environment and browser configurations of administrators, which can inform more sophisticated intrusion techniques. Furthermore, access to request URLs and action details reveals internal workflows and business logic, while customer identifiers expose personally identifiable information (PII) in violation of data privacy regulations such as GDPR or CCPA. This level of exposure undermines the integrity of the audit trail itself, as it becomes a vector for data leakage rather than solely a tool for accountability.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures where access control decisions are not enforced properly on protected resources. Additionally, from an offensive security perspective, this behavior corresponds to the ATT&CK technique T1078, Valid Accounts, as it exploits legitimate credentials to gain unauthorized access to sensitive data within a system. The ability to enumerate users and map administrative actions also touches upon reconnaissance activities that precede more direct attacks against application infrastructure or user accounts.
To mitigate this risk, developers must implement strict authorization checks on the GET /admin-api/crm/operatelog/page endpoint. This involves verifying that the authenticated user holds a specific role, such as Super Admin or Security Auditor, before returning any data from the audit log. It is recommended to adopt a principle of least privilege, ensuring that access rights are granular and tied directly to job functions rather than general authentication status. Additionally, implementing rate limiting on this endpoint can help prevent automated scraping of large volumes of sensitive logs. Regular security audits and code reviews focusing on API endpoints should be conducted to ensure that authorization logic is consistently applied across all administrative features, thereby preventing similar access control bypasses in other parts of the application.