yshop-crm CVE-2026-109171

Requires a valid authenticated back-office session on yshop-crm (any user, including the lowest-privilege role) because the POST /admin-api/crm/contract/check endpoint in CrmContractController carries no @PreAuthorize annotation and its approver-identity checks are commented out, so no specific role, feature flag, or non-default configuration is needed - the weakness is present in the shipped default code through version 2.1.3. The only limiting factor is that the attacker must first possess or obtain back-office credentials (PR:L); it is not exploitable by fully unauthenticated remote attackers, and impact is confined to contract approval/rejection state and the downstream deal/stock data it affects.

This is a medium-severity authorization flaw (CWE-862) whose signals are internally consistent and point to a real but bounded risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows a network-reachable, low-complexity attack requiring low privileges and no user interaction, and the impact is deliberately narrow: VI:L only, with VC:N and VA:N - i.e. a limited integrity impact and no confidentiality or availability loss. The key gating factor is PR:L: exploitation requires any valid authenticated back-office account, so this is an insider / post-compromise privilege-boundary issue, not a pre-auth internet-facing RCE. Public exploit code exists (a Python POC), which raises practical exploitability, but there is NO CISA KEV listing and NO EPSS score was provided in the input, so there is no evidence of active or widespread exploitation. The reporter is VulnCheck (disclosure@vulncheck.com), a credible source, and the POC plus annotated source links corroborate the technical claim. Net assessment: a legitimate access-control bug worth patching, but not an emergency - its real-world priority is moderated by the authentication requirement, the limited (integrity-only, low) impact, and the niche footprint of the affected product. EPSS and KEV data are absent rather than conflicting; do not treat the public POC as evidence of in-the-wild exploitation.

A low-privileged employee (or an attacker who has phished/obtained any back-office login) sends a single crafted POST request to /admin-api/crm/contract/check and approves or rejects CRM contracts they were never authorized to act on, tampering with customer deal/purchase records or forcing products back into stock. Because the endpoint has no @PreAuthorize annotation and the approver check is commented out, the server accepts the action from any authenticated session. A public Python POC (poc_crm_contract_check.py) automates this, and the low attack complexity means no special timing or conditions are needed.