---
id: CVE-2026-88255
title: >-
  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 …
summary: >-
  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 …
severity: medium
cvss: 6.3
cvssVector: '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'
cwe:
  - CWE-1289
vendor: ZenHive
product: mpp
affected:
  - mpp >= 0.2.0 < 0.16.2
  - >-
    zenhive/mpp >= f8904666061fbab695874856d8fcd02c471dfe1b <
    e12bd4a1cea2e97c2a01fc059c48e5594a7b4a43
published: '2026-09-16'
updated: '2026-09-16'
sourceUpdated: '2026-09-16T20:38:33.883'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-88255'
references:
  - url: 'https://cna.erlef.org/cves/CVE-2026-88255.html'
    label: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
  - url: >-
      https://github.com/ZenHive/mpp/commit/e12bd4a1cea2e97c2a01fc059c48e5594a7b4a43
    label: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
  - url: >-
      https://github.com/ZenHive/mpp/commit/f8904666061fbab695874856d8fcd02c471dfe1b
    label: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
  - url: 'https://github.com/ZenHive/mpp/security/advisories/GHSA-8x7x-5j8g-8hcx'
    label: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
  - url: 'https://osv.dev/vulnerability/EEF-CVE-2026-88255'
    label: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
tags:
  - nvd
  - cve.org
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-09-16T14:49:50.266563Z'
cvssSource: cna
ingestedAt: '2026-09-16T08:52:29.601Z'
epss: 0.00524
epssPercentile: 0.42114
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.