Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Details When the server acts as the feepayer, 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 accesslist 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 and gas parameters but never inspects accesslist length. It cosigns and broadcasts a transaction that costs the fee-payer wallet N × 2,400 extra gas per request with no corresponding work performed on-chain. At the default of 180 entries and 100 Gwei maxfeepergas, this inflates the fee-payer cost from the normal ~51,287 gas to ~483,287 gas — a 9.4× multiplier — while staying within the FeePayerPolicy cap of 500K…
Recommended action: Upgrade to 0.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 signature before co-signing) - Bypassing tempo/session voucher signature verification - Piggybacking off existing tempo/session channels via settle voucher reuse and weak channel ID binding - Performing free tempo/session requests by exploiting channel reopen without on-chain settled state - Accepting deductions on finalized tempo/session channels - Bypassing payment on free routes via method-mismatch fallback -…
Recommended action: Upgrade to 0.4.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Workarounds There are no workarounds available for this vulnerability.
Recommended action: Upgrade to 0.4.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.4.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.