Vulnerability · Published Sep 16, 2026 · Assigned by EEF
CVE-2026-88255mpp Tempo keys its pre-broadcast dedup reserve on the caller-supplied transaction encoding, so a re-encoded signed transaction reserves a second slot
Medium 6.3
In plain English
A medium-severity security flaw in mpp from ZenHive. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.5% (higher than 45% of all known vulnerabilities).
Official description
Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated remote client to pass the Tempo duplicate-submission gate twice with one signed transaction. MPP.Methods.Tempo reserves the pre-broadcast dedup slot on the caller-supplied hex in reserve_hash_atomic/2, keyed through store_key/1 on tx.raw rather than on a canonical form of the transaction. The deserializer stores the caller's hex verbatim and accepts both recovery-id encodings, so one signed transaction submitted once with v=27 and once with v=0 yields two distinct reserve keys, and both pass the reserve and reach the broadcast path. The plug-level credential replay store is deliberately carved out for tempo in lib/mpp/replay.ex, leaving this reserve as the only gate, and the post-broadcast mark writes the canonical hash key that the raw-keyed reserve never reads. What the duplicate submission yields depends on the node: a nonce-reuse rejection fails closed, while a node that answers with the canonical hash for an already-known transaction returns a second valid Payment-Receipt for a single on-chain payment. This issue affects mpp: from 0.2.0 before 0.16.2.
Affected products (as reported)
Weakness: CWE-1289 · Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
References
- GitHub Advisory related, vendor-advisory
- EEF CNA record for CVE-2026-88255 related
- OSV record EEF-CVE-2026-88255 related
- Introducing commit f890466 in ZenHive/mpp related
- Fix commit e12bd4a in ZenHive/mpp patch