CVE-2026-73829: Non-atomic hash-credential dedup in mpp Tempo allows replay of a confirmed payment under a concurrent race
Time-of-check Time-of-use (TOCTOU) Race Condition in ZenHive mpp allows an unauthenticated remote client to redeem one confirmed on-chain payment for multiple paid-resource accesses.
The type="hash" credential path in MPP.Methods.Tempo.verify/2 guards against replay with a non-atomic check-then-mark sequence: checkhashunused/2 reads the dedup store, an ethgetTransactionReceipt round trip verifies the payment on chain, and only then does markhashused/2 write the mark. Concurrent requests carrying the same settled payment hash all pass the read before any of them writes, so each is issued a receipt. The store's atomic checkandmark/2 primitive is available and used by the type="transaction" path, but the hash path calls plain get and put even when the configured store implements it. Exploitation requires a dedup store to be configured; the default nil store is stateless and documented as offering no replay protection at all.
This issue affects mpp: from 0.2.0 before 0.6.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
mpp (Tempo)to a version that resolves this vulnerability.Fixed in 0.6.1 - Compensating control
Ensure the configured dedup store provides atomic replay protection using an atomic check-and-mark primitive (e.g., check_and_mark/2); avoid stateless/default nil dedup store because it provides no replay protection at all.
Event History
Frequently Asked Questions
Which deployments are affected by the concurrent replay issue?
Affected deployments use mpp versions from 0.2.0 before 0.6.1, have a dedup store configured, and accept type="hash" credentials through the Tempo verification path.
Is a deployment using the default dedup-store configuration protected?
No. The default nil store is stateless and provides no replay protection at all, although the specific check-then-mark race requires a configured dedup store.
What does an attacker need to exploit the race?
An unauthenticated remote client needs a confirmed on-chain payment hash and must submit concurrent requests using that same settled payment. Multiple requests can pass the unused-hash check before any request records the hash as used.
How can I determine whether my service uses the vulnerable path?
Check whether the deployment accepts type="hash" credentials and whether its configured mpp version is earlier than 0.6.1. The type="transaction" path uses the store's atomic check_and_mark/2 primitive, while the hash path uses separate read and write operations.