EEF-CVE-2026-73541
Tempo fee sponsorship in mpp bounds each transaction but not aggregate exposure, allowing concurrent sponsor-wallet drain
Quick fix
EEF-CVE-2026-73541 — mpp: upgrade to the fixed version with the command below.
mix deps.update mpp Details
## Summary
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.
## Workaround
Disable Tempo fee sponsorship by setting "fee\_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max\_total\_fee and max\_validity\_window\_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.
## Configuration
Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee\_payer" => true in method\_config with either local co-signing (fee\_payer\_private\_key) or hosted sponsorship (fee\_payer\_url). Sponsorship is disabled by default.
Are you affected?
Enter the version of the package you're using.