mpp

Summary

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

An attacker who obtains a payer's subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client's own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer's wallet and re-authorize the server's access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.

Configurations

Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer's signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.

MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

An attacker who obtains a payer's subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client's own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer's wallet and re-authorize the server's access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.

Configurations

Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer's signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.

MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

An attacker who obtains a payer's subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client's own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer's wallet and re-authorize the server's access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.

Configurations

Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer's signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.

MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Authentication Bypass by Capture-replay in ZenHive mpp allows an attacker holding a captured subscription activation credential to charge the payer repeatedly.

The payer signs a Tempo KeyAuthorization over the chain id, key type, key id, expiry, limits and scopes only, with nothing tying it to the challenge that prompted it. MPP.Methods.Tempo.KeyAuthorization.verify/3 in lib/mpp/methods/tempo/key_authorization.ex pins each of those signed fields against the subscription request, and the access key it pins is a static per-endpoint server key, so one signed authorization verifies against every challenge the server issues for the same subscription terms. MPP.Methods.Tempo.Subscription.activate/4 deduplicates activations by challenge id, so presenting the captured credential under a fresh challenge produces a different dedup key, claim_activation succeeds, and the subscription transaction is built and broadcast again. Each replay charges the payer's wallet a new first-period settlement and re-authorizes the server key, bounded only by the subscription expiry and the chain's own semantics for re-installing an existing key.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

An attacker who obtains a payer's subscription activation credential (from a non-TLS hop, a log, a compromised intermediary, or the client's own retry buffer) can present it under fresh challenges to settle repeated first-period charges against that payer's wallet and re-authorize the server's access key. The payer bears the on-chain cost, limited only by the per-period subscription limit and the subscription expiry.

Configurations

Only deployments offering Tempo subscriptions are affected, which requires subscription_access_key_private_key in the Tempo method_config. Exploitation further requires the attacker to have obtained a payer's signed activation credential, in transit over a hop that is not TLS-protected or at rest in a log, an intermediary, or a client retry buffer.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows a client holding an open payment channel to obtain paid resources without being charged.

MPP.Session.Actions.accept_voucher/3 in lib/mpp/session/actions.ex treats a voucher whose cumulativeAmount equals the channel's already-accepted cumulative amount as an idempotent success, returning the channel unchanged without calling maybe_spend/2. The credential verifies, the protected resource is served, and spent and units stay where they were. Because the server issues a fresh challenge per request and the credential replay store keys on challenge id and payload, the same signed voucher can be re-presented under every new challenge, so one paid voucher yields an unbounded number of paid units. The path is reachable from any method built on MPP.Session.Method through the Plug, MCP, JSON-RPC and WebSocket transports.

This issue affects mpp: from 0.14.0 before 0.16.2.

Impact

A client that has opened and funded a payment channel once can re-present the same signed voucher indefinitely and receive paid resources without any further charge. Operators running mpp as paid-API middleware lose revenue in proportion to how much the client consumes, with nothing in the channel state recording the usage.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

Workarounds

Remove the static "memo" from the Tempo method_config so verification falls back to the default per-challenge attribution binding, which ties each settled transfer to the challenge being verified. Where a static memo must be kept, configure a dedup store (for example MPP.Tempo.ConCacheStore) with a TTL at least as long as the challenge expiry, which reduces unlimited replay to a race on the transaction hash rather than closing it.

Configurations

Only deployments that configure a static "memo" in the Tempo method_config are affected. Deployments using the default per-challenge attribution memo are not: that path binds each settled transfer to the challenge under verification and is single-use by construction.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for EIP-7702 account delegations of the client's choosing.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but never reads its aa_authorization_list field. Every signed delegation in that list is charged as intrinsic gas before the payment call runs, so a client attaching delegations from throwaway authority keys makes the sponsor pay for them within the default gas_limit ceiling. At the reporter's default of seven entries the sponsored cost rises from about 46,575 gas to about 1,884,087 gas. Because each entry is applied as a persistent set-code delegation, a client can also upgrade its own accounts to delegated code at the sponsor's expense.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope padded with delegations either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Improper Validation of Specified Quantity in Input in ZenHive mpp allows an unauthenticated remote client to inflate the fee-payer's gas cost per sponsored payment by a large multiplier and to have the sponsor pay for provisioning an access key on the client's own account.

When the server sponsors Tempo payments, MPP.Methods.Tempo.FeePayerPolicy.measure/3 in lib/mpp/methods/tempo/fee_payer_policy.ex bounds the gas fields, the fee budget, the validity window and the access list of the client-signed 0x76 envelope, but does not check whether the envelope carries the optional key_authorization field. A client can attach a fully signed key authorization, provisioning a new access key with token spending limits on its own account, alongside the normal payment call. The key and each limit entry are persistent storage writes billed as intrinsic gas to the sponsor, bounded only by the gas_limit ceiling. At the reporter's default of one key with three token limits the sponsored cost rises from about 46,587 gas to about 1,808,700 gas, and the client keeps a valid access key it paid nothing for.

This issue affects mpp: from 0.2.0 before 0.16.1.

Workarounds

