CVE-2026-73136: Static memo configuration in mpp Tempo disables per-challenge attribution binding, enabling third-party replay
Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer.
MPP.Methods.Tempo normally binds a settled TIP-20 TransferWithMemo to the specific challenge under verification through an attribution nonce carried in the memo. When a static "memo" is configured in methodconfig, checkmatchedmemobinding/3 returns the match unconditionally and that binding is skipped, leaving only token, recipient, amount and the static memo value to match on. The static memo is echoed in every unauthenticated 402 response and Tempo transfers are public, so an attacker can take any matching transfer paid by a legitimate customer, request a fresh challenge for the same route, and present that transaction hash as a type="hash" credential. The hash path performs no sender or signature check tying the presenter to the wallet that broadcast the transfer.
This issue affects mpp: from 0.6.1 before 0.6.4.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ZenHive mppto a version that resolves this vulnerability.Fixed in 0.6.4 - Configuration
Do not configure a static "memo" in method_config for mpp Tempo. Static memo configuration disables per-challenge attribution binding (check_matched_memo_binding/3 matches unconditionally and skips binding). Configure Tempo so the settled TIP-20 TransferWithMemo is bound to the specific challenge under verification via the attribution nonce carried in the memo.
ZenHive mpp Tempo method_config (static memo configuration) memo = remove/disable static memo (use per-challenge memo with attribution nonce binding)
Event History
Frequently Asked Questions
Which deployments are exposed to this replay attack?
Affected deployments are mpp versions from 0.6.1 before 0.6.4 that use MPP.Methods.Tempo with a static "memo" configured in method_config. The static memo causes per-challenge attribution binding to be skipped.
What does an attacker need to exploit the issue?
The attacker needs a matching public Tempo transfer transaction hash from an unrelated legitimate payer, then requests a fresh challenge for the same route and submits that hash as a type="hash" credential. No control of the payer wallet, sender check, or signature is required on this path.
Are unauthenticated payment challenges relevant to exploitation?
Yes. Every unauthenticated 402 response echoes the static memo, allowing an attacker to obtain the value needed to identify or replay a matching transfer. Tempo transfers are public, making eligible transaction hashes observable.
How can operators determine whether they are affected?
Check whether the deployed mpp version is at least 0.6.1 and earlier than 0.6.4, and inspect Tempo method_config for a static "memo" value. If both conditions apply, hash-based credentials can be replayed across challenges when token, recipient, amount, and memo match.