Huizhi Chargeos Cloud
Monthly
HUIZHI ChargeOS cloud through version 3.0.9 fails to bind the caller-supplied userId parameter in the hcp-mp PayController.xcxRecharge endpoint to the identity of the authenticated member making the request, so any low-privilege member or mini-program account (PR:L per the CVSS vector) can arbitrarily credit or reduce any other member's wallet balance without any payment and consume charging services for free. The issue is a CWE-639 authorization bypass through a user-controlled key, scored 7.1 by the reporter and independently assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, meaning network reachable, no user interaction, and pure integrity impact on wallet balances with no confidentiality or availability effect. No public exploit identified at time of analysis, although a public technical writeup of the IDOR and the affected Java source are both linked in the references, and no vendor-released patch has been identified, so any internet-exposed instance at or below 3.0.9 whose member API is reachable and where a member account can be obtained should be treated as at risk.
HUIZHI ChargeOS cloud deployments through version 3.0.9 expose other members' wallet balances, credit, profile and charging-order records to any authenticated member account, because the hcp-mp MeController and OrderController trust client-supplied userId, openId and orderNumber parameters instead of deriving identity from the session. The CVSS 4.0 base score is 7.1 (assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), reflecting a genuine but bounded confidentiality-only risk: a low-privileged authenticated user (any registered member, no admin role) can enumerate sequential member IDs against endpoints such as /me/getMemberBalanceByUserId and /order/orderDetail to read arbitrary members' data, with no modification or denial-of-service capability. There is no CISA KEV confirmation of active exploitation and no public exploit code identified at time of analysis, although a public technical writeup of the flaw and the vulnerable source files are referenced; exploitability is gated on first obtaining one valid member credential.
HUIZHI ChargeOS cloud through version 3.0.9 fails to bind the caller-supplied userId parameter in the hcp-mp PayController.xcxRecharge endpoint to the identity of the authenticated member making the request, so any low-privilege member or mini-program account (PR:L per the CVSS vector) can arbitrarily credit or reduce any other member's wallet balance without any payment and consume charging services for free. The issue is a CWE-639 authorization bypass through a user-controlled key, scored 7.1 by the reporter and independently assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, meaning network reachable, no user interaction, and pure integrity impact on wallet balances with no confidentiality or availability effect. No public exploit identified at time of analysis, although a public technical writeup of the IDOR and the affected Java source are both linked in the references, and no vendor-released patch has been identified, so any internet-exposed instance at or below 3.0.9 whose member API is reachable and where a member account can be obtained should be treated as at risk.
HUIZHI ChargeOS cloud deployments through version 3.0.9 expose other members' wallet balances, credit, profile and charging-order records to any authenticated member account, because the hcp-mp MeController and OrderController trust client-supplied userId, openId and orderNumber parameters instead of deriving identity from the session. The CVSS 4.0 base score is 7.1 (assessed as CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), reflecting a genuine but bounded confidentiality-only risk: a low-privileged authenticated user (any registered member, no admin role) can enumerate sequential member IDs against endpoints such as /me/getMemberBalanceByUserId and /order/orderDetail to read arbitrary members' data, with no modification or denial-of-service capability. There is no CISA KEV confirmation of active exploitation and no public exploit code identified at time of analysis, although a public technical writeup of the flaw and the vulnerable source files are referenced; exploitability is gated on first obtaining one valid member credential.