Skip to main content

ZenHive mpp CVE-2026-73541

| EUVDEUVD-2026-62593 HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-08-19 EEF GHSA-j5gr-9qmc-3234
8.3
CVSS 4.0 · Vendor: EEF
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Identify mpp-powered sponsor endpoint
  2. Delivery
    Generate N distinct signed transactions with unique nonces
  3. Exploit
    Submit transactions concurrently to the sponsor API
  4. Execution
    Each request accepted under per-transaction policy checks
  5. Persist
    Aggregate committed exposure exceeds wallet balance
  6. Impact
    Sponsor 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

mpp 0.2.0 <0.12.0
mpp d29d54e507918db00a5b65d90136b73166c017d7 <ddc46868fba57ccebb567c04709812b466123076

Affected Packages

euvd mpp fix: 0.12.0

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

Vendor (EEF) PRIMARY 8.3 HIGH
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
vuln.today AI 9.1 CRITICAL

Network-reachable, no auth or complexity once sponsor feature enabled; wallet drain is both integrity and availability High; scope unchanged.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

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

Why It Matters

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.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.4%
Top 65% exploitable
Prevalence
Rare
niche Elixir blockchain library, small ecosystem footprint
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GitHub VulDB

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Total

Priority Score

42
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +42
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in Mpp

View all
CVE-2026-82750 HIGH POC
8.3 Sep 06

Missing validation of the EIP-7702 aa_authorization_list field in ZenHive mpp's Tempo payment sponsorship module allows

CVE-2026-82751 HIGH POC
8.3 Sep 06

Gas-cost inflation and unauthorized access key provisioning in ZenHive mpp (versions 0.2.0 through 0.15.x) allows any un

CVE-2026-67581 HIGH
8.7 Aug 19

Replay of settled EVM blockchain transaction hashes against ZenHive mpp versions 0.3.0-0.6.2 allows unauthenticated remo

CVE-2026-59694 HIGH
8.3 Jul 17

Economic resource exhaustion in the ZenHive mpp Elixir library (versions 0.2.0 through 0.5.x) lets an unauthenticated re

CVE-2026-59695 HIGH
8.3 Jul 17

Fee-payer wallet draining in ZenHive mpp (Elixir) 0.2.0-0.5.x lets an unauthenticated remote client empty the sponsor's

CVE-2026-73136 HIGH
8.2 Aug 19

Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to cla

CVE-2026-59252 HIGH
8.2 Jul 17

Wallet-draining denial of service in ZenHive mpp (Elixir library) versions 0.2.0 through 0.5.x affects deployments confi

CVE-2026-87119 HIGH
8.2 Sep 22

Replay of a captured Tempo subscription credential in ZenHive mpp 0.14.0 through 0.16.1 lets an attacker who already hol

CVE-2026-89420 HIGH
7.1 Sep 22

ZenHive mpp versions 0.14.0 through 0.16.1 fail to charge clients that hold an open payment channel, allowing an authent

CVE-2026-88255 MEDIUM
6.3 Sep 16

Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unau

CVE-2026-89186 MEDIUM
6.3 Sep 16

ZenHive mpp (MPP.Plug payment middleware for Elixir/Phoenix) versions 0.1.0 through 0.16.1 can allow a shared HTTP cache

CVE-2026-73829 MEDIUM
6.3 Aug 19

Payment-replay protection in ZenHive mpp's Tempo hash-credential path is defeated by a TOCTOU race condition, allowing a

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy