Full Report
Bitswift only allows people to interact with the blockchain via their web client. This puts in classic web vulnerabilities into the mix. When claiming a voucher (for a coin), a user makes a POST request to /claim. Since this happens in web server code, there is a small window where multiple web requests can be made on the voucher. So, a claim can be made multiple times with something like Turbo Intruder. Nice!
Analysis Summary
# Vulnerability: Bitswift Voucher Claim Race Condition
## CVE Details
- CVE ID: Not assigned by the provided text. **(Assumed "N/A")**
- CVSS Score: **Not specified.** Context suggests High severity due to potential financial loss.
- CWE: CWE-362: Race Condition
## Affected Systems
- Products: Bitswift web client/server component handling voucher claims.
- Versions: Not specified, but affected prior to the fix.
- Configurations: Affects the functionality accessible via the web client making a POST request to `/claim`.
## Vulnerability Description
The vulnerability lies in the server-side handling of the voucher claiming process accessed via the web client through a POST request to `/claim` on port 8443. Due to a race condition, if multiple claim requests for the same voucher are sent in parallel (e.g., using tools like Turbo Intruder), the system fails to serialize the execution properly, allowing a user to successfully claim the voucher multiple times, receiving more crypto-assets than entitled.
## Exploitation
- Status: **Not exploited** in the wild. PoC examples suggest testing using Turbo Intruder.
- Complexity: **Low**. Exploitation relies on sending concurrent HTTP requests, which is highly automated with common security tools.
- Attack Vector: **Network** (via the public web client interface).
## Impact
- Confidentiality: **No Impact**
- Integrity: **High**. An attacker could fraudulently increase their token balance by repeatedly claiming the same voucher before the server processes uniqueness checks.
- Availability: **Low/Medium**. While the faucet function was temporarily disabled, the core platform remained operational.
## Remediation
### Patches
- Specific patch version details are **not provided**. Bitswift implemented and deployed fixes to secure the faucet and claim functions immediately following disclosure.
### Workarounds
- Bitswift **disabled the claim faucet function** immediately upon receiving the report pending the update and deployment of the permanent fix.
## Detection
- **Indicators of Compromise (IoCs):** High frequency of POST requests to `/claim` endpoint originating from a single or few user sessions within a very short timeframe, resulting in multiple successful claims logged for a single voucher token.
- **Detection Methods and Tools:** Monitoring server logs for concurrent successful claims against unique voucher identifiers. This is a server-side logic flaw, so network-level monitoring might only catch the excessive traffic patterns used for exploitation.
## References
- Vendor advisories: Information provided via Immunefi report summary.
- Relevant links - defanged:
- Bug bounty program: hxxps://immunefi.com/bounty/bitswift
- Article source: hxxps://medium.com/immunefi/bitswift-race-condition-bugfix-review-588184b8b43e