CVE-2026-73136: ZenHive MPP Auth Bypass Vulnerability

CVE-2026-73136 Overview

CVE-2026-73136 is an authentication bypass by capture-replay vulnerability in ZenHive mpp, an Elixir library implementing the HTTP 402 Machine Payable Protocol. The flaw resides in MPP.Methods.Tempo, which verifies TIP-20 TransferWithMemo payments on the Tempo ledger. When operators configure a static memo in method_config, the binding between a settled transfer and the specific challenge is skipped. An unauthenticated attacker can replay any matching public transfer paid by a legitimate customer to obtain paid resources. The issue affects mpp from version 0.6.1 up to but not including 0.6.4 [CWE-294].

Critical Impact
An unauthenticated network attacker can obtain paid resources without payment by replaying another user's public Tempo transaction hash as their own type="hash" credential.

Affected Products

ZenHive mpp version 0.6.1
ZenHive mpp versions after 0.6.1 and before 0.6.4
Deployments configured with a static memo value in method_config

Discovery Timeline

2026-08-19 - CVE-2026-73136 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-73136

Vulnerability Analysis

The mpp library implements HTTP 402 payment challenges using TIP-20 TransferWithMemo transactions on the Tempo ledger. Under normal operation, MPP.Methods.Tempo binds each settled transfer to a specific challenge through an attribution nonce carried in the transfer memo. This binding prevents one payment from satisfying an unrelated challenge.

When operators configure a static memo in method_config, the function check_matched_memo_binding/3 unconditionally returns a positive match. The per-challenge nonce check is skipped entirely. Verification then collapses to matching only the token, recipient, amount, and the static memo value.

Because the static memo is echoed in every unauthenticated HTTP 402 response and Tempo transfers are publicly observable, an attacker can locate any matching transfer paid by a legitimate customer. The attacker then requests a fresh challenge for the same route and presents that public transaction hash as a type="hash" credential.

Root Cause

The hash verification path in MPP.Methods.Tempo performs no sender or signature check that ties the presenter to the wallet that broadcast the transfer. Combined with the skipped memo-binding check under static-memo configurations, ownership of a payment is never validated.

Attack Vector

An unauthenticated remote attacker monitors public Tempo transfers matching the static memo, token, recipient, and amount. The attacker requests a challenge for the target route, submits the observed transaction hash as a hash credential, and receives the paid resource. No wallet control or signature is required.

text

// Patch excerpt from lib/mpp/methods/tempo.ex
     validate_memo!(config["memo"])
     validate_store!(config["store"])
+    validate_memo_store_binding!(config)
     validate_fee_payer!(config)
     validate_fee_payer_allowed_tokens!(config)
     :ok

Source: GitHub Commit 2207d7f. The fix enforces a dedup store binding for Tempo static-memo configurations so that a given transfer hash cannot be reused across challenges.

Detection Methods for CVE-2026-73136

Indicators of Compromise

Multiple successful HTTP 402 verifications referencing the same Tempo transaction hash across distinct client sessions or source IPs.
Access to paid resources from clients that never broadcast an on-chain transfer matching their requests.
Repeated type="hash" credential submissions from unauthenticated clients within short time windows following legitimate customer payments.

Detection Strategies

Correlate mpp verification logs with Tempo ledger data to confirm that each hash credential is presented only once and originates from the paying wallet.
Alert on any MPP.Methods.Tempo configuration containing a static memo value without an associated dedup store binding.
Monitor for challenge requests that resolve using previously observed transaction hashes.

Monitoring Recommendations

Enable verbose logging on all mpp payment verification paths and forward events to a centralized analytics platform.
Track the version of the mpp dependency across all services and flag any instance running 0.6.1 through 0.6.3.
Audit method_config files in source control for static memo fields and confirm each has a corresponding store configuration.

How to Mitigate CVE-2026-73136

Immediate Actions Required

Upgrade mpp to version 0.6.4 or later across all services that expose Tempo payment methods.
Inventory method_config definitions and identify any Tempo route configured with a static memo.
Rotate recipient addresses if you suspect prior replay abuse, and reconcile paid resources against on-chain payer identities.

Patch Information

The fix is available in mpp 0.6.4 via commit 2207d7f. See the GitHub Security Advisory GHSA-34g7-vx6g-82mq and the CNA advisory for additional details. The patch introduces validate_memo_store_binding!/1, requiring a dedup store whenever a static memo is configured.

Workarounds

Remove static memo values from Tempo method_config and rely on per-challenge attribution nonces if upgrading is not immediately possible.
Disable the Tempo type="hash" credential path until the patched version is deployed.
Restrict paid endpoints behind additional authentication until the underlying mpp dependency is updated.

bash

# Update mpp in mix.exs to the patched release
{:mpp, "~> 0.6.4"}

# Refresh dependencies
mix deps.update mpp
mix deps.get