lilishop EUVD-2026-103069

Exploitation requires a valid authenticated buyer account on the target lilishop instance (PR:L); the attacker then supplies another buyer's receipt id to the endpoint GET /buyer/trade/receipt/{id}, which succeeds because ReceiptServiceImpl.getDetail returns the record without verifying that the requesting buyer owns it. No special product configuration or feature toggle is needed - the flaw is present in the default code path through version 5.0.0. Practical limits: the attacker must hold or register a buyer login, must know or enumerate valid receipt IDs (feasible if IDs are sequential or guessable), and can only read data - no write, modification, or privilege escalation is possible.

This is a genuine but moderate-severity information-disclosure issue, not a top-tier emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:L) correctly characterizes it: network-reachable, low attack complexity, but requiring an authenticated buyer account (PR:L) and yielding only low-confidentiality impact with no integrity or availability effect - consistent with CWE-639 (IDOR). No EPSS score, no CISA KEV listing, and no vendor-confirmed exploit-code flag were provided, so exploitation status is 'no public exploit identified at time of analysis'; however, the referenced HackMD write-up and direct GitHub links to the vulnerable ReceiptServiceImpl.getDetail method mean the technical path is fully public and the bug is trivially reproducible by anyone with a buyer login. The signals are internally consistent (no conflict between vector and description). The main reason this is a real but bounded priority is the data exposed - taxpayer identification numbers, invoice titles, order numbers, and member identities constitute PII/tax data with privacy and regulatory consequences - tempered by the low real-world footprint of lilishop and the requirement for an authenticated account that can only read, not modify, records.

An attacker registers or already holds a legitimate buyer account on a lilishop storefront, then issues GET /buyer/trade/receipt/{id} while substituting receipt IDs belonging to other buyers. Because ReceiptServiceImpl.getDetail performs no ownership check, each request returns another buyer's invoice record, allowing the attacker to enumerate and harvest taxpayer IDs, invoice titles, order numbers, and member names at scale. No public weaponized exploit is listed, but a detailed write-up and the vulnerable source are publicly linked, making reproduction straightforward.