CVE-2026-73541: Tempo fee sponsorship in mpp bounds each transaction but not aggregate exposure, allowing concurrent sponsor-wallet drain
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 (maxgas, maxfeepergas, maxpriorityfeepergas, the worst-case gaslimit maxfeepergas <= maxtotalfee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reservehashatomic/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 maxtotalfee, 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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to sponsor-wallet draining?
Deployments using mpp versions from 0.2.0 before 0.12.0 are affected when they use MPP.Methods.Tempo.FeePayerPolicy to sponsor transaction fees. An unauthenticated remote client can submit concurrent distinct sponsored transactions and exhaust the fee-payer wallet.
What does an attacker need to bypass the per-transaction fee limits?
The attacker needs multiple distinct sponsored transactions with distinct expiring nonces. The existing atomic reservation is keyed by transaction hash, so it blocks repeat broadcasts of the same signed transaction but does not aggregate exposure across different transaction hashes.
Are default settings relevant to exploitation?
Yes. The default validity window is 900 seconds, allowing co-signed transactions to remain broadcastable and uncounted for that period. During that window, concurrent committed exposure can grow to N times the configured max_total_fee without a library-enforced aggregate bound.
What is the impact after the sponsor wallet is depleted?
Legitimate payers can be denied service once the fee-payer wallet is empty. The per-transaction ceilings still apply, but they do not limit the total amount committed across concurrent requests.