CVE-2026-73136 in mpp
Summary
by MITRE • 08/19/2026
Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated third party to obtain paid resources by replaying a transfer settled by an unrelated payer.
MPP.Methods.Tempo normally binds a settled TIP-20 TransferWithMemo to the specific challenge under verification through an attribution nonce carried in the memo. When a static "memo" is configured in method_config, check_matched_memo_binding/3 returns the match unconditionally and that binding is skipped, leaving only token, recipient, amount and the static memo value to match on. The static memo is echoed in every unauthenticated 402 response and Tempo transfers are public, so an attacker can take any matching transfer paid by a legitimate customer, request a fresh challenge for the same route, and present that transaction hash as a type="hash" credential. The hash path performs no sender or signature check tying the presenter to the wallet that broadcast the transfer.
This issue affects mpp: from 0.6.1 before 0.6.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in ZenHive's Multi-Path Payment (MPP) implementation, specifically within versions ranging from 0.6.1 to just prior to 0.6.4, represents a critical authentication bypass mechanism rooted in improper binding of cryptographic challenges to transactional data. This flaw allows an unauthenticated third party to intercept and replay valid payment transactions originally settled by unrelated payers, thereby gaining unauthorized access to paid resources or services. The core technical deficiency lies in the handling of memo fields during the verification process for TIP-20 TransferWithMemo objects. Under normal operational conditions, the MPP.Methods.Tempo module is designed to bind a settled transfer to a specific challenge under verification by utilizing an attribution nonce embedded within the transaction's memo field. This binding ensures that each payment attempt is uniquely tied to its corresponding authentication request, preventing replay attacks through strict validation of dynamic identifiers.
However, when a static value is configured in the method_config for the memo parameter, the check_matched_memo_binding/3 function exhibits flawed logic by returning an unconditional match regardless of whether the attribution nonce aligns with the current challenge context. This configuration effectively disables the binding mechanism that ties the transaction to the specific authentication session. Consequently, the validation process relies solely on static attributes such as the token identifier, recipient address, payment amount, and the static memo value itself. Since these elements do not change between different users or sessions for identical service requests, they fail to provide unique identification of the legitimate payer. This oversight creates a scenario where the system cannot distinguish between a fresh authentication attempt by an authorized user and a replayed transaction from a previous session initiated by someone else.
The operational impact is exacerbated by the public nature of Tempo transfers and the behavior of the 402 Payment Required response code. When a legitimate customer initiates a payment, their transfer details become visible on the network. The system subsequently returns a 402 response that echoes back specific transaction identifiers or hashes required for verification. An attacker can monitor these public broadcasts to identify valid transfers made by paying customers. By requesting a fresh authentication challenge from the service using the same route and parameters as the intercepted payment, the attacker obtains a new context in which to present credentials. The attacker then submits the hash of the legitimate customer's transaction as a type=hash credential. Because the underlying path verification logic does not perform sender validation or signature checks that tie the presenter of the hash to the actual wallet address that broadcasted the original transfer, the system accepts this replayed proof of payment as valid.
This attack vector aligns with CWE-287, which classifies Improper Authentication, specifically highlighting failures in verifying identity through insufficient binding of credentials to session context. Furthermore, it corresponds to ATT&CK technique T1539, Steal Web Session Cookie, adapted for blockchain-based authentication where the transaction hash serves as a form of session token or proof-of-payment credential. The lack of sender verification means that possession of the transaction identifier is treated as sufficient authorization, ignoring the fundamental security principle that cryptographic proofs must be bound to the identity of the actor presenting them. This allows attackers to effectively steal access rights by leveraging the work and funds expended by legitimate users who have already settled their debts with the service provider.
Mitigation strategies for this vulnerability require immediate updates to the ZenHive MPP implementation beyond version 0.6.4, where these logic flaws are addressed. Developers must ensure that memo fields used for binding challenges contain dynamic, non-reusable values such as unique attribution nonces or timestamps that expire quickly. Static configuration of memo parameters should be strictly prohibited in production environments to prevent the unconditional matching behavior observed in vulnerable versions. Additionally, the verification process must enforce strict sender validation by verifying that the wallet address associated with the transaction hash matches the identity of the entity presenting the credential for authentication. Implementing these controls ensures that payment proofs are cryptographically bound to both the specific challenge context and the authorized user's identity, thereby neutralizing replay attacks and preserving the integrity of the access control mechanism.