CVE-2026-111697 in ChargeOS Cloud
Summary
by MITRE • 10/16/2026
HUIZHI ChargeOS cloud through 3.0.9 contains an insecure direct object reference vulnerability in the hcp-mp MeController and OrderController that trusts client-supplied userId, openId and orderNumber parameters. Attackers can enumerate sequential member ids against endpoints like /me/getMemberBalanceByUserId and /order/orderDetail to read any member's wallet, credit, profile and charging orders.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in HUIZHI ChargeOS cloud versions up to 3.0.9 represents a classic insecure direct object reference flaw within the application logic of its MeController and OrderController components. This security defect stems from the system's failure to implement proper access control mechanisms when processing requests that rely on client-supplied identifiers such as userId, openId, and orderNumber. Instead of verifying whether the authenticated user has legitimate authorization to access or modify the specific resource identified by these parameters, the application directly maps the input values to internal database records. This architectural oversight allows any actor with network connectivity to interact with sensitive endpoints without needing valid credentials for the target accounts, effectively bypassing authentication and authorization controls that should be enforced at the server side.
The operational impact of this vulnerability is severe due to its potential for mass data enumeration and privacy violation. Attackers can exploit this flaw by systematically iterating through sequential integer values in the userId parameter when calling endpoints such as /me/getMemberBalanceByUserId or /order/orderDetail. Because the system does not validate that the requesting session belongs to the user whose ID is being queried, an attacker can retrieve sensitive financial and personal data for any member within the platform's database. This includes access to wallet balances, credit information, detailed profile attributes, and historical charging orders. The ability to enumerate these identifiers sequentially means that a single automated script could potentially harvest the private data of thousands or millions of users in a short period, leading to significant breaches of confidentiality and potential regulatory non-compliance regarding personal data protection.
From a classification perspective, this vulnerability aligns directly with CWE-639, which describes Insecure Direct Object References where an application uses user-supplied input to access objects directly without proper authorization checks. Furthermore, the exploitation technique maps to MITRE ATT&CK tactic T1078, specifically Valid Accounts or Default Accounts if default credentials are involved, but more accurately fits under data exfiltration techniques such as T1530 Data from Local System Archives or general information gathering via API abuse. The lack of object-level authorization allows the attacker to treat unique identifiers as public keys rather than private secrets, fundamentally breaking the principle of least privilege and secure by design standards expected in modern web applications.
To mitigate this vulnerability, developers must implement robust access control checks within the MeController and OrderController logic before processing any request that involves user-specific data. The application should verify that the authenticated session's identity matches the userId or openId provided in the request parameters, rejecting any mismatched requests with an appropriate error code rather than returning sensitive data. Additionally, implementing rate limiting on these endpoints can help mitigate enumeration attacks by detecting and blocking abnormal volumes of sequential access attempts. It is also recommended to use non-sequential, random identifiers such as UUIDs for internal user references instead of simple integers where possible, although this should not be relied upon as the sole defense since security through obscurity is insufficient without proper authorization checks. Regular security testing including automated DAST and manual penetration tests focusing on broken access control patterns are essential to ensure that similar flaws do not exist in other parts of the application architecture.