ZenHive mpp CVE-2026-88255

Requires that the target deploys ZenHive mpp (0.2.0 to before 0.16.2) with the Tempo (MPP.Methods.Tempo) payment method reachable by remote clients, and that the credential replay store is carved out for Tempo (as it is by default in lib/mpp/replay.ex), leaving reserve_hash_atomic/2 as the only dedup gate. The attacker needs a single validly signed transaction and submits it twice using both accepted recovery-id encodings (v=27 and v=0) so store_key/1 on tx.raw yields two distinct keys. LIMITING FACTORS: no authentication or user interaction is needed (PR:N/UI:N), but success depends on downstream node behavior (AT:P) - the harmful double-receipt only occurs against a node that answers with the canonical hash for an already-known transaction, while a node that enforces nonce-reuse rejection fails closed and yields no impact. Impact is bounded to a duplicate Payment-Receipt for one on-chain payment; no confidentiality or availability loss.

This is a genuine but moderate-severity logic flaw, not a critical one, and the multi-source signals agree on that. The vendor CVSS 4.0 base score is 6.3 (Medium) with vector AV:N/AC:L/AT:P/PR:N/UI:N and impact confined to VI:L (low integrity) with VC:N/VA:N - i.e. no confidentiality or availability loss, only a bounded integrity/business-logic effect (a duplicate Payment-Receipt for a single on-chain payment). No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so exploitation is theoretical at this time. The AT:P (attack requirement) metric is well-justified: the description states the double-receipt outcome only materializes on a node that answers with the canonical hash for an already-known transaction, whereas a node enforcing nonce-reuse rejection fails closed - so real impact is conditional on backend/node behavior. The 'Information Disclosure' tag in the input directly conflicts with the CVSS impact metrics (VC:N - no confidentiality impact); this is an integrity/dedup-bypass issue, not disclosure, and the tag appears mislabeled. Overall this is a lower-priority Medium: real for operators running ZenHive mpp in a payment path, but not a widespread or actively-exploited threat.

An unauthenticated remote client crafts one validly signed Tempo transaction and submits it twice through the MPP payment flow - once encoded with recovery id v=27 and once with v=0. Because the pre-broadcast dedup reserve is keyed on the raw caller-supplied hex rather than a canonicalized transaction, the two encodings produce two distinct reserve keys that both pass the gate; against a node that returns the canonical hash for an already-known transaction, the attacker receives two valid Payment-Receipts for a single on-chain payment. No public exploit code is identified in the provided data.