CVE-2026-109172 in yshop-crm
Summary
by MITRE • 10/12/2026
yshop-crm through 2.1.3 contains a missing authorization vulnerability that allows any authenticated back-office user to approve or reject receivables records by calling POST /admin-api/crm/contract-receivables/check. The handler lacks a @PreAuthorize check and the approver checks in CrmContractReceivablesServiceImpl.check are commented out, so attackers can approve records by id, inflating contract return_money and forging approval logs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in yshop-crm versions through 2.1.3 represents a critical failure in access control mechanisms within the back-office administrative interface. Specifically, this is an insecure direct object reference combined with missing function-level authorization on the endpoint responsible for managing contract receivables. The affected system exposes a POST request at /admin-api/crm/contract-receivables/check which is intended to process approval or rejection actions for financial records. Under normal operational parameters, only users possessing specific administrative privileges should be able to execute this action. However, due to the absence of proper authorization checks, any authenticated user with access to the back-office portal can invoke this endpoint regardless of their assigned role or permission level. This flaw effectively bypasses the intended security boundaries that separate standard staff from financial approvers, allowing unauthorized manipulation of sensitive business data.
From a technical perspective, the root cause lies in two distinct implementation errors within the Java-based backend logic. First, the controller method handling this request lacks a @PreAuthorize annotation or equivalent security interceptor configuration to verify user permissions before processing the input. Second, and more critically, the service layer implementation in CrmContractReceivablesServiceImpl contains commented-out code that was originally responsible for validating whether the current user has the authority to approve the specific record identified by its ID. By removing these checks without replacing them with alternative security controls, the application blindly trusts the input provided by the client side. An attacker can simply craft a POST request containing the identifier of any receivables record and submit it through this endpoint. The system will process the approval or rejection status based solely on the payload data, ignoring who is actually making the request.
The operational impact of this vulnerability is severe due to its direct effect on financial integrity and audit trails. By exploiting this flaw, an attacker can artificially inflate contract return_money values by approving receivables records that should remain pending or rejected. This manipulation distorts financial reporting metrics such as revenue recognition, cash flow projections, and overall profitability analysis. Furthermore, because the system generates approval logs for these actions, the vulnerability allows attackers to forge audit trails. These forged entries will appear legitimate within the application's logging mechanism, attributing unauthorized approvals to valid user accounts or creating a false history of administrative activity. This not only compromises data accuracy but also hinders forensic investigations and compliance audits by introducing deceptive evidence into system logs.
This issue aligns with CWE-285 Improper Authorization as it involves granting access rights for an action to an actor that is not authorized to perform the action. Additionally, from a threat modeling perspective using MITRE ATT&CK frameworks, this vulnerability facilitates lateral movement and privilege escalation within the application context if lower-level accounts are compromised. It also supports data manipulation techniques categorized under T1565 Data Manipulation where attackers modify stored data to achieve malicious goals such as financial fraud or covering tracks. The lack of server-side validation on business logic rules is a common pattern in modern web applications that prioritize rapid development over security hardening, making it essential for organizations to review their authorization middleware configurations.
To mitigate this vulnerability, immediate remediation steps must focus on restoring the missing access control checks. Developers should implement robust role-based access control (RBAC) at both the controller and service layers. The @PreAuthorize annotation or equivalent framework-specific security interceptor must be applied to the check endpoint to ensure that only users with explicit approval permissions can invoke it. Furthermore, the commented-out logic in CrmContractReceivablesServiceImpl should be reviewed and restored if it contained necessary business rule validations, such as verifying ownership of the record or checking departmental boundaries before allowing status changes. Input validation should also be strengthened to ensure that the user initiating the request matches the expected approver for that specific transaction ID. Regular security code reviews and static application security testing (SAST) scans can help detect similar missing authorization patterns in other parts of the application, preventing future instances of this class of vulnerability.