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