CVE-2026-110127 in waynboot-mall
Summary
by MITRE • 10/13/2026
waynboot-mall through 2.0.0 contains an insecure direct object reference vulnerability in the mobile CartController that allows authenticated members to modify or delete other members' cart items. Attackers can enumerate sequential cart ids via PUT /cart, POST /cart/changeNum, and DELETE /cart/{cartId} to change quantities, selection state, or remove items.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in waynboot-mall versions up to 2.0.0 represents a classic insecure direct object reference (IDOR) flaw within the mobile CartController component. This security defect arises from an insufficient authorization check on server-side endpoints that handle cart management operations, specifically PUT /cart, POST /cart/changeNum, and DELETE /cart/{cartId}. In these API interactions, the application relies exclusively on client-supplied identifiers to locate specific shopping cart items without verifying whether the requesting authenticated user is the legitimate owner of those items. Consequently, any authenticated member can manipulate or destroy data belonging to other users by simply altering the sequential integer values used as primary keys for cart entries.
From a technical perspective, the root cause lies in the absence of cross-reference validation between the session identity and the resource ownership metadata. When an attacker sends a request with a modified cart ID parameter, the backend processes it based on the provided identifier rather than checking if that identifier belongs to the currently authenticated user's account. This allows for unauthorized modification of item quantities, changes to selection states such as marking items as selected or unselected, and complete removal of other users' products from their respective shopping carts. The sequential nature of these identifiers further facilitates automated enumeration attacks where an attacker can iterate through a range of IDs to discover valid cart entries belonging to various users within the system.
The operational impact of this vulnerability is significant for both end-users and business integrity. Users face direct financial risk as attackers can remove desired items from their carts, potentially causing lost sales if those items are purchased by others before checkout. Additionally, malicious actors could alter quantities or selection states to disrupt normal shopping workflows or cause confusion during the payment process. For the organization, this represents a breach of data confidentiality and integrity regarding user-specific transactional data. It undermines trust in the platform's security posture and exposes the business to potential liability under various data protection regulations that mandate safeguarding personally identifiable information and financial-related records.
This vulnerability aligns with CWE-639, which categorizes issues related to authorization bypass via direct object references. In terms of offensive cybersecurity frameworks, this behavior maps directly to MITRE ATT&CK technique T1078, specifically the Valid Accounts sub-technique where an attacker leverages legitimate credentials to access resources they are not authorized to view or modify. The exploitation method also reflects aspects of automated enumeration often seen in broader account takeover campaigns, although here it is limited to cart data rather than full account compromise.
To mitigate this vulnerability, developers must implement strict object-level authorization checks on all endpoints within the CartController. This involves ensuring that every request includes a verification step where the system compares the user ID associated with the active session against the owner ID stored in the database record for the requested cart item. If these identifiers do not match, the server should reject the request with an appropriate HTTP 403 Forbidden status code rather than processing it. Furthermore, adopting non-sequential or cryptographically secure random identifiers for internal resource references can reduce the ease of enumeration, although this is a secondary defense and does not replace proper access control logic. Regular security testing using static application security testing tools configured to detect IDOR patterns should be integrated into the development lifecycle to prevent similar flaws in future releases.