CVE-2026-111657 in BeikeShop
Summary
by MITRE • 10/16/2026
BeikeShop through 2.0.0.31 contains an insecure direct object reference vulnerability in the markAsShipped handler of RmaController that allows authenticated customers to modify other customers' returns. Attackers can submit sequential RMA ids to the account/rmas/{id}/mark_as_shipped endpoint to overwrite courier names and tracking numbers and mark approved returns as shipped.
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 BeikeShop versions up to 2.0.0.31 represents a classic instance of an Insecure Direct Object Reference, commonly categorized under CWE-639 within the Common Weakness Enumeration framework. This security flaw resides specifically within the markAsShipped handler located in the RmaController component of the application's architecture. The core issue stems from insufficient authorization checks on server-side endpoints that process requests related to Return Merchandise Authorization (RMA) workflows. Instead of validating whether the authenticated user initiating the request is the legitimate owner of the specific return record being modified, the system relies solely on the object identifier provided in the HTTP request parameters. This architectural oversight allows any authenticated user with access to this endpoint to manipulate data belonging to other users by simply altering the unique identifier associated with their own requests.
From a technical perspective, the exploitation mechanism involves submitting sequential RMA identifiers to the account/rmas/{id}/mark_as_shipped API endpoint. Because the application does not enforce strict ownership verification before processing these updates, an attacker can iterate through various IDs in rapid succession. This brute-force approach enables the modification of critical fields associated with other customers' returns, specifically allowing the overwriting of courier names and tracking numbers. By successfully executing this action, the attacker effectively marks approved returns as shipped without physical possession or authorization to do so. This behavior aligns closely with MITRE ATT&CK technique T1078, which covers Valid Accounts, as it requires initial authentication but then abuses those credentials to perform unauthorized actions on resources they do not own.
The operational impact of this vulnerability is significant for both the e-commerce platform and its customer base. For customers, the primary risk involves privacy violations and potential financial fraud or confusion regarding their return status. If an attacker can alter tracking information, it may lead to legitimate returns being marked as delivered prematurely, potentially triggering refund processes before goods are actually received by the merchant. Furthermore, this manipulation disrupts the integrity of supply chain logistics data, making it difficult for merchants to track actual inventory movement and reconcile financial records accurately. For the business entity operating BeikeShop, such vulnerabilities erode customer trust and expose the organization to liability regarding mishandled returns and compromised user data integrity.
To mitigate this vulnerability, developers must implement robust object-level authorization checks within the RmaController's markAsShipped handler. The system should verify that the authenticated session belongs to the same entity as the resource being modified before allowing any state changes or data updates. This typically involves retrieving the current user's ID from their active session and comparing it against the owner_id field of the requested RMA record in the database, rejecting the request if they do not match. Additionally, implementing rate limiting on this endpoint can help mitigate brute-force attempts by sequential ID enumeration while more permanent code fixes are deployed. Regular security audits focusing on access control logic across all API endpoints are essential to prevent similar insecure direct object reference flaws from persisting in future releases of the software.