CVE-2026-111615 in mall4cloud
Summary
by MITRE • 10/16/2026
Mall4cloud through 4.0 contains an insecure direct object reference vulnerability that allows authenticated merchants to read other shops' buyer shipping addresses via the multishop OrderController getOrderAddr handler. Attackers can enumerate auto-increment orderAddrId values in GET /m/order/order_addr/{orderAddrId} requests to obtain consignee names, mobile numbers, addresses and post codes platform-wide.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within Mall4cloud versions up to 4.0 represents a classic instance of an Insecure Direct Object Reference (IDOR), categorized under CWE-639 in the Common Weakness Enumeration standard. This flaw resides specifically within the multishop OrderController component, targeting the getOrderAddr handler which processes requests for retrieving shipping address details associated with specific orders. The core technical deficiency lies in the application's failure to implement proper authorization checks that verify whether the authenticated user requesting the data is actually authorized to access the resource identified by the provided identifier. Instead of validating ownership or tenant isolation based on the session context, the system relies solely on the client-supplied orderAddrId parameter, assuming that possession of a valid ID implies permission to view the associated record.
From an operational perspective, this architectural oversight allows any authenticated merchant account within the platform to bypass intended data segregation boundaries. By manipulating the orderAddrId value in GET requests directed at the /m/order/order_addr/{orderAddrId} endpoint, attackers can perform sequential enumeration of auto-incrementing identifiers. Since these IDs are typically predictable and sequentially assigned, an attacker does not need complex exploitation techniques or authentication bypasses beyond possessing a valid merchant login. They simply iterate through integer values to retrieve shipping addresses belonging to other merchants' customers across the entire platform. This capability transforms what might seem like a minor data exposure into a significant privacy breach affecting potentially thousands of end consumers whose personally identifiable information is exposed without consent.
The impact of this vulnerability extends beyond simple data leakage, as it facilitates large-scale harvesting of sensitive personal information including consignee names, mobile phone numbers, physical addresses, and postal codes. This aggregated dataset can be leveraged for various malicious activities such as targeted phishing campaigns, social engineering attacks, or even physical security threats against individuals whose locations are revealed. Furthermore, the exposure undermines trust in the platform's ability to protect customer data, which is critical for e-commerce operations adhering to regulatory frameworks like GDPR or CCPA that mandate strict controls over personal data access and processing. The lack of proper object-level authorization means that the principle of least privilege is violated, allowing users to interact with resources outside their designated scope.
To mitigate this vulnerability, developers must implement robust server-side validation for every request involving sensitive data retrieval. This involves ensuring that each API call verifies that the authenticated user has explicit permission to access the specific orderAddrId being requested, typically by cross-referencing the ID against a database table linked to the current merchant's tenant or shop identifier. Implementing strict access control lists (ACLs) and enforcing multi-tenant isolation at the application logic layer is essential. Additionally, adopting non-predictable identifiers such as UUIDs instead of auto-incrementing integers can significantly reduce the feasibility of enumeration attacks by making sequential guessing computationally infeasible. Security testing should also include rigorous authorization checks to ensure that direct object references are never exposed without proper context validation, aligning with ATT&CK techniques related to data exfiltration and unauthorized access patterns.