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.
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.
\nMPP.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.
"},{"base64":false,"type":"text/markdown","value":"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.\n\n`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.\n\nThis issue affects mpp: from 0.2.0 before 0.12.0."}],"value":"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.\n\nMPP.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.\n\nThis issue affects mpp: from 0.2.0 before 0.12.0."}],"impacts":[{"capecId":"CAPEC-130","descriptions":[{"lang":"en","value":"CAPEC-130 Excessive Allocation"}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":8.3,"baseSeverity":"HIGH","privilegesRequired":"NONE","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"HIGH","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-770","description":"CWE-770 Allocation of Resources Without Limits or Throttling","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-08-19T17:20:00.286Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"tags":["vendor-advisory","related"],"url":"https://github.com/ZenHive/mpp/security/advisories/GHSA-j4j7-7xpr-c7cr"},{"tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-73541.html"},{"tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-73541"},{"tags":["patch"],"url":"https://github.com/ZenHive/mpp/commit/ddc46868fba57ccebb567c04709812b466123076"}],"source":{"discovery":"EXTERNAL"},"title":"Tempo fee sponsorship in mpp bounds each transaction but not aggregate exposure, allowing concurrent sponsor-wallet drain","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"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.