5vulnerabilities
- Critical1 (20.0%)
- High1 (20.0%)
- Medium0 (0.0%)
- Moderate3 (60.0%)
- Low0 (0.0%)
mppx
Ecosystem: npm
Downloads:
- 1CriticalAffects 1 version
- 1HighAffects 1 version
- 0MediumAffects 0 versions
- 3ModerateAffects 3 versions
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 2 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 2
- Low: 0
- 3 vulnerabilities
- Critical: 1
- High: 1
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (5)
Known vulnerabilities affecting mppx, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-727h-3vm5-qwq6 | Moderate | mppx: Gas Draining with padding### Details When the server acts as the fee_payer, `mppx` 0.6.27 validates calldata using viem's `decodeFunctionData`, which is lenient about trailing bytes. The `FeePayerPolicy` caps `gas_limit` (≤ 2 M) and `max_fee_per_gas` (≤ 100 Gwei) but does **not** check calldata length. Tempo uses legacy calldata gas pricing: **16 gas per non-zero byte**. Appending `N` bytes of `0x01` padding inflates actual gas used by `N × 16` while keeping `gas_limit` and `max_fee_per_gas` within policy caps. The server cosigns and broadcasts the padded transaction, draining its fee-payer wallet. **Vulnerable code |
| GitHub (opens in a new tab) | |
| GHSA-vc9j-9wph-qghj | Moderate | mppx: Gas Draining with access list### Details When the server acts as the fee_payer, `mppx` 0.6.27 copies the client-supplied EIP-2930 access list verbatim into the cosigned fee-payer transaction. The TypeScript SDK's fee-payer cosigning path accepts any `access_list` the client includes in the 0x78 `FeePayerEnvelope` without inspecting its length or contents. Access list gas is charged **intrinsically** — before any opcode executes — regardless of whether the listed addresses are ever touched. An attacker submits a valid `transferWithMemo` alongside fabricated address-only access list entries. The server validates calldata |
| GitHub (opens in a new tab) | |
| GHSA-8mhj-rffc-rcvw | Moderate | mppx has Stripe charge credential replay via missing idempotency check### Impact The `stripe/charge` payment method did not check Stripe's `Idempotent-Replayed` response header when creating PaymentIntents. An attacker could replay a valid credential containing the same `spt` token against a new challenge, and the server would accept the replayed Stripe PaymentIntent as a new successful payment without actually charging the customer again. This allowed an attacker to pay once and consume unlimited resources by replaying the credential. ### Patches Fixed in 0.4.11. The server now checks the `Idempotent-Replayed` header and rejects replayed PaymentIntents. ### |
| GitHub (opens in a new tab) | |
| GHSA-8x4m-qw58-3pcx | Critical | mppx has multiple payment bypass and griefing vulnerabilities### Impact Multiple vulnerabilities were discovered in `tempo/charge` and `tempo/session` which allowed for undesirable behaviors, including: - Replaying `tempo/charge` transaction hashes across push/pull modes, across charge/session endpoints, and via concurrent requests - Performing free `tempo/charge` requests due to missing transfer log verification in pull-mode - Replaying `tempo/charge` credentials across routes via cross-route scope confusion (`memo`/`splits` not included in scope binding) - Manipulating the fee payer of a `tempo/charge` handler into paying for requests (missing sender |
| GitHub (opens in a new tab) | |
| GHSA-mv9j-8jvg-j8mr | High | mppx: Tempo has a session close voucher bypass vulnerability due to settled amount equality### Impact The `tempo/session` cooperative close handler validated the close voucher amount using `<` instead of `<=` against the on-chain settled amount. An attacker could submit a close voucher exactly equal to the settled amount, which would be accepted without committing any new funds, effectively closing or griefing the channel for free. ### Patches Fixed in 0.4.11. ### Workarounds There are no workarounds available for this vulnerability. |
| GitHub (opens in a new tab) |
### Details When the server acts as the fee_payer, `mppx` 0.6.27 validates calldata using viem's `decodeFunctionData`, which is lenient about trailing bytes. The `FeePayerPolicy` caps `gas_limit` (≤ 2 M) and `max_fee_per_gas` (≤ 100 Gwei) but does **not** check calldata length. Tempo uses legacy calldata gas pricing: **16 gas per non-zero byte**. Appending `N` bytes of `0x01` padding inflates actual gas used by `N × 16` while keeping `gas_limit` and `max_fee_per_gas` within policy caps. The server cosigns and broadcasts the padded transaction, draining its fee-payer wallet. **Vulnerable code
CVE: CVE-2026-63627
### Details When the server acts as the fee_payer, `mppx` 0.6.27 copies the client-supplied EIP-2930 access list verbatim into the cosigned fee-payer transaction. The TypeScript SDK's fee-payer cosigning path accepts any `access_list` the client includes in the 0x78 `FeePayerEnvelope` without inspecting its length or contents. Access list gas is charged **intrinsically** — before any opcode executes — regardless of whether the listed addresses are ever touched. An attacker submits a valid `transferWithMemo` alongside fabricated address-only access list entries. The server validates calldata
CVE: CVE-2026-63628
- GHSA-8mhj-rffc-rcvwModeratemppx has Stripe charge credential replay via missing idempotency check
< 0.4.11
### Impact The `stripe/charge` payment method did not check Stripe's `Idempotent-Replayed` response header when creating PaymentIntents. An attacker could replay a valid credential containing the same `spt` token against a new challenge, and the server would accept the replayed Stripe PaymentIntent as a new successful payment without actually charging the customer again. This allowed an attacker to pay once and consume unlimited resources by replaying the credential. ### Patches Fixed in 0.4.11. The server now checks the `Idempotent-Replayed` header and rejects replayed PaymentIntents. ###
CVE: CVE-2026-34210
- GHSA-8x4m-qw58-3pcxCriticalmppx has multiple payment bypass and griefing vulnerabilities
< 0.4.8
### Impact Multiple vulnerabilities were discovered in `tempo/charge` and `tempo/session` which allowed for undesirable behaviors, including: - Replaying `tempo/charge` transaction hashes across push/pull modes, across charge/session endpoints, and via concurrent requests - Performing free `tempo/charge` requests due to missing transfer log verification in pull-mode - Replaying `tempo/charge` credentials across routes via cross-route scope confusion (`memo`/`splits` not included in scope binding) - Manipulating the fee payer of a `tempo/charge` handler into paying for requests (missing sender
- GHSA-mv9j-8jvg-j8mrHighmppx: Tempo has a session close voucher bypass vulnerability due to settled amount equality
< 0.4.11
### Impact The `tempo/session` cooperative close handler validated the close voucher amount using `<` instead of `<=` against the on-chain settled amount. An attacker could submit a close voucher exactly equal to the settled amount, which would be accepted without committing any new funds, effectively closing or griefing the channel for free. ### Patches Fixed in 0.4.11. ### Workarounds There are no workarounds available for this vulnerability.
CVE: CVE-2026-34209