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

CVE-2026-109172 Overview

CVE-2026-109172 is a missing authorization vulnerability in yshop-crm through version 2.1.3. The flaw resides in the POST /admin-api/crm/contract-receivables/check endpoint used to approve or reject contract receivables records. The handler lacks a @PreAuthorize annotation, and the approver checks inside CrmContractReceivablesServiceImpl.check are commented out. Any authenticated back-office user can approve arbitrary receivables records by id, inflating contract return_money totals and forging approval logs. The weakness is tracked as CWE-862: Missing Authorization.

Critical Impact

Any authenticated back-office account can approve or reject receivables, tampering with financial records and bypassing the intended multi-user approval workflow.

Affected Products

• yshop-crm through version 2.1.3
• yshop-module-crm-biz component (CrmContractReceivablesController)
• CrmContractReceivablesServiceImpl.check service method

Discovery Timeline

• 2026-10-12 - CVE-2026-109172 published to NVD
• 2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-109172

Vulnerability Analysis

The vulnerability stems from two independent gaps in the receivables approval flow. First, the Spring controller method handling POST /admin-api/crm/contract-receivables/check does not declare a @PreAuthorize expression, so the framework performs no role or permission evaluation before invoking the handler. Second, the service layer in CrmContractReceivablesServiceImpl.check has its approver-identity checks commented out, removing the only remaining safeguard that would validate whether the current user is actually the assigned approver for the targeted receivables record.

With both layers disabled, a receivables record can transition through the approval state purely on the basis of a request parameter. The service updates the parent contract's return_money field and appends an approval log entry attributed to the invoking user. This gives an attacker both financial impact (artificial inflation of collected payment totals) and audit-trail impact (forged approver identities on receivables records).

Root Cause

The root cause is improper access control at both the HTTP routing layer and the business logic layer. The controller omits authorization metadata that would be enforced by Spring Security, and the service implementation ships with the approver validation branch commented out rather than active. See the GitHub CRM Controller Code and GitHub CRM Service Implementation for the exact locations.

Attack Vector

An attacker with any valid back-office session issues an HTTP POST to /admin-api/crm/contract-receivables/check referencing a target receivables record id and the desired approval outcome. No elevated role, assignment, or ownership relationship is required. A proof-of-concept Python script is published as the GitHub PoC Script, and additional context is documented in the VulnCheck Advisory on YShop.

See the referenced advisory and PoC for request structure. No synthetic exploit code is reproduced here.

Detection Methods for CVE-2026-109172

Indicators of Compromise

• Requests to POST /admin-api/crm/contract-receivables/check originating from user accounts that are not the designated approver for the referenced receivables record.
• Receivables records whose approval state changed without a corresponding workflow assignment entry in the CRM audit log.
• Sudden increases in the return_money field on contracts that are not reconciled by matching payment events in finance systems.

Detection Strategies

• Enable application-layer access logging for all /admin-api/crm/contract-receivables/* routes and alert when the acting user differs from the receivables approver assignment.
• Review Spring Security configuration to flag controller methods lacking @PreAuthorize or equivalent access control annotations.
• Reconcile crm_contractreturn_money totals against the sum of approved crm_contract_receivables rows to detect tampering.

Monitoring Recommendations

• Forward web server and application logs to a centralized analytics platform and build correlation rules on anomalous approver-to-record relationships.
• Monitor for high-frequency calls to the check endpoint from a single session, which may indicate scripted abuse using the published PoC.
• Track changes to receivables approval status outside of normal business hours or by accounts without finance-role attributes.

How to Mitigate CVE-2026-109172

Immediate Actions Required

• Restrict network exposure of the /admin-api/crm/contract-receivables/check endpoint to trusted administrative networks until a patched build is deployed.
• Audit back-office user accounts and revoke credentials that do not require receivables workflow access.
• Review recent approval logs and reconcile any receivables approvals processed since the application was deployed.

Patch Information

At the time of publication, no fixed version has been identified in the NVD record. yshop-crm releases through 2.1.3 are affected. Monitor the yshop-crm GitHub repository and the VulnCheck Advisory on YShop for a vendor update. Operators building from source should add a @PreAuthorize guard to the controller method and uncomment or reimplement the approver-identity checks in CrmContractReceivablesServiceImpl.check.

Workarounds

• Apply a reverse-proxy rule that blocks POST /admin-api/crm/contract-receivables/check for users outside a dedicated finance group.
• Add a Spring Security method-level filter that enforces a role check on the receivables check handler until an upstream patch is available.
• Temporarily disable the receivables approval feature and require finance staff to process approvals through a manual, out-of-band workflow.

# Example NGINX restriction limiting the vulnerable endpoint to a finance subnet
location = /admin-api/crm/contract-receivables/check {
    allow 10.20.30.0/24;   # finance team subnet
    deny all;
    proxy_pass http://yshop_backend;
}