CVE-2026-92457 in yshop-crm
Summary
by MITRE • 09/16/2026
yshop-crm through 2.1.3 contains a missing authorization vulnerability in the CrmInvoiceController issueInvoice endpoint that allows authenticated back-office users to issue arbitrary invoices. Attackers can call the PUT /admin-api/crm/invoice/issue endpoint without required permissions to modify invoice status, inflate contract invoiced amounts with attacker-chosen values, and trigger invoice emails to arbitrary addresses.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
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 Customer Relationship Management module. Specifically, this flaw resides in the CrmInvoiceController class at the issueInvoice endpoint, which is exposed via the PUT /admin-api/crm/invoice/issue API route. The core technical deficiency is an absence of proper authorization checks that verify whether the authenticated user possesses the requisite permissions to modify invoice statuses or alter financial data. In a properly secured system, any operation involving the creation or modification of invoices should require explicit validation against role-based access control policies. However, in this implementation, the backend logic accepts requests from any logged-in back-office user regardless of their specific privileges, effectively treating all authenticated sessions as having administrative authority over invoice issuance.
This missing authorization flaw allows attackers to exploit the system by sending crafted HTTP PUT requests to the vulnerable endpoint with arbitrary parameters. Since the server does not validate the requester's role or permissions before processing the request, an attacker can manipulate critical financial fields such as invoiced amounts and recipient email addresses. By injecting malicious values into these fields, a compromised account or any user with basic access credentials can inflate contract invoices with fabricated figures that do not reflect actual business transactions. This capability undermines the integrity of financial records and creates significant risks for accounting accuracy and audit trails. Furthermore, the ability to trigger invoice emails to arbitrary email addresses introduces additional vectors for social engineering attacks, such as phishing or credential harvesting, by sending fraudulent billing notices to external parties who may trust the apparent legitimacy of communications from the organization's domain.
From an operational perspective, this vulnerability poses severe risks including financial fraud, data integrity compromise, and reputational damage. The ability to arbitrarily adjust invoice amounts can lead to significant monetary losses if not detected promptly during reconciliation processes. Additionally, sending fake invoices to external contacts erodes trust with clients and partners who receive these fraudulent documents. From a security architecture standpoint, this issue aligns closely with CWE-269 Improper Privilege Management, as it involves the abuse of legitimate user privileges due to insufficient enforcement of access controls. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where attackers leverage existing credentials to perform unauthorized actions within a system. The lack of server-side validation for authorization tokens or role identifiers during state-changing operations exemplifies a common pattern in insecure direct object references and broken access control scenarios prevalent in modern web applications.
To mitigate this vulnerability, developers must implement strict role-based access control checks at the controller level before processing any invoice-related requests. This involves verifying that the authenticated user holds specific permissions designated for financial administration or invoice management tasks. Input validation should also be enforced to ensure that invoiced amounts and recipient addresses conform to expected formats and business logic constraints, preventing arbitrary value injection. Additionally, implementing audit logging for all changes made via this endpoint can aid in detecting suspicious activity post-exploitation. Upgrading to a patched version of yshop-crm where these access controls are properly enforced is the primary remediation strategy. Until an update is available, network-level restrictions or Web Application Firewall rules that limit access to the /admin-api/crm/invoice/issue endpoint based on IP whitelisting can provide temporary protection against exploitation by external actors who may have obtained valid credentials through other means such as credential stuffing or phishing campaigns.