In plain English
Replaying an old payment created new credits, like a receipt that works every time you show it.
The technical account follows below, for readers who want the detail.
Three lessons any team can use
Every payment action needs a guard against being repeated.
Check that a payment already settled before handing over value.
Replay protection belongs in the ledger, not the interface.
The Challenge
A cloud development platform credited virtual machine time on payment, but replaying a completed transaction through a proxy minted fresh credits without fresh payment. The payment path never confirmed whether a transaction had already settled, so one purchase could be spent over and over.
How We Proved It
Traced the flaw to missing idempotency in the checkout and team mutation logic, where replayed transactions processed as new instead of settled. Showed the credit balance climbing past 5,000 on replay with screenshots and a walkthrough video, supplied workspace identifiers so the vendor could trace events in their own logs, and filed a full public advisory with reproduction detail. The vendor confirmed investigation and the researcher was formally credited on the published GHSA.
CodeSandbox
Jun 21, 2024
Security Advisory
Full Writeup
Researched and disclosed by Abang Obed. Read every step, payload, and takeaway.
Read the advisoryRelated Case Studies
More disclosures from our researchers.
Know your risk. Strengthen what matters.
Tell us where you are, what you rely on, and what you need to protect. We will help you understand what to do next.