CVE-2026-73541: ZenHive MPP DOS Vulnerability

CVE-2026-73541 Overview

CVE-2026-73541 is a resource exhaustion vulnerability in the ZenHive mpp library affecting versions from 0.2.0 before 0.12.0. The flaw resides in MPP.Methods.Tempo.FeePayerPolicy, which enforces per-transaction ceilings but does not account for aggregate exposure across concurrent sponsored payment requests. An unauthenticated remote client can submit many distinct sponsored transactions in parallel, each individually passing policy checks, and drain the fee-payer wallet. Once emptied, the wallet cannot underwrite legitimate payers, producing a denial-of-service condition. The vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
An unauthenticated network attacker can exhaust the sponsor wallet by broadcasting N concurrent sponsored transactions, each carrying distinct expiring nonces, denying service to all subsequent legitimate payers.

Affected Products

ZenHive mpp versions 0.2.0 through 0.11.x
MPP.Methods.Tempo.FeePayerPolicy module
Applications embedding the mpp library for sponsored transaction handling

Discovery Timeline

2026-08-19 - CVE-2026-73541 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-73541

Vulnerability Analysis

The FeePayerPolicy module enforces ceilings on a per-transaction basis. These ceilings include max_gas, max_fee_per_gas, max_priority_fee_per_gas, a worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window. Nothing in the library aggregates committed sponsor exposure across concurrent requests. The result is that N valid sponsored transactions each pass individual policy checks while collectively committing N times max_total_fee from the fee-payer wallet.

Root Cause

The deduplication primitive reserve_hash_atomic/2 is keyed on the transaction hash. It prevents rebroadcast of an identical signed transaction but does not block N distinct sponsored transactions carrying distinct expiring nonces. The default 900-second validity window keeps co-signed transactions broadcastable and uncounted for that entire period, widening the concurrency window an attacker can exploit.

Attack Vector

An unauthenticated remote client crafts multiple sponsored payment requests, each with distinct nonces and expirations. Because each request satisfies the per-transaction ceilings and each hash is unique, reserve_hash_atomic/2 admits them all. The sponsor commits funds to each, and once the wallet is drained, subsequent legitimate sponsored payments fail. See the GitHub Security Advisory GHSA-j4j7-7xpr-c7cr for advisory-level detail.

text

* `:sponsor_capacity_exhausted` — fee sponsor capacity is temporarily unavailable (402)

Source: GitHub Commit ddc4686

The patch introduces a new error class :sponsor_capacity_exhausted returned as a payable 402 challenge, signaling that aggregate sponsor budget accounting is now enforced.

Detection Methods for CVE-2026-73541

Indicators of Compromise

Rapid, concurrent sponsored transaction submissions from a single client or IP range with distinct nonces
Sudden drop in fee-payer wallet balance without a matching increase in legitimate business activity
Elevated volume of 402 responses returned to downstream callers once the wallet is empty
Broadcasts clustered inside the default 900-second validity window

Detection Strategies

Instrument the mpp transport layer to log per-request sponsor commitments and correlate them against wallet balance deltas
Alert when the count of in-flight sponsored transactions exceeds a business-justified threshold
Baseline typical concurrency for sponsored payment endpoints and flag statistical outliers

Monitoring Recommendations

Track aggregate max_total_fee committed in any rolling 900-second window against remaining wallet balance
Monitor for the newly introduced :sponsor_capacity_exhausted (402) response and its retry_after delta-seconds signal
Forward sponsor wallet balance metrics and transport-layer telemetry to a centralized data lake for cross-source correlation and hunting

How to Mitigate CVE-2026-73541

Immediate Actions Required

Upgrade ZenHive mpp to version 0.12.0 or later, which introduces aggregate in-flight sponsor budget accounting
Set conservative wallet balances and rotate sponsor keys if unexplained drain events have already occurred
Rate-limit sponsored payment endpoints at the network edge until the upgrade is deployed

Patch Information

The fix is delivered in commit ddc46868fba57ccebb567c04709812b466123076, which adds aggregate in-flight sponsor budgets in lib/mpp/client/transport/http.ex and introduces the :sponsor_capacity_exhausted error in lib/mpp/errors.ex. Callers receive a payable 402 challenge and can consume the retry_after/1 backoff signal. See the CNA CVE-2026-73541 Listing and OSV Vulnerability Data EEF-CVE-2026-73541.

Workarounds

Shorten the sponsored transaction validity window well below the 900-second default to reduce the concurrent exposure window
Enforce an application-layer semaphore that caps concurrent sponsored transactions per client and globally
Cap the fee-payer wallet balance to the maximum acceptable single-incident loss and refill on demand
Require authentication or attestation before accepting sponsored payment requests where the protocol permits

bash

# Example: pin mpp to the fixed release in mix.exs
# {:mpp, "~> 0.12.0"}
mix deps.update mpp
mix deps.get