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 mppDetails
## 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.
## Workarounds
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.
## Configurations
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.