CVE-2026-110121 in Lilishop
Summary
by MITRE • 10/13/2026
PickMall lilishop through 4.4 contains an insecure direct object reference vulnerability that allows authenticated sellers to overwrite any store's product by supplying another store's goodsId to the goods update endpoint. Attackers can send PUT requests to /store/goods/goods/update/{goodsId} to replace product details and SKUs and reassign products to their own store.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in PickMall lilishop, specifically affecting versions up through 4.4, represents a critical failure in access control mechanisms known as an Insecure Direct Object Reference or IDOR. This flaw resides within the application logic governing product management for authenticated sellers. The core technical deficiency lies in the insufficient validation of input parameters when processing updates to store goods. Specifically, the endpoint /store/goods/goods/update/{goodsId} accepts a goods identifier from the request path but fails to verify that this identifier corresponds to an item owned by or associated with the currently authenticated user making the request. Consequently, the application blindly trusts the client-supplied object reference without performing any server-side authorization checks to ensure ownership rights before executing the update operation.
From a technical perspective, this vulnerability allows for arbitrary overwriting of product data across different stores within the platform. An attacker who has obtained valid authentication credentials can manipulate HTTP PUT requests directed at the vulnerable endpoint. By substituting the goodsId parameter with an identifier belonging to another store's product, the attacker gains the ability to modify critical attributes such as product details and Stock Keeping Units (SKUs). Furthermore, the vulnerability extends beyond mere modification; it enables the reassignment of products from one merchant account to another. This capability fundamentally breaks the isolation boundaries between distinct vendor entities on the marketplace platform, allowing a malicious actor to seize control over inventory that does not belong to them.
The operational impact of this flaw is severe and multifaceted. For individual sellers, it results in direct financial loss due to theft of intellectual property or merchandise data, as well as potential reputational damage if their store listings are defaced with incorrect information. For the platform operator, the implications include a complete erosion of trust among merchants who rely on the integrity of their digital storefronts. The ability to reassign products effectively allows attackers to hijack successful product pages, potentially diverting sales revenue or using legitimate-looking listings for phishing and fraud campaigns. Additionally, if the overwritten data includes malicious content such as compromised images or links, it could facilitate broader supply chain attacks against customers who trust the platform's curation.
This vulnerability aligns with CWE-639, which categorizes issues related to authorization bypasses via direct object references where the application does not verify that the user is authorized for the requested action on a specific resource. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1534 if used to move laterally within the platform's ecosystem by compromising one account to affect another. The lack of proper ownership verification is a classic example of trusting client-side inputs without server-side validation of resource association.
To mitigate this vulnerability, developers must implement strict object-level authorization checks on all endpoints that modify or delete resources. When processing requests to /store/goods/goods/update/{goodsId}, the backend logic must query the database to confirm that the goodsId provided in the URL is explicitly linked to the userId of the authenticated session making the request. If a mismatch occurs, the server should reject the request with an appropriate 403 Forbidden status code rather than proceeding with the update. Additionally, implementing rate limiting and anomaly detection can help identify unusual patterns of access across different store IDs, providing an additional layer of defense against automated exploitation attempts. Regular security audits focusing on business logic flaws are essential to prevent similar IDOR vulnerabilities in other parts of the application.