CVE-2026-73541 in mpp
Summary
by MITRE • 08/19/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in ZenHive's Multi-Party Payment (MPP) module represents a critical failure in resource management, specifically categorized under CWE-400 as an Allocation of Resources Without Limits or Throttling. This flaw allows unauthenticated remote clients to exhaust the financial resources of a fee-payer wallet by exploiting concurrent sponsored payment requests. The core issue lies in the implementation of the Tempo.FeePayerPolicy module, which is designed to enforce spending ceilings such as max_gas, max_fee_per_gas, and max_priority_fee_per_gas. While these parameters establish theoretical limits on individual transaction costs, they are applied sequentially rather than concurrently. This architectural oversight means that when multiple distinct transactions are submitted simultaneously by different clients or the same client using nonces within a valid window, each request is evaluated against its own isolated limit without considering the aggregate exposure across all active requests. Consequently, the system fails to account for cumulative resource consumption, leading to a scenario where the total committed sponsor exposure can reach N times the max_total_fee budget cap, effectively bypassing the intended financial safeguards.
From an operational perspective, this flaw enables a denial of service attack against legitimate users who rely on the fee-payer wallet for sponsored transactions. Because the reserve_hash_atomic function is keyed solely on the transaction hash, it successfully prevents duplicate broadcasts of identical signed transactions but offers no protection against distinct transactions that carry different expiring nonces. This design choice allows attackers to flood the system with unique, valid-looking requests that each consume a portion of the fee-payer's balance. The default validity window of 900 seconds exacerbates this issue by allowing co-signed transactions to remain broadcastable and uncounted toward any running total for an extended period. During this window, an attacker can continuously submit new sponsored payments, draining the wallet until it is empty. Once the fee-payer's balance is depleted, legitimate users are unable to execute their intended operations, resulting in a complete service outage for those relying on the sponsorship mechanism.
This vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, where an adversary uses compromised or vulnerable systems to consume significant amounts of computing resources, often leading to denial of service conditions. In this specific context, the resource being hijacked is financial capital rather than CPU cycles or memory, but the impact on system availability and integrity remains severe. The lack of a global state mechanism to track cumulative spending across concurrent requests creates a race condition-like environment where the sum of individual valid transactions exceeds the total budget cap. This is particularly dangerous in decentralized finance environments where trustless execution relies heavily on accurate accounting of fees and gas limits.
The issue affects versions of ZenHive mpp from 0.2.0 up to, but not including, version 0.12.0. To mitigate this vulnerability, developers must implement a global counter or ledger that tracks the total committed exposure across all active sponsored transactions within the validity window. This mechanism should atomically check and update the remaining budget before allowing any new transaction to proceed, ensuring that the sum of max_total_fee for all concurrent requests does not exceed the defined cap. Additionally, reducing the default validity window from 900 seconds can help limit the duration during which uncounted transactions remain broadcastable, thereby reducing the attack surface and potential financial loss. Implementing rate limiting based on client IP or account ID could also provide an additional layer of defense against high-frequency concurrent requests designed to exploit this flaw.