EUVD-2026-84360
GHSA-96m7-5wfv-978m
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable and low-complexity, but the attacker must hold a funded payment channel (PR:L); impact is purely integrity of billing/accounting (I:H) with no confidentiality or availability loss.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
3DescriptionCVE.org
Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.
MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.
This issue affects mpp: from 0.14.0 before 0.16.2.
AnalysisAI
ZenHive mpp versions 0.14.0 through 0.16.1 fail to charge clients that hold an open payment channel, allowing an authenticated client to obtain an unbounded number of paid units from a single signed voucher. The flaw sits in MPP.Session.Actions.accept_voucher/3, which returns the channel unchanged when a voucher's cumulativeAmount equals the already-accepted cumulative amount, so the credential verifies, the protected resource is served, and no spend is recorded; because the server issues a fresh challenge per request and the replay store keys only on challenge id plus payload, the same voucher can be re-presented under every new challenge. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
No credit card · 7-day full trial
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the server to run mpp's session/channel payment 'intent' (session_store / MPP.Session.Method dispatch, versions 0.14.0 through 0.16.1) and the attacker to be an authenticated client who has already opened and funded a payment channel (hence PR:L). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) frames this accurately as a network-reachable, low-complexity, low-privilege integrity flaw with no confidentiality or availability impact - the 'high integrity' rating reflects that the server's payment/billing accounting can be defeated, not that data is exposed or the service crashes. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Vendor-released patch: upgrade mpp to 0.16.2 or later, which corrects the accept_voucher/3 short-circuit; the corresponding upstream fix is commit 7270edc1dcfb58250cc5ee812876609206564165 (accompanied by commit 82df569c898be1137189e3648e1edb4af6363651), and details are in the advisory at https://github.com/ZenHive/mpp/security/advisories/GHSA-8c63-r789-xrrf. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory every ZenHive mpp deployment and confirm whether it is running any version in the 0.14.0 through 0.16.1 range, covering all call paths that reach the payment layer (Plug, MCP, JSON-RPC and WebSocket transports), and restrict network reachability of those endpoints to trusted clients while preserving audit logging of voucher acceptance; also notify finance and billing owners that metered usage figures for this period may be understated. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Missing validation of the EIP-7702 aa_authorization_list field in ZenHive mpp's Tempo payment sponsorship module allows
Gas-cost inflation and unauthorized access key provisioning in ZenHive mpp (versions 0.2.0 through 0.15.x) allows any un
Replay of settled EVM blockchain transaction hashes against ZenHive mpp versions 0.3.0-0.6.2 allows unauthenticated remo
Concurrent sponsored-payment flooding in ZenHive mpp (versions 0.2.0 through 0.12.0) allows an unauthenticated remote cl
Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to cla
Economic resource exhaustion in the ZenHive mpp Elixir library (versions 0.2.0 through 0.5.x) lets an unauthenticated re
Fee-payer wallet draining in ZenHive mpp (Elixir) 0.2.0-0.5.x lets an unauthenticated remote client empty the sponsor's
Replay of a captured Tempo subscription credential in ZenHive mpp 0.14.0 through 0.16.1 lets an attacker who already hol
Wallet-draining denial of service in ZenHive mpp (Elixir library) versions 0.2.0 through 0.5.x affects deployments confi
Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unau
ZenHive mpp (MPP.Plug payment middleware for Elixir/Phoenix) versions 0.1.0 through 0.16.1 can allow a shared HTTP cache
Payment-replay protection in ZenHive mpp's Tempo hash-credential path is defeated by a TOCTOU race condition, allowing a
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today