Mpp
Monthly
Replay of a captured Tempo subscription credential in ZenHive mpp 0.14.0 through 0.16.1 lets an attacker who already holds a validly signed Tempo KeyAuthorization repeatedly charge the same payer's wallet. The signed authorization is bound only to chain id, key type, key id, expiry, limits, and scopes - never to the challenge that prompted it - so it verifies against every challenge the server issues for the same subscription terms, and because Subscription.activate/4 deduplicates activations solely by challenge id, a fresh challenge yields a new dedup key and the settlement transaction is rebuilt and broadcast again. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, but the flaw class is a straightforward capture-replay, exploitation requires only that the attacker obtain one signed credential (attack requirements: present, AC:H), and the independent assessment rates integrity impact High on a CVSS:3.1 base of 8.2.
ZenHive mpp versions 0.14.0 through 0.16.1 fail to charge clients that hold an open payment channel, allowing an authenticated client to obtain an unbounded number of paid units from a single signed voucher. The flaw sits in MPP.Session.Actions.accept_voucher/3, which returns the channel unchanged when a voucher's cumulativeAmount equals the already-accepted cumulative amount, so the credential verifies, the protected resource is served, and no spend is recorded; because the server issues a fresh challenge per request and the replay store keys only on challenge id plus payload, the same voucher can be re-presented under every new challenge. The result is a high-integrity billing/accounting bypass (CVSS 4.0 7.1, PR:L) reachable over the network through the Plug, MCP, JSON-RPC and WebSocket transports; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though a vendor patch is available.
Missing validation of the EIP-7702 aa_authorization_list field in ZenHive mpp's Tempo payment sponsorship module allows any unauthenticated remote client to inflate the fee-payer's gas cost by roughly 40x and to have the sponsor pay for persistent EIP-7702 set-code delegations on attacker-controlled Ethereum accounts. Versions 0.2.0 through 0.16.0 are affected; the FeePayerPolicy.measure/3 function validates gas fields, fee budget, validity window, and access list but never inspects the aa_authorization_list, so a client embedding seven throwaway delegation entries drives sponsored gas from approximately 46,575 to over 1,884,087. No public exploit has been identified at time of analysis, and a vendor patch is available in mpp 0.16.1.
Gas-cost inflation and unauthorized access key provisioning in ZenHive mpp (versions 0.2.0 through 0.15.x) allows any unauthenticated remote client to attach a fully signed key_authorization payload to a Tempo 0x76 payment envelope, forcing the fee sponsor to pay for persistent blockchain storage writes the client itself initiated. At the reporter's default test case of one access key with three token spending limits, the sponsor's gas cost rises from roughly 46,587 to roughly 1,808,700 gas - approximately a 39x multiplier - while the client retains a valid access key it paid nothing for. No public exploit has been identified at time of analysis, but the vulnerability is well-specified and trivially reproducible given knowledge of the Tempo protocol.
Replay of settled EVM blockchain transaction hashes against ZenHive mpp versions 0.3.0-0.6.2 allows unauthenticated remote attackers to obtain paid resources at no cost. MPP.Methods.EVM.verify/2 validates payment by matching a submitted transaction hash against on-chain token/recipient/amount fields but neither binds the proof to a specific challenge nor records prior use; because MPP.Plug regenerates challenge.id on every 402 response, any historical on-chain transfer visible on a public block explorer can satisfy an unlimited number of subsequent payment challenges on a static-price route. No public exploit code has been identified at time of analysis and no CISA KEV listing exists, though the attack prerequisites are trivially met given the public nature of blockchain transaction data.
Concurrent sponsored-payment flooding in ZenHive mpp (versions 0.2.0 through 0.12.0) allows an unauthenticated remote client to drain a fee-payer wallet to zero, denying service to all legitimate sponsored-transaction users once the wallet is empty. The root cause is that MPP.Methods.Tempo.FeePayerPolicy enforces per-transaction budget ceilings but maintains no aggregate accounting across concurrent in-flight sponsorships, meaning N simultaneous sponsored requests commit N × max_total_fee against the wallet with no global cap. No public exploit has been identified at time of analysis, but the attack is mechanically trivial once the sponsor endpoint is reachable - no authentication, no cryptographic preconditions, only the ability to issue distinct signed transactions with distinct nonces within the 900-second validity window.
Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to claim paid resources by reusing a legitimate customer's public TIP-20 TransferWithMemo transaction hash. When the Tempo payment method is configured with a static 'memo' value in method_config, the per-challenge attribution nonce binding that ties a specific transfer to a specific verification challenge is skipped unconditionally, and the hash credential path performs no sender or wallet-signature check - leaving only token, recipient, amount, and the static memo (itself broadcast in every unauthenticated 402 response) to match. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available in mpp 0.6.4.
Wallet-draining denial of service in ZenHive mpp (Elixir library) versions 0.2.0 through 0.5.x affects deployments configured as a Tempo fee payer (fee_payer: true), where the MPP.Methods.Tempo method co-signs and broadcasts a client-supplied EVM transaction without verifying the client's gas_limit is high enough to complete execution. An unauthenticated remote client can submit a signed transferWithMemo transaction with gas_limit set just below the required amount, causing an on-chain out-of-gas revert that still charges the sponsor's fee-payer wallet while the attacker pays nothing. There is no public exploit identified at time of analysis and this is not on CISA KEV, but repeated low-cost requests can exhaust the sponsor wallet and stop the server from funding gas for legitimate payment requests.
Economic resource exhaustion in the ZenHive mpp Elixir library (versions 0.2.0 through 0.5.x) lets an unauthenticated remote client inflate a sponsoring fee-payer's gas cost per payment by roughly 7.4x, draining the sponsor wallet over sustained abuse. When deployed with fee_payer: true, MPP.Tempo.Transaction.cosign_fee_payer/3 re-signs client-supplied base fields of the 0x76 AASigned envelope verbatim - including an oversized EIP-2930 access list - without validating length or contents, so intrinsic gas is charged for fabricated entries that touch nothing on-chain. No public exploit identified at time of analysis, but the attack is fully detailed in the vendor advisory and fixed in 0.6.0.
Fee-payer wallet draining in ZenHive mpp (Elixir) 0.2.0-0.5.x lets an unauthenticated remote client empty the sponsor's wallet in a single request when the server runs with fee_payer: true. Because MPP.Tempo.Transaction.cosign_fee_payer/3 co-signs the client-supplied gas ceilings (max_fee_per_gas / max_priority_fee_per_gas) of the 0x76 AASigned envelope without bounds checking, an attacker sets arbitrarily large per-gas rates that are billed against the server's wallet, after which it can no longer sponsor legitimate payments. No public exploit identified at time of analysis; the issue was reported by the Erlang Ecosystem Foundation (EEF) and patched in 0.6.0.
Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unauthenticated remote client pass the pre-broadcast dedup reservation twice using a single signed transaction - once with recovery id v=27 and once with v=0 - because the reserve key is derived from the caller-supplied raw transaction hex rather than a canonical form of the transaction. The post-broadcast mark then writes the canonical hash key that the raw-keyed reserve never reads, so the two encodings never collide. Impact is real but bounded and conditional: a node that rejects nonce reuse fails closed and produces no harm, while a node that returns the canonical hash for an already-known transaction can issue a second valid Payment-Receipt for a single on-chain payment; confidentiality and availability are unaffected, and no public exploit code has been identified at time of analysis.
ZenHive mpp (MPP.Plug payment middleware for Elixir/Phoenix) versions 0.1.0 through 0.16.1 can allow a shared HTTP cache - a CDN or reverse proxy - to store a paid 200 response together with its Payment-Receipt header and replay both to clients that never paid, because the library's own Cache-Control: private is silently replaced when the mounting application sets its own cache directive on the same connection. An unauthenticated remote client that reaches such a cache can therefore obtain paid content and a valid receipt for free, and a related weaker case has a downstream non-2xx response still carrying a Payment-Receipt for a resource that was never delivered (CWE-524). The real-world risk is tightly bounded: the library's default behavior (private on success, no-store on 402) is safe, so the leak requires an application-level caching misconfiguration plus a shared cache in the response path, and no public exploit code was identified at time of analysis.
Payment-replay protection in ZenHive mpp's Tempo hash-credential path is defeated by a TOCTOU race condition, allowing a single confirmed on-chain payment hash to be redeemed for multiple paid-resource grants. The race window spans an eth_getTransactionReceipt RPC round trip - potentially hundreds of milliseconds - during which concurrent unauthenticated requests all pass the non-atomic read guard before any write completes. Affected deployments run mpp 0.2.0 through 0.6.0 with a dedup store configured; no public exploit has been identified at time of analysis, but the attack requires only a standard concurrent HTTP client and knowledge of a valid settled payment hash.
Replay of a captured Tempo subscription credential in ZenHive mpp 0.14.0 through 0.16.1 lets an attacker who already holds a validly signed Tempo KeyAuthorization repeatedly charge the same payer's wallet. The signed authorization is bound only to chain id, key type, key id, expiry, limits, and scopes - never to the challenge that prompted it - so it verifies against every challenge the server issues for the same subscription terms, and because Subscription.activate/4 deduplicates activations solely by challenge id, a fresh challenge yields a new dedup key and the settlement transaction is rebuilt and broadcast again. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, but the flaw class is a straightforward capture-replay, exploitation requires only that the attacker obtain one signed credential (attack requirements: present, AC:H), and the independent assessment rates integrity impact High on a CVSS:3.1 base of 8.2.
ZenHive mpp versions 0.14.0 through 0.16.1 fail to charge clients that hold an open payment channel, allowing an authenticated client to obtain an unbounded number of paid units from a single signed voucher. The flaw sits in MPP.Session.Actions.accept_voucher/3, which returns the channel unchanged when a voucher's cumulativeAmount equals the already-accepted cumulative amount, so the credential verifies, the protected resource is served, and no spend is recorded; because the server issues a fresh challenge per request and the replay store keys only on challenge id plus payload, the same voucher can be re-presented under every new challenge. The result is a high-integrity billing/accounting bypass (CVSS 4.0 7.1, PR:L) reachable over the network through the Plug, MCP, JSON-RPC and WebSocket transports; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though a vendor patch is available.
Missing validation of the EIP-7702 aa_authorization_list field in ZenHive mpp's Tempo payment sponsorship module allows any unauthenticated remote client to inflate the fee-payer's gas cost by roughly 40x and to have the sponsor pay for persistent EIP-7702 set-code delegations on attacker-controlled Ethereum accounts. Versions 0.2.0 through 0.16.0 are affected; the FeePayerPolicy.measure/3 function validates gas fields, fee budget, validity window, and access list but never inspects the aa_authorization_list, so a client embedding seven throwaway delegation entries drives sponsored gas from approximately 46,575 to over 1,884,087. No public exploit has been identified at time of analysis, and a vendor patch is available in mpp 0.16.1.
Gas-cost inflation and unauthorized access key provisioning in ZenHive mpp (versions 0.2.0 through 0.15.x) allows any unauthenticated remote client to attach a fully signed key_authorization payload to a Tempo 0x76 payment envelope, forcing the fee sponsor to pay for persistent blockchain storage writes the client itself initiated. At the reporter's default test case of one access key with three token spending limits, the sponsor's gas cost rises from roughly 46,587 to roughly 1,808,700 gas - approximately a 39x multiplier - while the client retains a valid access key it paid nothing for. No public exploit has been identified at time of analysis, but the vulnerability is well-specified and trivially reproducible given knowledge of the Tempo protocol.
Replay of settled EVM blockchain transaction hashes against ZenHive mpp versions 0.3.0-0.6.2 allows unauthenticated remote attackers to obtain paid resources at no cost. MPP.Methods.EVM.verify/2 validates payment by matching a submitted transaction hash against on-chain token/recipient/amount fields but neither binds the proof to a specific challenge nor records prior use; because MPP.Plug regenerates challenge.id on every 402 response, any historical on-chain transfer visible on a public block explorer can satisfy an unlimited number of subsequent payment challenges on a static-price route. No public exploit code has been identified at time of analysis and no CISA KEV listing exists, though the attack prerequisites are trivially met given the public nature of blockchain transaction data.
Concurrent sponsored-payment flooding in ZenHive mpp (versions 0.2.0 through 0.12.0) allows an unauthenticated remote client to drain a fee-payer wallet to zero, denying service to all legitimate sponsored-transaction users once the wallet is empty. The root cause is that MPP.Methods.Tempo.FeePayerPolicy enforces per-transaction budget ceilings but maintains no aggregate accounting across concurrent in-flight sponsorships, meaning N simultaneous sponsored requests commit N × max_total_fee against the wallet with no global cap. No public exploit has been identified at time of analysis, but the attack is mechanically trivial once the sponsor endpoint is reachable - no authentication, no cryptographic preconditions, only the ability to issue distinct signed transactions with distinct nonces within the 900-second validity window.
Capture-replay authentication bypass in ZenHive mpp versions 0.6.1-0.6.3 allows unauthenticated network attackers to claim paid resources by reusing a legitimate customer's public TIP-20 TransferWithMemo transaction hash. When the Tempo payment method is configured with a static 'memo' value in method_config, the per-challenge attribution nonce binding that ties a specific transfer to a specific verification challenge is skipped unconditionally, and the hash credential path performs no sender or wallet-signature check - leaving only token, recipient, amount, and the static memo (itself broadcast in every unauthenticated 402 response) to match. No active exploitation is confirmed and no public exploit code has been identified; a vendor patch is available in mpp 0.6.4.
Wallet-draining denial of service in ZenHive mpp (Elixir library) versions 0.2.0 through 0.5.x affects deployments configured as a Tempo fee payer (fee_payer: true), where the MPP.Methods.Tempo method co-signs and broadcasts a client-supplied EVM transaction without verifying the client's gas_limit is high enough to complete execution. An unauthenticated remote client can submit a signed transferWithMemo transaction with gas_limit set just below the required amount, causing an on-chain out-of-gas revert that still charges the sponsor's fee-payer wallet while the attacker pays nothing. There is no public exploit identified at time of analysis and this is not on CISA KEV, but repeated low-cost requests can exhaust the sponsor wallet and stop the server from funding gas for legitimate payment requests.
Economic resource exhaustion in the ZenHive mpp Elixir library (versions 0.2.0 through 0.5.x) lets an unauthenticated remote client inflate a sponsoring fee-payer's gas cost per payment by roughly 7.4x, draining the sponsor wallet over sustained abuse. When deployed with fee_payer: true, MPP.Tempo.Transaction.cosign_fee_payer/3 re-signs client-supplied base fields of the 0x76 AASigned envelope verbatim - including an oversized EIP-2930 access list - without validating length or contents, so intrinsic gas is charged for fabricated entries that touch nothing on-chain. No public exploit identified at time of analysis, but the attack is fully detailed in the vendor advisory and fixed in 0.6.0.
Fee-payer wallet draining in ZenHive mpp (Elixir) 0.2.0-0.5.x lets an unauthenticated remote client empty the sponsor's wallet in a single request when the server runs with fee_payer: true. Because MPP.Tempo.Transaction.cosign_fee_payer/3 co-signs the client-supplied gas ceilings (max_fee_per_gas / max_priority_fee_per_gas) of the 0x76 AASigned envelope without bounds checking, an attacker sets arbitrarily large per-gas rates that are billed against the server's wallet, after which it can no longer sponsor legitimate payments. No public exploit identified at time of analysis; the issue was reported by the Erlang Ecosystem Foundation (EEF) and patched in 0.6.0.
Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unauthenticated remote client pass the pre-broadcast dedup reservation twice using a single signed transaction - once with recovery id v=27 and once with v=0 - because the reserve key is derived from the caller-supplied raw transaction hex rather than a canonical form of the transaction. The post-broadcast mark then writes the canonical hash key that the raw-keyed reserve never reads, so the two encodings never collide. Impact is real but bounded and conditional: a node that rejects nonce reuse fails closed and produces no harm, while a node that returns the canonical hash for an already-known transaction can issue a second valid Payment-Receipt for a single on-chain payment; confidentiality and availability are unaffected, and no public exploit code has been identified at time of analysis.
ZenHive mpp (MPP.Plug payment middleware for Elixir/Phoenix) versions 0.1.0 through 0.16.1 can allow a shared HTTP cache - a CDN or reverse proxy - to store a paid 200 response together with its Payment-Receipt header and replay both to clients that never paid, because the library's own Cache-Control: private is silently replaced when the mounting application sets its own cache directive on the same connection. An unauthenticated remote client that reaches such a cache can therefore obtain paid content and a valid receipt for free, and a related weaker case has a downstream non-2xx response still carrying a Payment-Receipt for a resource that was never delivered (CWE-524). The real-world risk is tightly bounded: the library's default behavior (private on success, no-store on 402) is safe, so the leak requires an application-level caching misconfiguration plus a shared cache in the response path, and no public exploit code was identified at time of analysis.
Payment-replay protection in ZenHive mpp's Tempo hash-credential path is defeated by a TOCTOU race condition, allowing a single confirmed on-chain payment hash to be redeemed for multiple paid-resource grants. The race window spans an eth_getTransactionReceipt RPC round trip - potentially hundreds of milliseconds - during which concurrent unauthenticated requests all pass the non-atomic read guard before any write completes. Affected deployments run mpp 0.2.0 through 0.6.0 with a dedup store configured; no public exploit has been identified at time of analysis, but the attack requires only a standard concurrent HTTP client and knowledge of a valid settled payment hash.