Yshopmall CVE-2026-110120

Requires an authenticated Yshopmall member account (PR:L); the attacker must supply a victim's after-sales id together with the matching orderCode when invoking deleteAfterSalesOrder, addLogisticsInformation, or GET /applyForAfterSales/{key}, because the StoreAfterSalesController/ServiceImpl logic does not verify record ownership against the caller's identity. Exploitation is LIMITED by the need for valid member credentials and by having to obtain or enumerate valid victim after-sales ids and orderCodes; it does not work unauthenticated and affects only the after-sales data of other members, not system-wide resources.

This is a medium-severity authorization flaw (IDOR, CWE-639) whose signals are internally consistent and point to a real but bounded risk. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) scores 5.3 and tells a coherent story: network-reachable, low complexity, but requiring an authenticated member account (PR:L) and yielding only limited confidentiality and integrity impact with no availability impact. No EPSS score, KEV listing, or POC flag was supplied in the input, so there is no evidence of active exploitation or published exploit code - exploitation status is therefore 'no public exploit identified at time of analysis.' Note that the input Tag labels this 'Authentication Bypass,' which conflicts with both the description and CWE-639: this is an authorization/access-control (IDOR) issue, not an authentication bypass - no credentials are bypassed, a valid member session is still required. The realistic risk is horizontal data access and tampering between legitimate members rather than mass unauthenticated compromise; it is a genuine data-integrity and privacy issue for multi-tenant deployments but not an emergency patch-tonight item on CVSS/EPSS grounds. EPSS and KEV data are missing from the input and cannot be assumed either way.

An authenticated member of a Yshopmall storefront logs in with their own low-privilege account, then calls the after-sales API (e.g., GET /applyForAfterSales/{key}, deleteAfterSalesOrder, or addLogisticsInformation) while substituting another member's after-sales id and orderCode. Because the backend does not verify that the record belongs to the caller, the attacker reads the victim's order items and can tamper with or delete the victim's after-sales records. No public exploit code is identified in the provided data, though a detailed technical write-up (hackmd) and a VulnCheck advisory describe the vulnerable controller logic.