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.
Advisories

No advisories yet.

Fixes

Solution

No solution given by the vendor.


Workaround

No workaround given by the vendor.

History

Wed, 16 Sep 2026 15:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Wed, 16 Sep 2026 15:00:00 +0000

Type Values Removed Values Added
First Time appeared Zenhive
Zenhive mpp
Vendors & Products Zenhive
Zenhive mpp

Wed, 16 Sep 2026 08:30:00 +0000

Type Values Removed Values Added
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.
Title mpp Tempo keys its pre-broadcast dedup reserve on the caller-supplied transaction encoding, so a re-encoded signed transaction reserves a second slot
First Time appeared Zenhive
Zenhive mpp
Weaknesses CWE-1289
CPEs cpe:2.3:a:ZenHive:mpp:*:*:*:*:*:*:*:*
Vendors & Products Zenhive
Zenhive mpp
References
Metrics cvssV4_0

{'score': 6.3, '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'}


Projects

Sign in to view the affected projects.

cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-09-16T14:49:57.782Z

Reserved: 2026-09-11T18:30:01.336Z

Link: CVE-2026-88255

cve-icon Vulnrichment

Updated: 2026-09-16T14:49:54.770Z

cve-icon NVD

Status : Received

Published: 2026-09-16T09:17:07.333

Modified: 2026-09-16T15:18:04.487

Link: CVE-2026-88255

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-16T14:45:05Z

Weaknesses