Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify mpp server in fee-payer mode
-
DeliveryCraft 0x76 envelope with inflated gas ceilings
-
ExploitClient-sign and submit single request
-
ExecutionServer co-signs and broadcasts
-
PersistOn-chain effective_gas_price bills sponsor wallet
-
ImpactFee-payer wallet drained, sponsorship halted
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V2 - Validation and Business Logic Input size validation
|
| Exploitation Conditions | The server must be deployed as a Tempo gas fee payer (fee_payer: true) so that MPP.Tempo.Transaction.cosign_fee_payer/3 co-signs client-supplied envelopes - this is the AT:P attack requirement and the single decisive precondition; instances without fee-payer/sponsorship enabled are not affected. Given that mode, no authentication is required (PR:N) and no user interaction is needed (UI:N): a remote client simply submits one 0x76 AASigned envelope carrying oversized max_fee_per_gas / max_priority_fee_per_gas fields. Limiting factors are the non-default deployment (must be an active gas sponsor), the affected version window (0.2.0 through 0.5.x, fixed in 0.6.0), and that the fee-payer wallet must hold a spendable balance for loss to occur. |
| Impact | This is a genuine high-priority risk for anyone running mpp in fee-payer mode, though its blast radius is bounded by that configuration. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VI:H/VA:H) correctly captures network-reachable, unauthenticated, low-complexity exploitation with an attack requirement (AT:P) - the server must be deployed as a fee payer - and impact that is integrity/availability (funds spent, sponsorship service exhausted) rather than confidentiality. Note the input Tags label this 'Information Disclosure,' which is inaccurate: nothing is disclosed; the impact is financial loss and denial of the sponsorship service (VC:N in the vector confirms this). No EPSS score and no KEV/POC signals were provided, so exploitation probability cannot be quantified numerically; the low-complexity, unauthenticated, single-request nature means weaponization would be trivial if any actor targeted an exposed fee-payer deployment. The main limiting factor is prevalence and configuration - only fee_payer: true instances are exploitable, and mpp is a niche library - so treat this as a critical fix for the small population of affected operators rather than a broad internet-wide event. |
| Exploit ScenarioDerived | An attacker discovers an mpp server running in fee-payer mode, crafts a 0x76 AASigned envelope embedding astronomically high max_fee_per_gas / max_priority_fee_per_gas values, signs it as the client, and submits a single payment request. The server co-signs and broadcasts it, the on-chain effective_gas_price bills the inflated rate against the server's wallet, draining it in one transaction and halting gas sponsorship for all legitimate users. No exploit code is publicly identified, but the low-complexity, unauthenticated network vector makes this trivial to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 17, 2026
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.
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.
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
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.
Know when Mpp 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:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
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
DescriptionCVE.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.
Executive ViewAI
ZenHive mpp (Elixir) versions 0.2.0 through 0.5.x contain a vulnerability that enables unauthenticated attackers to drain sponsor wallets and disable payment-processing services. Organizations running this library in fee-sponsorship mode face immediate financial loss and service disruption, impacting customer transactions. A vendor patch (version 0.6.0) is available and should be deployed immediately.
Apply vendor patch.
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
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
Economic resource exhaustion in the ZenHive mpp Elixir library (versions 0.2.0 through 0.5.x) lets an unauthenticated re
Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to cla
Wallet-draining denial of service in ZenHive mpp (Elixir library) versions 0.2.0 through 0.5.x affects deployments confi
Replay of a captured Tempo subscription credential in ZenHive mpp 0.14.0 through 0.16.1 lets an attacker who already hol
ZenHive mpp versions 0.14.0 through 0.16.1 fail to charge clients that hold an open payment channel, allowing an authent
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
EUVD-2026-45158
GHSA-6v7f-h3qg-wwpp
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB