CVE-2026-109173 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 invoices via POST /admin-api/crm/invoice/check. The CrmInvoiceController check handler lacks @PreAuthorize and approver checks are commented out, letting attackers bypass the invoice approval workflow by supplying any invoice id.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
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 flaw manifests as an insecure direct object reference combined with missing function-level authorization controls on the endpoint responsible for processing invoice approvals and rejections. The affected route is POST /admin-api/crm/invoice/check, which serves as the primary mechanism for users to validate or deny financial transactions within the customer relationship management module. In a properly secured system, this action should be restricted to specific roles with explicit permission to manage invoices, such as finance managers or senior administrators. However, due to implementation errors in the CrmInvoiceController class, any authenticated user possessing valid credentials for the back-office portal can execute this operation regardless of their assigned role or privileges.
The technical root cause lies directly within the source code of the check handler method inside CrmInvoiceController. The developer failed to implement standard Spring Security annotations such as @PreAuthorize, which are typically used to enforce declarative access control based on user roles or permissions before a method is executed. Furthermore, explicit logic checks that would verify whether the current session's user has the authority to approve or reject the specific invoice being targeted were commented out during development or debugging phases and never restored in production builds. This oversight effectively neutralizes any server-side validation of authorization context, allowing an attacker who has successfully authenticated into the system to manipulate financial records by simply supplying arbitrary invoice identifiers via HTTP POST requests.
From a security classification perspective, this vulnerability aligns with CWE-285 Improper Authorization and CWE-639 Injection of Critical Data Without Validation or Encoding in some contexts where object references are manipulated without checking ownership. In terms of the MITRE ATT&CK framework, this behavior is indicative of T1078 Valid Accounts, as it relies on legitimate credentials to perform unauthorized actions, and potentially relates to privilege escalation if lower-privileged users can affect high-value financial workflows. The absence of role-based access control checks means that even a low-level support agent or data entry clerk could theoretically approve fraudulent invoices or reject legitimate payments, leading to significant operational disruptions and potential financial loss for the organization.
The operational impact of this vulnerability is severe due to its direct influence on business-critical processes involving revenue recognition and cash flow management. An attacker with basic authentication can bypass the intended approval workflow, potentially allowing unauthorized expenditures to be processed without oversight or blocking legitimate payments to disrupt operations. This lack of segregation of duties violates fundamental internal control principles required by standards such as SOX for financial reporting integrity. Additionally, because the vulnerability allows manipulation via simple API calls, it is easily exploitable using automated tools or scripts, increasing the risk of widespread compromise if credentials are leaked through other vectors like phishing or credential stuffing attacks.
To mitigate this vulnerability immediately, organizations running yshop-crm versions up to 2.1.3 should apply any available patches provided by the vendor that restore the commented-out authorization logic and implement proper role-based access control annotations on the CrmInvoiceController check handler. If patching is not immediately feasible, temporary mitigations include restricting network-level access to the /admin-api/crm/invoice/check endpoint using firewall rules or reverse proxy configurations to limit exposure only to trusted IP ranges associated with authorized administrative workstations. Implementing multi-factor authentication for all back-office accounts can also reduce the risk of credential compromise leading to exploitation. Long-term remediation requires a comprehensive review of access control implementations across the application, ensuring that every state-changing endpoint enforces strict authorization checks against user roles and resource ownership before processing requests.