TOCTOU Race Condition

What is a TOCTOU Race Condition?#

TOCTOU (Time-of-Check to Time-of-Use, CWE-367) is the most prevalent subtype of race condition in both operating systems and web applications. The pattern is mechanically simple: an application evaluates a precondition at one moment (the check), then performs an action contingent on that precondition at a later moment (the use). Between these two moments, another thread, process, or concurrent request can change the state the check evaluated — invalidating the assumption the use relies on.

In web applications, the authoritative state lives in a database. Every SELECT-then-UPDATE sequence where the SELECT result drives the UPDATE condition is a potential TOCTOU. The check (SELECT) and use (UPDATE) are two separate round-trips to the database, and any concurrent request that writes to the same row during that window defeats the check. At the kernel level, the same pattern appears as stat()-then-open() sequences in filesystem access and as privilege checks followed by privileged operations in syscall handlers.

TOCTOU is classified under CWE-367, a child of CWE-362 (concurrent execution with shared resource). OWASP A04:2021 (Insecure Design) covers it under improper state machine design — the application's state machine was designed without guaranteeing atomic transitions between the check and use steps.

Mechanism#

The database TOCTOU follows a predictable three-step structure:

1. CHECK: SELECT state FROM resource WHERE id = X  →  state = 'valid'
2. [TOCTOU WINDOW — concurrent transaction reads same 'valid' state]
3. USE:   UPDATE resource SET state = 'consumed' WHERE id = X AND state = 'valid'

Both concurrent requests read state = 'valid' and both commit their UPDATE. The resource is consumed twice.

The filesystem TOCTOU follows the same pattern with file operations:

