CVE-2026-73136 is an authentication bypass by capture-replay in the ZenHive mpp Erlang package. When a static memo is configured for Tempo, the per-challenge binding is skipped, so an attacker can replay a stranger's settled transfer to get paid resources. The record scores it 7.5, High. Upgrade mpp to 0.6.4.
What's affected
The GitHub advisory lists the mpp Erlang package as affected up to and including 0.6.3, with 0.6.4 as the patched version. The record names the product as ZenHive machine_payments_protocol and does not list versions, so rely on the advisory for the range.
Only some deployments are exposed. The advisory says the issue applies where a server configures a static memo value in the Tempo method configuration, which is a documented option. Normally, MPP.Methods.Tempo binds a settled transfer to the specific challenge using an attribution nonce carried in the memo. With a static memo, that binding is bypassed, and matching uses only token, recipient, amount and the static memo value. The static memo is repeated in every unauthenticated 402 response, and Tempo transfers are public, so an attacker can take a matching transfer paid by a real customer, request a fresh challenge, and present that transaction hash as a credential. The hash path does not tie the presenter to the sender wallet.
The weakness class is CWE-294, authentication bypass by capture-replay.
How to check if you're exposed
Find out whether your service uses the mpp package, and which version.
mix deps | grep mpp
grep '"mpp"' mix.lock
If the locked version is 0.6.3 or lower, you are in the affected range. Then read your Tempo method configuration and look for a static memo setting. If you do not set one, the advisory says the exposure does not apply to your configuration, though you should still upgrade.
The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for the packages it finds.
What to do now
- Upgrade mpp to 0.6.4 or later and rebuild your release.
- If you cannot upgrade yet, remove the static memo from the Tempo method configuration so verification falls back to the per-challenge attribution binding.
- If you must keep a static memo, configure a dedup store with a time to live at least as long as the challenge expiry. The advisory says this reduces unlimited replay to a race on the transaction hash and does not close it.
- Review access logs for paid routes that were served for transaction hashes you saw more than once.
- Reconcile paid resource delivery against actual payments for the period before the fix.
- Plan to move away from static memos where per-challenge binding will work.
Why it matters
A payment gate has to prove that the person asking for a resource is the person who paid for it. A public transfer record alone proves that someone paid. If the server matches only on amount and a fixed memo, any observer can claim the payment as their own.
The sources differ slightly on scoring. The record gives 7.5 High under CVSS 3.1 with integrity impact only. The CNA page for the Erlang Ecosystem Foundation rates it High at 8.2, and the GitHub advisory labels it High. The scale differs, the direction does not. The workaround is notable because it removes the setting that causes the weakness, instead of adding a control around it. No source says the flaw has been exploited in the wild, and the CVE is not on the CISA KEV list.
Quick check
Which deployments are exposed?
Those that configure a static memo in the Tempo method configuration, per the advisory.
What is the lasting fix?
Upgrade mpp to 0.6.4. The advisory also lists removing the static memo as a workaround.
Sources
Last reviewed: 18 October 2026.
