Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify mpp-powered sponsor endpoint
-
DeliveryGenerate N distinct signed transactions with unique nonces
-
ExploitSubmit transactions concurrently to the sponsor API
-
ExecutionEach request accepted under per-transaction policy checks
-
PersistAggregate committed exposure exceeds wallet balance
-
ImpactSponsor wallet drained, legitimate users denied service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the target mpp deployment is configured with fee_payer_url to enable hosted fee-payer sponsorship (the Tempo pipeline with the fee_payer_policy block active). This is not a default condition - an operator must explicitly enable and configure sponsored transactions. Once that feature is enabled, exploitation requires no authentication (PR:N per the CVSS vector) and no user interaction; the attacker needs only network access to the sponsored-transaction endpoint and the ability to generate multiple distinct signed transactions (distinct hashes, distinct nonces) within the 900-second validity window. Exploitation is limited to deployments using mpp 0.2.0 through 0.11.x with hosted sponsorship enabled; mpp deployments that do not use the fee_payer_url sponsorship feature are not affected. There is no constraint on the attacker's transaction content beyond validity under the per-transaction fee policy. |
| Impact | The CVSS 4.0 score of 8.3 is well-founded and not inflated. The vector AV:N/AC:L/AT:P/PR:N/UI:N reflects that exploitation is network-accessible, requires no privileges, and involves no user interaction, but the AT:P attack requirement correctly captures that the sponsor feature must be configured and active - this is not a default-on condition for arbitrary mpp deployments. Integrity (VI:H) and availability (VA:H) impacts are both severe: a drained fee-payer wallet simultaneously destroys the financial integrity of the sponsorship service and denies legitimate users access to sponsored transactions for the duration of the 900-second validity window per wave of attack transactions. There is no confidentiality impact. No EPSS data or KEV listing was present in the input, meaning this is not confirmed as actively exploited by CISA. The attack is low-complexity once the sponsor endpoint is reachable, making it a genuine priority for any deployment using mpp's hosted sponsorship functionality, despite the absence of public exploit code. |
| Exploit ScenarioDerived | An attacker discovers a public-facing mpp-powered API endpoint configured for hosted fee-payer sponsorship, such as a DeFi relay or gas-abstraction service. The attacker submits hundreds of concurrent sponsored transaction requests, each with a distinct nonce, all valid under the per-transaction fee policy ceiling - each is individually accepted and committed against the sponsor wallet. Within the 900-second validity window, the cumulative committed exposure exceeds the wallet balance, causing the sponsor to become unable to fund legitimate transactions until the in-flight commitments expire. No public exploit code is known at time of analysis, but the attack requires only the ability to generate distinct signed transactions and issue concurrent HTTP requests. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 19, 2026
Concurrent sponsored-payment flooding in ZenHive mpp (versions 0.2.0 through 0.12.0) allows an unauthenticated remote client to drain a fee-payer wallet to zero, denying service to all legitimate sponsored-transaction users once the wallet is empty. The root cause is that MPP.Methods.Tempo.FeePayerPolicy enforces per-transaction budget ceilings but maintains no aggregate accounting across concurrent in-flight sponsorships, meaning N simultaneous sponsored requests commit N × max_total_fee against the wallet with no global cap. No public exploit has been identified at time of analysis, but the attack is mechanically trivial once the sponsor endpoint is reachable - no authentication, no cryptographic preconditions, only the ability to issue distinct signed transactions with distinct nonces within the 900-second validity window.
RemediationAI
Upgrade mpp to version 0.12.0 or later, which introduces the max_in_flight_total_fee and max_in_flight_reservations controls in fee_payer_policy and requires selection of an atomic store (ConCacheStore or equivalent shared-backend store for multi-node deployments). The vendor advisory is at https://github.com/ZenHive/mpp/security/advisories/GHSA-j4j7-7xpr-c7cr and the patch commit is at https://github.com/ZenHive/mpp/commit/ddc46868fba57ccebb567c04709812b466123076. If an immediate upgrade is not possible, operators should disable the hosted sponsorship endpoint (remove fee_payer_url from the Tempo pipeline configuration) to eliminate the attack surface entirely - this prevents legitimate sponsored transactions as well, so it is a service-impacting workaround. Rate-limiting at the network or application gateway layer (e.g., restricting the number of concurrent connections per IP to the sponsored endpoint) can reduce but not eliminate the risk, since an attacker using multiple source IPs would bypass per-IP throttling. No partial fix short of the 0.12.0 upgrade addresses the root aggregate-accounting gap.
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 library (cpe:2.3:a:zenhive:mpp) that implements Meta Payment Protocol, providing sponsored blockchain transaction infrastructure - including fee-payer policies used by hosted sponsor wallets. The vulnerable component is MPP.Methods.Tempo.FeePayerPolicy, which validates per-transaction parameters (max_gas, max_fee_per_gas, max_priority_fee_per_gas, and a worst-case gas_limit × max_fee_per_gas total-fee budget cap) and a 900-second validity window. The internal deduplication primitive reserve_hash_atomic/2 is keyed on the transaction hash, which prevents replay of the exact same signed transaction but does nothing to bound the total number of distinct sponsored transactions in flight simultaneously. CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes the flaw: the library allocates sponsor wallet exposure for each accepted transaction without any global ceiling on concurrent commitments. The fix, delivered in commit ddc46868, introduces two new fee_payer_policy fields - max_in_flight_total_fee and max_in_flight_reservations - along with a new sponsor_capacity_exhausted error (HTTP 402) with a Retry-After backoff signal, and mandates an explicitly selected atomic store (e.g., ConCacheStore) to safely track in-flight state across concurrent requests.
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-reachable, no auth or complexity once sponsor feature enabled; wallet drain is both integrity and availability High; scope unchanged.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
DescriptionCVE.org
Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.
MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.
This issue affects mpp: from 0.2.0 before 0.12.0.
Executive ViewAI
ZenHive mpp versions 0.2.0 through 0.12.0 contain a wallet-draining vulnerability that allows unauthenticated attackers to exhaust sponsored-transaction fee balances and deny service to legitimate payment users. Organizations relying on ZenHive mpp for fee sponsorship face immediate financial and operational risk, as attackers can trivially deplete fee-payer wallets without credentials, blocking all subsequent sponsored transactions. Any system with internet-accessible sponsored-payment endpoints using affected versions requires urgent patching to prevent service disruption and financial depletion.
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
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
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
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-62593
GHSA-j5gr-9qmc-3234
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB