HUIZHI ChargeOS EUVD-2026-102988

Requires a valid authenticated session on the ChargeOS 'hcp-mp' member/mini-program API (PR:L) - i.e. any registered member account suffices; no admin role is needed. Exploitation then relies on the specific affected endpoints /me/getMemberBalanceByUserId and /order/orderDetail accepting client-supplied userId, openId and orderNumber parameters, which the MeController and OrderController trust without an ownership/authorization check. The limiting factors are that the attacker must first obtain one working member credential and that member ids are sequential and enumerable; the flaw exposes confidentiality only (read access to wallet, credit, profile and order data), with no modification or denial-of-service capability.

This is a genuine but bounded confidentiality risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) and CWE-639 agree with the description: a network-reachable IDOR requiring only low privileges (PR:L - a valid but ordinary member/app account), no user interaction, and low complexity, yielding high confidentiality impact (VC:H) with no integrity or availability impact (VI:N/VA:N). Signals are internally consistent, which raises confidence in the 7.1 score. However, several exploitation-priority signals are entirely absent from the input: no EPSS probability, no CISA KEV listing, and no explicit POC flag - so there is no evidence of active exploitation. The practical risk is driven by how trivial enumeration is (sequential member ids over authenticated APIs), not by any confirmed in-the-wild activity. Net: a real priority for any operator of this product because any authenticated user can harvest all members' wallet, credit, profile and order data, but this is a mass-data-exposure/privacy issue rather than a wormable or system-compromising flaw, and there is no confirmation of exploitation at scale.

An attacker registers or obtains a single low-privilege ChargeOS member account, then scripts requests to /me/getMemberBalanceByUserId and /order/orderDetail while incrementing the client-supplied userId and orderNumber values. Because the server trusts these parameters without authorization checks, the attacker reads every other member's wallet balance, credit, profile and charging-order history. A public technical write-up (hackmd) and the vulnerable source lines are referenced, but no packaged exploit tool is indicated in the input.