Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/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, unauthenticated, no UI; AC:H because exploitation requires the non-default fee_payer:true deployment precondition; no confidentiality impact, but fund-spend integrity (I:H) and sponsorship exhaustion (A:H).
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
3DescriptionCVE.org
Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet in a single request by naming an arbitrarily high gas price.
When the mpp Elixir library is configured as fee payer (fee_payer: true), MPP.Tempo.Transaction.cosign_fee_payer/3 re-signs the client-supplied base fields of the 0x76 AASigned envelope verbatim, including max_fee_per_gas and max_priority_fee_per_gas, without validating that they are within reasonable bounds. A malicious client embeds arbitrarily large values for these fields in the signed envelope. The server co-signs and broadcasts the transaction. The effective_gas_price billed against the fee-payer wallet is derived from the attacker-supplied ceilings, so the server pays those inflated per-gas rates out of its own wallet. A single crafted request can drain the wallet entirely, after which the server can no longer sponsor gas for legitimate payment requests.
This issue affects mpp: from 0.2.0 before 0.6.0.
AnalysisAI
Fee-payer wallet draining in ZenHive mpp (Elixir) 0.2.0-0.5.x lets an unauthenticated remote client empty the sponsor's wallet in a single request when the server runs with fee_payer: true. Because MPP.Tempo.Transaction.cosign_fee_payer/3 co-signs the client-supplied gas ceilings (max_fee_per_gas / max_priority_fee_per_gas) of the 0x76 AASigned envelope without bounds checking, an attacker sets arbitrarily large per-gas rates that are billed against the server's wallet, after which it can no longer sponsor legitimate payments. No public exploit identified at time of analysis; the issue was reported by the Erlang Ecosystem Foundation (EEF) and patched in 0.6.0.
Technical ContextAI
mpp is an Elixir server library implementing a machine/micro-payment protocol over the Tempo transaction format, where an EIP-1559-style AASigned envelope (type 0x76) carries gas economics fields including max_fee_per_gas and max_priority_fee_per_gas. In sponsored (gas-abstraction) mode the server acts as fee payer: it co-signs a client-signed transaction so the client's payment executes but the server's wallet pays the gas. The root cause is CWE-1284 (Improper Validation of Specified Quantity in Input): cosign_fee_payer/3 re-signs the client's base fields verbatim, trusting attacker-controlled quantities. The effective_gas_price charged on-chain is derived from those ceilings, so unbounded client input translates directly into unbounded spend from the sponsor wallet. The fix adds MPP.Methods.Tempo.FeePayerPolicy, which bounds gas_limit, the per-gas ceilings, a gas × max_fee_per_gas total-fee budget, rejects non-empty access lists, and requires an expiring nonce key plus a near-future valid_before within a max_validity_window_seconds (default 15 min). Affected CPE is cpe:2.3:a:zenhive:mpp.
RemediationAI
Vendor-released patch: upgrade mpp to 0.6.0 or later, which introduces MPP.Methods.Tempo.FeePayerPolicy and validates the client-signed 0x76 envelope's gas economics before co-signing (fix commit https://github.com/ZenHive/mpp/commit/5d6338e2334084c5f2a78cfcca474830733ed7e8; advisory https://github.com/ZenHive/mpp/security/advisories/GHSA-vv77-66rf-pm86). The 0.6.0 defaults are safe without configuration changes for existing fee_payer: true deployments, and you can tighten them further via method_config["fee_payer_policy"] to override max_gas, max_fee_per_gas, max_priority_fee_per_gas, max_total_fee (wei), and max_validity_window_seconds per chain. If you cannot upgrade immediately, disable sponsored mode by setting fee_payer: false (trade-off: clients must pay their own gas, breaking gas-abstraction UX), fund the fee-payer wallet with only a minimal balance and monitor/alert on balance drops to cap single-request loss, and restrict network access to the mpp endpoint to trusted callers. Note that even after upgrading, the related low-gas_limit revert drain (GHSA-vj8p-hp9x-gh47) is tracked separately and needs pre-broadcast simulation, so continue monitoring vendor advisories.
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
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
EUVD-2026-45158
GHSA-6v7f-h3qg-wwpp