Balance Ceiling Bypass via Race Condition
The platform advertised a hard ceiling on account funds. We treated that ceiling as a promise and tried to break it. By firing a tight burst of identical funding requests in a single packet window, every request read the same "under the limit" balance before any of them wrote — and they all committed. The account sailed past its maximum to several times the allowed amount. No exotic payload, just timing.
- Duration
- 2 Weeks
- Team
- 2 Application Security Operators
- Scope
- Business Logic Testing
- Methodology
- Authenticated Grey-Box / Business Logic & Concurrency Testing
Attack narrative
Each phase references the MITRE ATT&CK technique used, with captured evidence.
- 01
Discovery
T1592 — Gather Victim Host Information
We funded a test account up to the legitimate ceiling and captured the single funding request the client issues, noting it relied entirely on a server-side balance check.
POST /investoraccount/{id}/deposit (observed)— RequestPOST /investoraccount/[REDACTED-ID]/deposit HTTP/2Host: app.[REDACTED-CLIENT].exampleContent-Type: application/jsonCookie: <AUTHENTICATED SESSION — REDACTED>{ "amount": [REDACTED] }— ResponseHTTP/2 200 OKContent-Type: application/json{ "status": "credited", "balance": "<at enforced ceiling>" } - 02
Analysis
Race Condition — TOCTOU (CWE-362)
The handler performed a CHECK (read balance, confirm below ceiling) and a USE (credit the amount) without a lock or atomic transaction between them — a classic time-of-check / time-of-use window.
operator@proteqon: concurrency-model# Two logically separate ops, no lock between themCHECK : read balance -> assert balance + amount <= MAXUSE : balance = balance + amount[!] No SELECT ... FOR UPDATE, no atomic transaction, no idempotency keyverdict : N parallel requests all pass CHECK before any USE commits$ - 03
Exploitation
T1499 — Endpoint Resource Manipulation
We replayed the captured funding request as a single simultaneous batch. Every request observed the pre-credit balance, passed validation, and committed — stacking deposits well past the ceiling. Performed on an operator-owned demo account only.
operator@proteqon: parallel-burst# Single-packet style burst of identical deposit requests$ race-runner --request deposit.txt --parallel 8 --single-packet[*] Dispatching 8 requests simultaneously...[+] 8/8 returned 200 OK (all passed the ceiling check)[+] Final balance >> enforced maximum (multiple deposits stacked)[!] Ceiling bypassed via timing alone$ - 04
Impact
T1565 — Data Manipulation
The same pattern applies anywhere a limit is checked and applied non-atomically — funding ceilings, promo redemptions, withdrawals. Inflated balances corrupt integrity of account data and any metrics derived from it.
Key vulnerabilities
Non-Atomic Balance Check and Credit (TOCTOU)
The ceiling check and the credit operation were not executed atomically, so concurrent requests bypassed the maximum-balance limit.
No Idempotency Controls on Funding
Funding requests lacked idempotency keys, allowing duplicate or replayed requests to each take effect.
No Velocity / Rate Limiting on Financial Operations
The absence of per-account rate limiting let a dense burst of requests land inside the race window unimpeded.
Remediation
- 01
Wrap the balance check and credit in a single atomic transaction with row-level locking (SELECT ... FOR UPDATE) and re-read the balance after the lock is held.
- 02
Require a unique idempotency key per funding request and reject duplicates within a time window.
- 03
Apply a distributed lock keyed on the account ID for the duration of the operation.
- 04
Add a database-level ceiling constraint as a last-resort guard and per-account velocity limits.
Outcome
Funding wrapped in an atomic, row-locked transaction with idempotency keys. Re-test confirmed the ceiling held under parallel load.
- Bypassed
- Enforced Ceiling
- Timing Only
- Exploit Technique
- ~8
- Parallel Requests
- None
- Production Funds Moved
All client identities, infrastructure details, and timelines in this report have been anonymized and adapted to protect confidentiality. Technique identifiers reference the MITRE ATT&CK framework. All offensive actions described were performed within a pre-authorized rules-of-engagement window; no production data was destroyed and no live systems were harmed.
Start an engagement
Want this level of rigor on your systems?
Book a 30-minute scoping call with a senior engineer. You'll leave with a clear recommendation on scope, approach, and timeline.