CVE-2026-73541 is a resource exhaustion flaw (CWE-770) in ZenHive mpp, an Elixir library for machine payments. With fee sponsorship on, concurrent requests can drain the fee-payer wallet. The record rates it High at 8.2. The advisory lists 0.12.0 as patched, so upgrade.
What's affected
The GitHub advisory (GHSA-j4j7-7xpr-c7cr) lists 0.12.0 of the mpp package as patched. The record does not give a version range, so treat anything earlier as affected and confirm with the advisory.
Only some deployments are in scope. The advisory says servers that enable Tempo server-side fee sponsorship are affected, either with a local co-signing key or a hosted fee payer URL. Servers with fee_payer disabled, which is the default, are unaffected.
Severity, as two sources state it. The record gives 8.2 (High) under CVSS 3.1. The Erlang Ecosystem Foundation CNA page for the CVE lists it as High at 8.3. Both are High, so the practical advice does not change.
How to check if you're exposed
Check which version your Elixir application resolved, and whether sponsorship is enabled.
mix deps | grep -A2 mpp
grep -rn "fee_payer" config lib
If the library is at a version earlier than 0.12.0 and your method configuration sets fee_payer to true, you are in the affected group. Also check the balance and recent outgoing activity of the sponsoring wallet. A wallet that empties faster than your traffic explains is a sign worth investigating.
What to do now
- Upgrade
mppto 0.12.0 or later and rebuild your release. - If you cannot upgrade now, turn off fee sponsorship or put a rate limit and a concurrency limit in front of the payment endpoint.
- Keep the sponsoring wallet funded with only what you expect to spend, not a large reserve.
- Alert on wallet balance and on sponsored transaction counts per minute.
- Review other payment endpoints that spend your own funds for the same gap.
Why it matters
The weakness is allocation of resources without limits, CWE-770. The advisory describes a policy that enforces five ceilings on each transaction: gas, fee per gas, priority fee, a worst case budget and a validity window. Every one of those bounds applies to a single transaction. Nothing tracks the total exposure across requests that arrive at the same time, and the duplicate check is keyed on the transaction hash, so it stops the same signed transaction being sent twice but not many different ones.
This is a common design miss: per-request limits look strict, but an attacker who can open many requests at once multiplies the allowed spend. When code spends money, the budget has to be shared state with a ceiling. The harm here is denial of service for legitimate payers once the wallet is empty, plus the direct financial loss. KEV status is false.
Quick check
Who is at risk?
Operators who sponsor transaction fees on the Tempo method. Servers that leave fee_payer off are unaffected, according to the advisory.
Does the per-transaction budget cap protect me?
No. That cap applies to one transaction at a time. The flaw is that nothing limits many sponsored transactions arriving together.
Sources
Last reviewed: 18 October 2026.
