yshop-crm CVE-2026-109173

Requires a valid authenticated back-office session on yshop-crm (PR:L); any low-privileged user account suffices because the /admin-api/crm/invoice/check handler in CrmInvoiceController has no @PreAuthorize annotation and the approver-identity checks in CrmInvoiceServiceImpl are commented out. The attacker only needs to know or guess an existing invoice id, which is supplied directly in the request. Exploitation is LIMITED by the need for authentication (not exploitable by anonymous remote attackers) and is constrained to the invoice approve/reject workflow - it does not grant data disclosure or code execution. No special non-default configuration is required; the missing authorization is present in the shipped code through version 2.1.3.

This is a genuine but moderate-severity business-logic flaw, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 (Medium) and is internally consistent with the description: network-reachable, low complexity, requires low privileges (PR:L - any authenticated back-office user), no user interaction, and only a limited integrity impact (VI:L) with no confidentiality or availability loss. CWE-862 (Missing Authorization) matches the root cause precisely. Publicly available POC code exists (a Python script in a third-party GitHub repo), which raises practical exploitability, but there is NO CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation - POC availability and active exploitation are distinct signals and should not be conflated. The key limiting factor is that the attacker must already hold valid back-office credentials, so this is a privilege-escalation/authorization-bypass issue usable by a malicious or compromised insider rather than an anonymous internet attacker. Net: a real but bounded priority - patch in normal cycles, prioritize if untrusted or low-privilege staff have back-office accounts.

A low-privileged back-office user (or an attacker who has phished/compromised any staff account) who is not authorized to approve invoices sends a crafted POST to /admin-api/crm/invoice/check supplying an arbitrary invoice id, and the server approves or rejects it despite the lack of approver authorization. A public Python POC (poc_crm_invoice_check.py) demonstrates the request. Because AC is low and no user interaction is needed, the request succeeds reliably once any authenticated session is held.