1. CHECK: stat("/upload/FILE.TXT")  →  extension = .txt (not JSP, skip compilation)
2. [TOCTOU WINDOW — attacker's FILE.JSP upload overwrites same path on case-insensitive FS]
3. USE:   process("/upload/FILE.TXT")  →  reads JSP content, compiles and executes

Apache Tomcat CVE-2024-50379 exploits exactly this filesystem TOCTOU. Tomcat's JSP compilation on case-insensitive file systems checks the filename to determine if compilation is needed. Two concurrent uploads to the same logical path — FILE.JSP and file.txt — create a race where Tomcat's extension check sees .txt but the compile step finds JSP bytecode. A subsequent GET /file.jsp executes the compiled JSP with Tomcat's service account privileges.

# CVE-2024-50379 class — filesystem TOCTOU PoC on case-insensitive FS
import asyncio
import httpx
 
async def tomcat_toctou_race(target: str, upload_endpoint: str, jsp_payload: bytes):
    """Race upload of FILE.JSP and file.txt to same case-insensitive FS path."""
    async with httpx.AsyncClient(http2=True, verify=False) as client:
        await client.get(target + "/")  # Warm connection
        harmless = client.post(upload_endpoint,
            files={"file": ("payload.txt", b"benign content", "text/plain")})
        weaponized = client.post(upload_endpoint,
            files={"file": ("PAYLOAD.JSP", jsp_payload, "application/x-jsp")})
        r1, r2 = await asyncio.gather(harmless, weaponized)
        # Trigger JSP compilation and execution
        rce = await client.get(target + "/payload.jsp")
        return rce.text  # "uid=" in response confirms RCE

Attack Variants#

Database TOCTOU is the most common web variant. Any ORM pattern that reads a row, checks a field, then updates is vulnerable. The read-into-memory → modify → save-back pattern has a race window on every ORM framework: Rails, Django, Hibernate, Mongoose.

Kernel TOCTOU vulnerabilities (CVE-2024-30088, CVE-2025-38352) appear regularly because kernel code frequently performs security decisions in one function and acts in another, with context switches possible between them. Three kernel-level TOCTOU CVEs reached the CISA KEV catalog between June 2024 and September 2025.

Hypervisor TOCTOU (CVE-2025-22224) is the highest-impact class: a guest VM process races a size check in the host-side VMCI driver against a buffer write, achieving heap overflow on the hypervisor host. VM escape from a CVSS 9.3 TOCTOU.

Real-World Examples#

CVE-2024-30088 — Windows Kernel (CISA KEV, June 2024, CVSS 7.0)

A TOCTOU in NtQueryInformationToken processing allowed local privilege escalation to SYSTEM. Added to CISA's Known Exploited Vulnerabilities catalog in June 2024 with confirmed in-the-wild exploitation. Patched in June 2024 Patch Tuesday.

CVE-2025-22224 — VMware ESXi/Workstation (CISA KEV, March 2025, CVSS 9.3)

A TOCTOU heap overflow in VMware's VMCI (Virtual Machine Communication Interface) subsystem enabled guest VM process escape to the hypervisor host. The race occurs between a size validation check and a subsequent memory copy — a guest with access to the VMCI device wins the race to corrupt host memory. Exploited in active campaigns targeting cloud and VDI environments before the March 2025 advisory.

CVE-2024-50379 + CVE-2024-56337 — Apache Tomcat (CVSS 9.8)

JSP compilation TOCTOU on case-insensitive file systems. Two concurrent uploads to the same logical path create a race where the extension check sees .txt but the compilation step executes JSP bytecode. GET /file.jsp triggers execution with Tomcat's service privileges. CVE-2024-56337 was an incomplete fix bypassable with alternative case permutations. Fixed in Tomcat 11.0.2 / 10.1.34 / 9.0.98.

CVE-2024-7344 — Docker Buildkit Symlink TOCTOU (CVSS 7.0)

Docker's BuildKit executor checked whether a path pointed to a regular file before processing. An attacker with build context access could race a symlink creation against the check, causing the build step to process a file outside the intended build context — container escape in Docker-in-Docker environments.

CVE-2025-38352 — Linux Kernel POSIX Timer TOCTOU (CISA KEV, September 2025, CVSS 7.4)

A TOCTOU in POSIX CPU timer handling allowed local privilege escalation. Added to the CISA KEV catalog in September 2025 — the third kernel-level TOCTOU in the catalog within 15 months.

Detection#

Manual Testing#

1. Identify endpoints performing a read-then-conditional-write: POST /redeem/{token}, POST /apply/{coupon}, POST /withdraw, POST /confirm/{token}.
2. Send 20 concurrent identical requests using Burp Repeater "Send group in parallel" (HTTP/2 single-packet).
3. Multiple 200 OK responses where only one is valid indicates a TOCTOU.
4. Read-race-read proof: GET state before burst, execute burst, GET state after. Counter incremented by N > 1 confirms TOCTOU.

For filesystem TOCTOU:

1. On upload endpoints running on Windows or macOS, concurrently upload files whose names differ only in case (test.TXT and test.jsp).
2. Immediately GET the .jsp path. Command output in the response confirms the race.

Automated Detection#

# Read-race-read TOCTOU proof pattern
async def toctou_proof(pre_url: str, race_url: str, race_body: dict,
                        post_url: str, headers: dict, n: int = 20):
    async with httpx.AsyncClient(http2=True, verify=False) as client:
        pre_state = (await client.get(pre_url, headers=headers)).json()
        tasks = [client.post(race_url, headers=headers, json=race_body) for _ in range(n)]
        responses = await asyncio.gather(*tasks)
        successes = sum(1 for r in responses if r.status_code == 200)
        post_state = (await client.get(post_url, headers=headers)).json()
        return {
            "race_successes": successes,
            "state_before": pre_state,
            "state_after": post_state,
            "toctou_confirmed": successes > 1,
        }

BreachVex detects database TOCTOU through complementary techniques: structural URL pattern analysis, concurrent request bursts, and state verification. Filesystem TOCTOU detection uses concurrent case-variant upload pairs against Windows/macOS-fingerprinted targets.

Prevention#

Atomic Conditional Update#

-- VULNERABLE: two-step check + update — TOCTOU window between them
SELECT is_used FROM tokens WHERE value = $1;
UPDATE tokens SET is_used = TRUE WHERE value = $1;
 
-- FIXED: atomic conditional UPDATE — no round-trip between check and use
UPDATE tokens
SET is_used = TRUE, used_by = $2, used_at = NOW()
WHERE value = $1 AND is_used = FALSE
RETURNING id;  -- 0 rows returned = already used

SELECT FOR UPDATE#

# SQLAlchemy — row-level write lock closes the TOCTOU window
with session.begin():
    token = session.execute(
        select(Token)
        .where(Token.value == token_value, Token.is_used == False)
        .with_for_update()  # Acquires write lock — concurrent SELECTs block
    ).scalar_one_or_none()
 
    if token is None:
        raise ValueError("Token invalid or already used")
 
    token.is_used = True
    token.used_by = user_id
    # Lock held until commit — TOCTOU window eliminated

Java: Optimistic Locking with @Version#

@Entity
public class Coupon {
    @Id private Long id;
    private boolean used;
 
    @Version
    private Long version;  // Auto-incremented on each UPDATE
}
 
@Transactional(isolation = Isolation.SERIALIZABLE)
public void redeemCoupon(Long couponId, Long userId) {
    Coupon coupon = couponRepository.findById(couponId)
        .orElseThrow(() -> new NotFoundException("Coupon not found"));
    if (coupon.isUsed()) {
        throw new IllegalStateException("Coupon already redeemed");
    }
    coupon.setUsed(true);
    coupon.setRedeemedBy(userId);
    // If version changed concurrently, throws OptimisticLockException — caller retries
    couponRepository.save(coupon);
}

Resources#

• NVD — CVE-2024-50379 Apache Tomcat TOCTOU RCE
• PortSwigger Web Security Academy — Race Conditions
• CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
• OWASP WSTG-BUSL-04 — Test for Process Timing