{"id":"CVE-2026-88255","aliases":["EEF-CVE-2026-88255","EUVD-2026-80256","GHSA-8x7x-5j8g-8hcx","GHSA-p7v4-jpp9-2m3q"],"status":"published","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","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","severity":{"version":"4.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","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00524,"percentile":0.44885,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1289"],"published":"2026-09-16T08:24:40Z","modified":"2026-10-28T02:30:55Z","fixes":[{"ecosystem":"Hex","package":"mpp","fixed_in":["0.16.2"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"mpp","ranges":[{"type":"SEMVER","events":[{"introduced":"0.2.0"},{"fixed":"0.16.2"}]}],"versions":["0.10.0","0.11.0","0.12.0","0.13.0","0.14.0","0.15.0","0.16.0","0.16.1","0.2.0","0.3.0","0.3.1","0.3.2","0.4.0","0.6.0","0.6.1","0.6.2","0.6.3","0.6.4","0.7.0","0.8.0","0.9.0"]}],"products":[{"vendor":"zenhive","product":"mpp"}],"references":[{"url":"https://github.com/ZenHive/mpp/security/advisories/GHSA-8x7x-5j8g-8hcx","tags":["related","vendor-advisory","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-88255.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-88255","tags":["related","web"]},{"url":"https://github.com/ZenHive/mpp/commit/f8904666061fbab695874856d8fcd02c471dfe1b","tags":["related","fix","web"]},{"url":"https://github.com/ZenHive/mpp/commit/e12bd4a1cea2e97c2a01fc059c48e5594a7b4a43","tags":["patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-88255","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-p7v4-jpp9-2m3q"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/88xxx/CVE-2026-88255.json","tags":["advisory"]},{"url":"https://github.com/ZenHive/mpp","tags":["package"]},{"url":"https://hex.pm/packages/mpp","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-88255","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","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","status":"published","published":"2026-09-16T08:24:40.446Z","modified":"2026-09-16T14:49:57.782Z","cvss":[{"version":"4.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","level":"medium","assessor":"cna"}],"cwes":["CWE-1289"],"updated_at":"2026-11-02T13:41:53.237769Z"}],"euvd":[{"id":"EUVD-2026-80256","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","status":"published","published":"2026-09-16T08:24:40Z","modified":"2026-09-16T14:49:57Z","cvss":[{"version":"4.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","level":"medium"}],"updated_at":"2026-11-02T17:28:15.854171Z"}],"ghsa":[{"id":"GHSA-p7v4-jpp9-2m3q","title":"Improper Validation of Unsafe Equivalence in Input in ZenHive mpp allows an unauthenticated...","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","status":"published","published":"2026-09-16T09:30:29Z","modified":"2026-09-16T09:30:36Z","cvss":[{"version":"4.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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"}],"cwes":["CWE-1289"],"updated_at":"2026-11-02T15:11:57.71972Z"}],"nvd":[{"id":"CVE-2026-88255","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","status":"published","published":"2026-09-16T09:17:07.333Z","modified":"2026-09-16T20:38:33.883Z","cvss":[{"version":"4.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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-1289"],"updated_at":"2026-11-02T14:12:48.287983Z"}],"osv":[{"id":"CVE-2026-88255","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","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.\n\nMPP.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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.","status":"published","published":"2026-09-16T08:24:40.446Z","modified":"2026-10-28T02:30:55.089080085Z","cvss":[{"version":"4.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","level":"medium"}],"cwes":["CWE-1289"],"updated_at":"2026-11-02T15:45:19.210277Z"},{"id":"EEF-CVE-2026-88255","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","description":"## Summary\n\nImproper 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.\n\n`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.\n\nWhat 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.\n\nThis issue affects mpp: from 0.2.0 before 0.16.2.\n\n## Impact\n\nA client re-encodes the recovery id of a transaction it has already submitted and presents it again. The duplicate passes the only duplicate-submission gate the Tempo method has, and against a node that answers with the canonical hash for an already-known transaction the client is issued a second `Payment-Receipt` for one on-chain payment.\n\n## Configurations\n\nReachable when `MPP.Methods.Tempo` broadcasts a `type=\"transaction\"` credential with a dedup store in place. From mpp 0.7.0 the dedup store is on by default (the app-started `MPP.Tempo.ConCacheStore`; opt out with `store: false`), so every default Tempo deployment from 0.7.0 before 0.16.2 is affected. Before 0.7.0 the default store was `nil`, which runs the library statelessly and provides no application-level replay protection at all, a documented property rather than part of this issue; those versions are affected only where a `\"store\"` was configured explicitly in `method_config`.","status":"published","published":"2026-09-16T08:24:40.446Z","modified":"2026-09-16T08:40:58.847428916Z","cvss":[{"version":"4.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","level":"medium"}],"cwes":["CWE-1289"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}