Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege member
-
DeliveryCraft xcxRecharge request with arbitrary userId/amount
-
ExploitBypass missing authorization check
-
ExecutionCredit wallet without payment
-
ImpactConsume charging services for free
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Exploitation requires a valid low-privilege member/mini-program account that can reach the hcp-mp PayController.xcxRecharge endpoint (authenticated, per PR:L); the attacker then supplies attacker-controlled userId and amount parameters that the endpoint fails to authorize against the caller's identity. Limiting factors: the attacker must be able to authenticate to the platform (the WeChat mini-program / member API must be exposed and registration or an existing account obtainable), and the deployment must be ChargeOS cloud at or below version 3.0.9. No special non-default configuration is otherwise needed and no user interaction is required, so against any reachable in-scope instance the barrier is only obtaining any member credential. |
| Impact | This is a credible, real-world priority despite a moderate 7.1 CVSS. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) describes a network-reachable, low-complexity flaw requiring only low-privilege authentication (a standard app/mini-program member account) and no user interaction, with high integrity impact and no confidentiality or availability impact - consistent with a missing-authorization (IDOR, CWE-639) bug where any authenticated user can tamper with arbitrary accounts. The reporter (VulnCheck) provides a vendor-style advisory plus a public technical write-up and a direct link to the vulnerable source (PayController.java xcxRecharge, lines 18-28), which strongly corroborates the root cause but is NOT confirmation of active exploitation. No EPSS score, no CISA KEV listing, and no explicitly flagged exploit artifact were supplied in the input, so exploitation remains theoretical-but-easy rather than observed. The main signals are confirming (trivial exploitability, published analysis), while the missing signals (EPSS, KEV) are simply absent rather than conflicting - absence of EPSS/KEV here should be read as 'not yet scored/tracked,' not as low risk. Net: for any operator actually running ChargeOS cloud this is a high-priority financial-fraud bug; its limited blast radius across the global environment is a function of product footprint, not low technical severity. |
| Exploit ScenarioDerived | An attacker registers or already holds a low-privilege member account on a HUIZHI ChargeOS cloud deployment (through v3.0.9), then sends a crafted request to the hcp-mp PayController.xcxRecharge endpoint supplying an arbitrary userId and amount. Because the endpoint never verifies that the caller owns the targeted wallet, the attacker credits their own (or any) balance without paying and then consumes EV charging services for free. A public technical write-up detailing the flaw exists, though no packaged exploit tool was flagged in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
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.
RemediationAI
No vendor-released patch identified at time of analysis, so remediation must be handled as compensating controls until an official fix is published; the root fix is to stop trusting the request body and derive the target wallet owner from the authenticated session or access token, ignoring any client-supplied userId in xcxRecharge, and to credit or debit balances only against a verified payment transaction (for example a validated WeChat Pay callback or order ID) with the amount taken from the server-side order record rather than the request. If a code change can be deployed quickly, hot-patch the hcp-mp PayController so that recharge calls are restricted to self (session userId must equal the requested userId) and reject unknown or mismatched userId values with 403 before any balance write; the trade-off is that any legitimate admin or customer-service top-up flow that relied on the client-specified userId will break and must be reimplemented as a separate, role-checked endpoint. Where patching is not immediately possible, block or restrict external access to the xcxRecharge route at the reverse proxy, API gateway or WAF; the trade-off is that mini-program top-ups stop working for all users, so this is best applied as a temporary measure combined with tighter access control (allow the endpoint only from known WeChat mini-program source ranges or authenticated sessions). In parallel, restrict registration on the member API if open sign-up is enabled, since the only real precondition for exploitation is obtaining any low-privilege member account. Finally, audit the wallet ledger and payment gateway records for recharge events with no matching paid order, reverse any fraudulent credits, add alerting and rate limiting on balance-changing calls, and manually reconcile member balances; note that reversing fraudulent credits may affect legitimate users if the audit is not matched carefully against payment records. Monitor the vendor and the referenced advisories (https://www.vulncheck.com/advisories/huizhi-chargeos-cloud-through-3.0.9-unpaid-wallet-credit-via-pay-xcxrecharge and the writeup at https://hackmd.io/@hieuPenguinnn/huizhi-chargeos-mp-member-api-userid-idor) for a released fixed version, and upgrade as soon as one is available.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ChargeOS is an EV charging network management platform; its hcp-mp module is the member-facing API tier that serves the WeChat mini-program, and it is implemented in Java (Spring-style controllers) under hcp-modules/hcp-mp. The vulnerable handler, PayController.xcxRecharge (referenced lines 18-28 of com/hcp/mp/controller/PayController.java in the roinli/HUIZHI-ChargeOS-cloud repository), accepts amount and userId parameters from the request body and performs no check that the caller is authorized to act on that userId, which places it squarely in CWE-639, Authorization Bypass Through User-Controlled Key, i.e. an insecure direct object reference on the wallet object. Because the operation credits or debits a monetary balance, the failure is an integrity defect rather than a disclosure or availability defect: the published CVSS 4.0 vector shows AV:N/AC:L/AT:N/PR:L/UI:N and only VI:H, while the independent CVSS 3.1 assessment mirrors this as S:U/C:N/I:H/A:N, confirming no confidentiality or availability impact and no special attack requirements beyond a valid low-privilege account. The CPE cpe:2.3:a:roinli:huizhi-chargeos-cloud:*:*:*:*:*:*:*:* carries a wildcard version, consistent with the advisory stating that all cloud releases through 3.0.9 are affected and that no fixed release has been identified.
Know when Huizhi Chargeos Cloud gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Network-reachable endpoint, low complexity, requires a low-privilege member account (PR:L), no UI; integrity high from arbitrary balance modification, with no direct confidentiality or availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
HUIZHI ChargeOS cloud through 3.0.9 contains a missing authorization vulnerability in the hcp-mp PayController.xcxRecharge endpoint that allows attackers to modify any member's wallet balance without payment. Attackers can send requests with arbitrary amount and userId parameters to credit or reduce balances and consume charging services for free.
Executive ViewAI
HUIZHI ChargeOS cloud through version 3.0.9 contains an authorization bypass in the hcp-mp PayController.xcxRecharge endpoint that allows an authenticated low-privilege member or mini-program account to arbitrarily credit or reduce any member's wallet balance without payment. This creates direct financial-integrity and revenue-loss exposure for charging operators and their customers, and the absence of a vendor patch means internet-exposed instances remain at risk. No public exploit identified at time of analysis, but the low-privilege authenticated attack path and wallet impact make containment and reconciliation a leadership priority.
No vendor-released patch identified at time of analysis; interim controls include disabling or network-restricting the xcxRecharge endpoint, enforcing server-side userId-to-session binding, adding WAF/API-gateway rules to reject mismatched userId values, monitoring and reconciling wallet balances, and applying emergency vendor workarounds if provided.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-102989
GHSA-g757-7gqj-36w5
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB