Post cover image

September 12, 2026

The Server Was Already Logged In - Race Conditions Part 2: Hidden Windows

Hidden sub-states, multi-endpoint attacks and single-endpoint password reset races - the deeper side of race conditions.

By // l1m1nal_3ntr0py

6 min read

By // l1m1nal_3ntr0py

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

This is Part 2 of a 3-part series on Race Conditions. Read Part 1 here.

None

In Part 1 we learned about limit overrun — using parallel requests to exceed a single-use limit before the server marks it as used. Simple concept. Devastating impact.

But that was just the surface.

Some race conditions do not involve limits at all. They involve something more subtle — hidden states that exist for milliseconds inside a single request. States the developer never intended anyone to see. States that briefly make the impossible possible.

This is where race conditions get interesting.

Hidden Multi-Step Sequences

When you send a request to a web application, you assume it does one thing. In reality, a single request often triggers an entire chain of operations behind the scenes — each one happening in sequence, each one creating a brief window where the application is in an in-between state.

These are called sub-states.

Think of a light switch. It is either on or off. But for a fraction of a second during the flick — it is neither. That fraction of a second is the sub-state. And in web security, that fraction of a second can be everything.

A login with MFA — the hidden sub-state:

python

# Step 1: Set user as logged in
session['userid'] = user.userid      ← logged in here!

# Step 2: Check if MFA needed
if user.mfa_enabled:
    session['enforce_mfa'] = True    ← MFA enforced here!
    # redirect to MFA page

Between Step 1 and Step 2 there is a window where the user is logged in — but MFA has not yet been enforced. For that brief moment the user has a valid authenticated session with no second factor required.

The race attack:

Normal flow (sequential):
Login → userid set → MFA enforced → redirect to MFA page
You try /dashboard → BLOCKED

Race attack:
Login request   ──────────────► userid set ←─────┐
/dashboard request ──────────► hits here! ✅      │
                               MFA not set yet!   │
                               ACCESS GRANTED!    │
                               MFA enforced ──────┘
                               (too late!)

Send the login request and a request to a sensitive authenticated endpoint simultaneously. The dashboard request hits the server during the window when the session has a valid user ID but MFA has not yet been enabled.

How to Spot Hidden Sub-States

You cannot see sub-states directly — you have to infer them. Here is how:

Trigger different errors on the same endpoint:

Send requests with intentionally wrong data to force the server through different code paths. Watch for responses that suggest the server is in an unexpected state — errors that should not exist if the request was processed completely.

Look for multi-step processes in a single request:

→ Login that also sets session variables
→ Registration that creates AND initialises a user
→ Payment that validates AND confirms in one request
→ Email change that sends AND records simultaneously

Any endpoint that does multiple things is a candidate.

Watch for second-order effects:

→ Emails arriving with wrong content
→ Session state changing unexpectedly
→ Responses that reference data from another request
→ Confirmation of actions you did not complete

Multi-Endpoint Race Conditions

The most intuitive form of multi-step race condition involves sending requests to multiple different endpoints simultaneously.

Classic example — the online shop basket trick:

Normal flow:
Add item to basket → Pay → Receive order confirmation

Race attack:
POST /payment ──────────────────► validates payment
POST /cart/add ──────────────────► adds expensive item
                 ↑ sent simultaneously!

Timeline:
Payment validated ──────────────────┐
Add item hits the window! 💥 ───────┤
Order confirmed (includes            │
your expensive item!) ───────────────┘

The payment is validated against the basket at the time of payment. But if you can add an item to the basket during the window between validation and confirmation — that item gets included in the confirmed order without being paid for.

Aligning Multi-Endpoint Windows

The challenge with multi-endpoint attacks is that different endpoints process at different speeds. Your /cart/add might complete in 50ms but /payment takes 200ms. By the time payment is ready to confirm, /cart/add has long finished — the window has closed.

Two solutions:

Connection warming:

Before your attack, send a dummy request on the same connection to warm up the back-end connection. This eliminates the initial connection delay that makes the first request slower than subsequent ones.

Step 1: Send harmless GET / to warm connection
Step 2: Notice first request is slower — connection warming working
Step 3: Remove warming request — subsequent requests now fast
Step 4: Run actual attack with aligned timing

In Burp Repeater: Group your requests → Send group in sequence (single connection) to warm → then Send group in parallel for the attack.

Abusing rate limits for server-side delay:

Flood the server with dummy requests to trigger its rate or resource limit. This causes the server to queue all incoming requests and process them at similar speeds — slowing down the fast endpoint to match the slow one.

Without rate limit abuse:
/cart/add  ──────► done (50ms)    ← already finished!
/payment   ──────────────────────► done (200ms)
Window:    ↑ too early ❌

With rate limit abuse:
Dummy GET × 50 ──────────────────────────────►
Server overwhelmed → queuing requests

Now attack requests join queue:
/cart/add  ──────────────────────► done (200ms)
/payment   ──────────────────────► done (200ms)
Both aligned! ✅ Window open!

Single-Endpoint Race Conditions

Not all race conditions require multiple endpoints. Some of the most elegant attacks happen on a single endpoint — by sending parallel requests with different values and letting them interfere with each other.

Password reset — the collision:

Consider a password reset mechanism that stores the user ID and reset token in the session:

python

# What the server does on each reset request:
session['reset-user'] = username    ← stored in session
session['reset-token'] = generate_token()
send_email(username, token)

Normal sequential behaviour:

Request 1 (wiener): reset-user=wiener, token=5678 → email sent to wiener
Request 2 (carlos): reset-user=carlos, token=1234 → email sent to carlos
No mixing. Safe. ✅

Race attack — parallel requests:

Request 1 (wiener) ──────────────────── token=5678
Request 2 (carlos) ───── token=1234
                      ↑ MIX HAPPENS HERE!

Final state:
reset-user = carlos  ← from request 2
reset-token = 5678   ← from request 1 (overwrote!)

Email sent to wiener with token 5678
But token 5678 is now linked to carlos!

Wiener uses token → resets CARLOS's password! 💀

How to execute in Burp:

Step 1: Login as wiener — get session cookie
Step 2: Go to password reset — enter wiener — intercept in Burp
Step 3: Send to Repeater
Step 4: Duplicate tab — change username to carlos in copy
Step 5: Group both tabs
Step 6: Send group in parallel
Step 7: Check wiener's email — did you receive a token?
Step 8: Use that token on the reset URL — it resets carlos!

Why this works:

The vulnerability is in the storage pattern:

Vulnerable — session storage:
session['reset-user'] = carlos     ← can be overwritten!
session['reset-token'] = 1234      ← can be overwritten!
Parallel requests write to SAME session → collision!

Safe — database storage:
DB.save(user=carlos, token=1234)   ← atomic operation
Each token linked directly to user in DB
No shared session → no collision!

Email-based operations are especially vulnerable:

Emails are often sent in a background thread after the HTTP response is returned. This means the race window is larger than usual — the server has already responded to your request before the email is even sent. More time for collision.

Session-Based Locking — Detecting and Bypassing

Some frameworks prevent race conditions by only processing one request per session at a time. PHP's native session handler does this by default.

How to detect session locking:

No locking (good for attacks):
Request 1 → responds at 200ms
Request 2 → responds at 201ms ← almost same time!

Session locking (bad for attacks):
Request 1 → responds at 200ms
Request 2 → responds at 400ms ← waited for request 1!
Request 3 → responds at 600ms ← waited for both!

Sequential timing = session locking detected ❌

The bypass — use different session tokens:

Instead of:
Request 1 → session=ABC (locked!)
Request 2 → session=ABC (waiting!)

Use:
Request 1 → session=ABC ← different sessions!
Request 2 → session=DEF ← process simultaneously!

Important caveat:

Session locking only stops attacks that use session storage. If the vulnerable data is stored in a database — different sessions still write to the same database record. Session locking is irrelevant.

Session storage → session locking stops the attack ❌
Database storage → different sessions → race still works ✅

Summary

HIDDEN SUB-STATES
→ Single requests trigger multiple backend operations
→ Gap between steps = sub-state = race window
→ Find by triggering errors and watching for
  unexpected responses

MULTI-ENDPOINT ATTACKS
→ Send requests to different endpoints simultaneously
→ Classic: add item during payment validation window
→ Fix timing with connection warming or rate limit abuse

SINGLE-ENDPOINT ATTACKS
→ Parallel requests with different values interfere
→ Session storage is vulnerable — overwrites possible
→ Email-based operations have larger windows
→ Detect session locking by checking response timing
→ Bypass by using different session tokens

WHAT TO LOOK FOR
→ Endpoints that store data in sessions
→ Multi-step processes in single requests
→ Email operations (sent in background threads)
→ Payment + order confirmation flows
→ Any shared mutable state

Part 3 coming soon — Partial construction race conditions, time-sensitive attacks, and how to prevent all of this.

Written by // l1m1nal_3ntr0py — documenting my cybersecurity journey from scratch

Follow my journey:

← Read Part 1