CVE-2026-111348 in Likeshop
Summary
by MITRE • 10/16/2026
Likeshop through 3.5.1 contains an insecure direct object reference vulnerability in AfterSale.php and AfterSaleLogic.php that lets authenticated users access other customers' after-sale records by supplying their ids. Attackers with self-registered accounts can call the detail, goodsInfo, cancel, express, and again actions to read refund and order data, cancel refunds, overwrite return shipment details, or re-open refused refunds.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Likeshop versions through 3.5.1 represents a critical failure in access control mechanisms, specifically categorized as an Insecure Direct Object Reference (IDOR) within the application's after-sales module. This flaw resides primarily in the AfterSale.php and AfterSaleLogic.php components of the software architecture. The core technical issue stems from the system's reliance on user-supplied identifiers to retrieve or manipulate sensitive data without performing adequate authorization checks against the authenticated session context. When a user initiates an action such as viewing details, retrieving goods information, canceling a request, updating express shipping details, or re-opening a previously refused refund, the application accepts parameters directly from the client side and uses them to query the database. Crucially, the backend logic fails to verify that the identifier provided by the requester actually belongs to the currently authenticated user account. This lack of server-side validation allows an attacker to simply modify the unique identifiers associated with after-sale records in their API requests or HTTP calls to target resources belonging to other customers.
From a technical perspective, this vulnerability exploits the assumption that possession of a valid session token is sufficient for access control, ignoring the necessity of object-level permission checks. In a secure implementation, every request involving sensitive data must validate that the resource being accessed is explicitly linked to the identity presented in the authentication credentials. Here, the absence of such validation means that any authenticated user can enumerate and interact with after-sale records by iterating through sequential or predictable IDs. The impact is severe because it grants unauthorized access to a wide range of personally identifiable information (PII) and financial data associated with refunds and orders. Attackers possessing self-registered accounts, which are often easy to obtain in e-commerce platforms due to low barriers to entry, can exploit this flaw without needing elevated privileges or complex exploitation techniques beyond basic parameter manipulation.
The operational impact of this vulnerability extends across multiple dimensions of business integrity and customer trust. By accessing the detail and goodsInfo endpoints, attackers can read confidential refund amounts, order histories, and product specifics belonging to other users, leading to a significant breach of data privacy. Furthermore, the ability to invoke cancel actions on after-sale requests allows malicious actors to disrupt legitimate customers' efforts to resolve issues with their purchases, potentially causing financial loss or inconvenience for victims who are unable to process refunds or returns as intended. The capability to overwrite return shipment details via the express endpoint introduces a risk of logistical fraud, where attackers could redirect returned goods to different addresses or falsify tracking information, complicating dispute resolution and inventory management. Additionally, re-opening refused refunds through the again action enables unauthorized financial manipulation, potentially allowing users to claim refunds for orders they did not purchase or have already been settled, thereby directly impacting the merchant's revenue and increasing operational overhead in fraud detection.
This vulnerability aligns with CWE-639, which defines Insecure Direct Object Reference as a type of authorization flaw where an application exposes a reference to an internal implementation object, such as a file, directory, or database key, without proper access control checks. It also maps directly to the MITRE ATT&CK framework under T1078, specifically Valid Accounts, and potentially T1530, Data from Cloud Storage Object Misconfiguration if viewed through the lens of data exfiltration via cloud-backed databases. The exploitation path is straightforward: an attacker authenticates with a low-privilege account, identifies valid after-sale IDs belonging to other users, and modifies these IDs in subsequent API calls to perform unauthorized read or write operations on those records.
To mitigate this vulnerability, developers must implement strict server-side authorization checks for all endpoints within the AfterSale module. Every request that accesses or modifies an after-sale record must verify that the resource ID corresponds to a transaction owned by the authenticated user making the request. This can be achieved by joining the after-sales table with the orders or users table during database queries and ensuring the user_id matches the session's current user identity before returning data or executing mutations. Additionally, implementing randomization for internal identifiers rather than using sequential integers can make enumeration more difficult, although it does not replace the need for proper access control logic. Input validation should also be enforced to ensure that supplied IDs are of the expected format and exist within the system context relevant to the current user. Regular security audits and static code analysis focused on authorization flaws in object references will help prevent similar issues from being introduced during future development cycles, ensuring compliance with secure coding standards such as OWASP API Security Top 10, particularly regarding Broken Object Level Authorization (BOLA).