Disable Tempo fee sponsorship by leaving "fee_payer" at its default of false and setting no fee_payer_url, so the client pays its own gas. Where sponsorship must stay enabled, lower the max_gas override in fee_payer_policy to just above what a legitimate sponsored payment needs (a TIP-20 transfer is roughly 50,000 gas), so an envelope carrying a key authorization either fails the policy or runs out of gas at a bounded cost. This bounds the inflation without closing it.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

Authentication Bypass by Capture-replay in ZenHive mpp allows an unauthenticated remote client to obtain paid resources by resubmitting one settled on-chain transfer.

MPP.Methods.EVM.verify/2 accepts a transaction-hash credential and matches a transfer purely on token, to and amount (ERC-20) or to and value (native). It binds the proof neither to the challenge being verified nor to any record of prior use, and the generic MPP.Plug dedup store keys on challenge.id, which is regenerated for every 402 response. On a static-price route, a single historical transfer matching the charge therefore satisfies an unbounded number of later charges, including transfers an attacker can read off a public block explorer.

This issue affects mpp: from 0.3.0 before 0.6.3.

Workarounds

Price each challenge uniquely (per-challenge or single-use amounts) so that a historical transfer cannot match a later charge, and keep challenge expiry short to narrow the window in which any given transfer stays useful. Deployments that can use the Tempo method for on-chain payments get per-challenge attribution binding instead.

Summary

Allocation of Resources Without Limits or Throttling in ZenHive mpp allows an unauthenticated remote client to drain the fee-payer wallet through concurrent sponsored payments, denying service to legitimate payers once it is empty.

MPP.Methods.Tempo.FeePayerPolicy enforces its ceilings (max_gas, max_fee_per_gas, max_priority_fee_per_gas, the worst-case gas_limit * max_fee_per_gas <= max_total_fee budget cap, and a validity window) against one transaction at a time, and nothing accounts for exposure across concurrent requests. reserve_hash_atomic/2 is keyed on the transaction hash, so it prevents duplicate broadcast of the same signed transaction but not N distinct sponsored transactions carrying distinct expiring nonces. Committed sponsor exposure is therefore N times max_total_fee, bounded by nothing in the library, and the default 900 second validity window lets co-signed transactions stay broadcastable and uncounted for that entire period.

This issue affects mpp: from 0.2.0 before 0.12.0.

Workarounds

Disable Tempo fee sponsorship by setting "fee_payer" => false (the default), so the client pays its own gas and the sponsor wallet is never committed. Where sponsorship must stay enabled, lowering max_total_fee and max_validity_window_seconds reduces the exposure each concurrent request can commit and how long it stays outstanding, without bounding the aggregate.

Configurations

Only deployments that enable Tempo server-side fee sponsorship are affected, through "fee_payer" => true in method_config with either local co-signing (fee_payer_private_key) or hosted sponsorship (fee_payer_url). Sponsorship is disabled by default.

Summary

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.

Workarounds

Remove the static "memo" from the Tempo method_config so verification falls back to the default per-challenge attribution binding, which ties each settled transfer to the challenge being verified. Where a static memo must be kept, configure a dedup store (for example MPP.Tempo.ConCacheStore) with a TTL at least as long as the challenge expiry, which reduces unlimited replay to a race on the transaction hash rather than closing it.

Configurations

Only deployments that configure a static "memo" in the Tempo method_config are affected. Deployments using the default per-challenge attribution memo are not: that path binds each settled transfer to the challenge under verification and is single-use by construction.

Summary

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.

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.

What 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.

This issue affects mpp: from 0.2.0 before 0.16.2.

Impact

A 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.

Configurations

Reachable 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.

Summary

Use of Cache Containing Sensitive Information in ZenHive mpp allows a shared HTTP cache to store a paid response and serve it to clients that never paid.

MPP.Plug.verify_credential in lib/mpp/plug.ex sets payment-receipt and cache-control: private on the connection before the wrapped application runs, and registers no register_before_send/2 callback. Plug.Conn.put_resp_header/3 replaces an existing header, so a mounting application that sets its own cache-control on the paid resource (for example public, max-age=3600) silently overrides the private the library relies on, and a CDN or reverse proxy can then store the paid 200 together with its Payment-Receipt and serve both to unpaid clients. The library-level guarantee is therefore defeatable by the application it protects. For the same reason a downstream non-2xx response still carried Payment-Receipt, issuing a receipt for a response that delivered no resource.

This issue affects mpp: from 0.1.0 before 0.16.2.

Impact

An unpaid client requesting the same URL through the shared cache receives the cached paid response, including the Payment-Receipt header issued to the paying client. Operators lose the revenue for every cache hit, and the receipt identifying a paid transaction is disclosed to third parties.

Workarounds

In the application mounted behind MPP.Plug, stop setting Cache-Control on paid routes so the library's private survives to the response, or set a directive that is itself safe for a shared cache (private, or no-store). Where the application must set its own caching policy, configure the CDN or reverse proxy not to cache responses carrying a Payment-Receipt header.

Configurations

Reachable only where the application mounted behind MPP.Plug sets its own Cache-Control on the paid resource, overriding the private the library wrote, and a shared HTTP cache (CDN or reverse proxy) sits in front of that route. An application that sets no Cache-Control of its own keeps the library's private and is not affected.