CVE-2026-111647 in lilishop
Summary
by MITRE • 10/16/2026
PickMall lilishop through 5.0.0 contains an insecure direct object reference vulnerability that allows authenticated buyers to read other buyers' invoice records because ReceiptServiceImpl.getDetail performs no ownership check. Attackers can supply another buyer's receipt id to GET /buyer/trade/receipt/{id} to obtain invoice titles, taxpayer identification numbers, order numbers, member ids and member names.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in PickMall lilishop versions through 5.0.0 represents a classic instance of an Insecure Direct Object Reference, commonly categorized under CWE-639. This flaw arises from the application's failure to enforce proper authorization checks when processing requests for sensitive data. Specifically, the ReceiptServiceImpl.getDetail method retrieves invoice details based solely on the identifier provided in the request parameters without verifying that the requesting user is the legitimate owner of those records. In a secure architecture, every access to an object must be validated against the current session's identity and permissions to ensure that users can only interact with resources they are explicitly authorized to view or modify.
The technical mechanism of this exploitation involves authenticated buyers manipulating the URL parameter associated with the GET /buyer/trade/receipt/{id} endpoint. By substituting their own receipt identifier with those belonging to other registered users, an attacker can bypass any implicit security controls and retrieve detailed invoice information. The data exposed through this vector includes highly sensitive personal and financial identifiers such as invoice titles, taxpayer identification numbers, order numbers, member IDs, and member names. This level of detail goes beyond simple transaction history and touches upon protected health or financial information depending on the jurisdictional context, thereby significantly increasing the severity of the privacy breach.
From an operational perspective, this vulnerability allows for systematic data scraping where attackers can iterate through sequential receipt identifiers to harvest large volumes of customer data in a short period. The exposure of taxpayer identification numbers is particularly critical as these are often used for identity theft and financial fraud. Furthermore, the disclosure of member names and order numbers facilitates targeted phishing attacks or social engineering campaigns against specific individuals within the platform's user base. This undermines the trust users place in the e-commerce platform to safeguard their private information during commercial transactions.
In terms of threat modeling, this vulnerability aligns with ATT&CK technique T1078, specifically relating to valid accounts and potentially T1539 if it leads to data exfiltration from local systems or databases. The lack of object-level authorization is a fundamental design flaw that persists even when authentication mechanisms are robust, highlighting the necessity for implementing role-based access control at the service layer rather than relying solely on user login status.
To mitigate this vulnerability, developers must implement strict ownership verification within the ReceiptServiceImpl.getDetail method before returning any data. This involves querying the database to confirm that the receipt ID requested corresponds to a record owned by the authenticated user's account ID stored in their session or token payload. Additionally, implementing rate limiting on the endpoint can help prevent automated enumeration attacks where attackers attempt to guess valid identifiers sequentially. Regular security code reviews and static application security testing should be employed to detect such authorization bypasses early in the development lifecycle, ensuring that all API endpoints adhere to the principle of least privilege by only exposing data necessary for the specific user context.