In November 2025, three separate security flaws hit runc, a widely used container runtime used by technologies including Docker and Kubernetes. A few weeks later, a similar flaw turned up in filelock, a widely used Python library. They were different tools and companies, but it was the same root cause each time. It’s called TOCTOU, a race condition that’s been causing security flaws for decades.
What Is TOCTOU?
TOCTOU stands for Time-of-Check to Time-of-Use, and it’s a type of software security vulnerability. It happens when a program checks a resource’s state, like file permissions or user authorization, and then relies on that check still being true when it finally acts on the resource. In the small window between those two steps, an attacker can change the resource. It’s classified as CWE-367 in the Common Weakness Enumeration.
A good way to think about it is someone checking that a door is locked, walking away to get a set of keys, and then returning to open it. In that brief time, someone else could have unlocked it. The system trusts the original check, even though the situation could have changed entirely.
What makes TOCTOU particularly dangerous is that the timing window can be imperceptible to humans, often just microseconds, but automated tools can exploit it repeatedly. The pattern itself is decades old, but it’s exactly what caused the runc and filelock flaws mentioned above, and it keeps turning up in some of the most widely used software in existence.
How a TOCTOU Race Condition Works
TOCTOU race conditions follow a fairly simple pattern, and once you know how they work, they’re easier to spot in code.
Step 1: The Check
First, the system checks that a condition is met before moving on. For example, it might confirm a file exists, verify that a user has permission to access a resource, or check that an account has enough money for a transaction. The important thing is that the result is only valid at that moment.
Step 2: The Interval
After the system completes its check, there is usually a brief window before it takes action. Even if the code runs quickly, another process or an attacker can change the resource during this time. The problem is that the system may still rely on the original check when it acts.
Step 3: The Use
The system now uses the result of its earlier check and assumes nothing has changed. If an attacker changed or replaced the resource in the meantime, the system could end up working with something different from what it checked in the first place.
To sum up, the pattern is:
-
The vulnerability: the system relies on the result of an earlier check, even though the resource may have changed.
-
The exploit: an attacker changes the resource between the check and the action.
The exact technique that attackers use depends on the system and might involve sending multiple requests at the same time, changing files, or using symbolic links (files that point to another location, which the operating system follows automatically). Automated tools can make many attempts in a short time, so even a very small window can be enough to exploit a vulnerability.
Where TOCTOU Vulnerabilities Occur
TOCTOU isn’t limited to one type of system or programming language. It can occur anywhere a system checks something and then acts on it later, and it can take different forms depending on the system.
File System TOCTOU Attacks
One of the most common examples involves a privileged program checking a file before opening it. A privileged program might use access() to confirm that the user who invoked it is allowed to write to a file, then use open() to actually write to it.
The catch is that access() checks the permissions of the user who started the program, while open() uses the program’s own elevated privileges. An attacker can replace the file with a symbolic link between these two steps, pointing it at a file they aren’t normally allowed to modify. The earlier check still passes, but the write happens using the program’s elevated privileges.
This is known as a symlink attack. The program still believes it’s working with the file it checked, but the file has changed by the time it opens it.
Web Application Race Conditions
Web applications can also have TOCTOU vulnerabilities when they check something and act on it later. For example, an online store might check that an item is still in stock before processing an order. If two customers try to buy the last item at the same time, both checks could pass before either order is completed, allowing both orders to go through.
Privileged Program Exploitation
Programs with higher-than-normal permissions can make TOCTOU vulnerabilities more dangerous. For example, a program might check that a user is allowed to access a file and then modify it. If an attacker changes the file between the check and the action, the program could end up modifying a file the attacker wouldn’t normally have permission to change.
It’s particularly serious when the program has administrator-level access because the attacker could use the vulnerability to access files or resources they shouldn’t.
Cloud and Distributed Authorization Windows
These same check-then-use problems can also be found in microservices and cloud architectures. As an example, there could be an online store where one part of the application checks whether a customer is allowed to place an order, while another part processes the order. If that permission changes between the two steps, the order could still be processed based on the earlier check.
Things get more complicated when the check and the action happen in different services. One service might check whether a user has permission, while another performs the action. If that permission changes in between, the second service could act on an outdated decision.
Why TOCTOU Still Threatens Modern Applications
A vulnerability class identified decades ago might seem like something that should be solved by now. However, TOCTOU still appears in modern systems because new technologies create new ways for a resource or permission to change between the check and the action.
Container Runtimes and Escapes
There have been recent vulnerabilities in container tools that show TOCTOU is still an issue. One of them, CVE-2025-23359, is the TOCTOU race condition in the NVIDIA Container Toolkit that could allow an attacker to escape a container and execute code on the host. A related vulnerability, CVE-2024-0132, affected the same toolkit the year before.
Setting up containerized environments includes many separate steps, such as mounting filesystems and starting containers. If the system checks something at one step and relies on that information at a later step, there is a chance that something could change in between. This can create a TOCTOU vulnerability, and the number of components involved can make these issues more difficult to find during development.
AI Pipelines and Agentic Workflows
Nowadays, AI systems can create a much longer gap between a permission check and an action. An AI agent might be given permission to perform an action at the start of a task but not carry it out until much later. If its access changes in the meantime, the system needs to make sure the agent isn’t still relying on the earlier permission check.
This same pattern can also appear in how AI coding tools handle external tools that an agent is allowed to call. A user may approve a tool based on its configuration at one point, with the expectation that the approval remains valid. CVE-2025-54136 showed the risk when that configuration could be changed afterward.
In Cursor, an already-approved MCP server configuration could be modified without prompting the user to approve it again, allowing the tool’s behavior to change while the original approval remained in place.
Retrieval-based systems can face a similar issue. A system might check that a user is allowed to access certain data, but that permission could be revoked before the data is retrieved. The system may still provide the data based on the earlier check.
How to Detect TOCTOU in Code
The key to finding TOCTOU vulnerabilities is looking for code that checks something and then acts on it later. The longer the gap between the two steps, the more opportunity there is for something to change.
A simple example looks like this:
if user_allowed_to_access(file_path): # the check
... # the interval
open(file_path) # the use
There’s nothing necessarily wrong with this code on its own. The problem is that file_path could point to a different file by the time open() runs.
Static Analysis Limitations
When it comes to static analysis tools, they can help find check-then-use patterns, but they can’t always tell whether it’s dangerous. For example, the check and the action might happen in different parts of the code, making the connection harder for the tool to identify.
This can also lead to false positives, since a check followed by an action isn’t automatically a vulnerability. The risk depends on whether an attacker could change the resource between those two steps.
Manual Code Review Patterns
When reviewing code for TOCTOU vulnerabilities, look for patterns such as:
-
Checking a file and then opening it separately, such as
access()followed byopen(). -
A check and an action that happen as separate steps instead of one atomic operation.
-
Checking a file path and then using that path again later.
-
Multiple database operations where another request could change the data in between.
Dynamic Testing and Fuzzing
Dynamic testing looks for TOCTOU vulnerabilities while the application is running. Fuzzing takes this further by automatically making many attempts, often with different timing or inputs, to try to trigger a race condition.
For example, a testing tool might send multiple requests at the same time and repeat the test to see if one can change a resource between the check and the action. This can uncover vulnerabilities that aren’t obvious from looking at the code alone.
How to Prevent and Mitigate TOCTOU
Prevention focuses on removing the gap between the check and the action, or preventing the resource from changing during that time.
1. Combine the Check and Action with an Atomic Operation
An atomic operation combines the check and the action into a single step. For example, instead of checking whether a file already exists and then creating it, one operation can do both at once.
For file creation, for instance, use O_CREAT|O_EXCL with open() instead of first checking whether a file exists and then creating it.
2. Use File Descriptors Instead of Paths
After a file is opened, use the file descriptor for later operations instead of looking up the file by its path again.
For example, fstat() gets information about a file using its file descriptor, while stat() looks up the file using its path. Using fstat() helps ensure you’re still working with the same file, even if the path changes afterward.
3. Prevent changes While an Operation Is in Progress
It’s a good idea to use locks or database transactions when multiple legitimate processes or requests could access the same resource at the same time. For example, a lock can help prevent two processes from changing the same file at once, while a database transaction can group related database operations together.
Locks can help prevent race conditions caused by legitimate concurrent activity, but they aren’t always enough to stop a malicious attacker. Some file locks are advisory, meaning that another process can ignore the lock rather than respecting it.
For TOCTOU vulnerabilities involving attackers, atomic operations and file descriptors are often a better way to prevent the resource from changing between the check and the use.
4. Enforce Least Privilege and Reduce the Attack Surface
Give programs only the permissions they need to do their job. If an attacker exploits a TOCTOU vulnerability, this limits what they can access or change.
For example, avoid giving a program administrator-level access when it only needs to work with a specific set of files, reducing potential damage if the vulnerability is exploited.
TOCTOU Prevention with SecureFlag
TOCTOU vulnerabilities are easier to prevent when developers can recognize the pattern before coding even begins.
Threat modeling can help identify race condition risks during the design stage. With ThreatCanvas, teams can identify potential TOCTOU issues early and give developers guidance on how to address them before coding.
Hands-on training gives developers the chance to practice finding and fixing TOCTOU vulnerabilities in realistic scenarios. SecureFlag’s labs cover race conditions across multiple languages and frameworks, helping developers recognize the pattern and use the correct prevention techniques when they see it in their own code.
The labs also help developers build the skills to review AI-generated code for security issues, an important part of development as AI coding tools become part of everyday workflows.
Book a demo to see how SecureFlag helps developers build secure coding skills.
Frequently Asked Questions About TOCTOU
What is TOCTOU in cybersecurity?
TOCTOU (Time-of-Check to Time-of-Use) is a race condition vulnerability where an attacker exploits the timing delay between when a system checks a resource’s state and when it uses that resource. It is classified as CWE-367 in the Common Weakness Enumeration.
What is a TOCTOU race?
A TOCTOU race is a race condition where two operations, a security check and a subsequent use, compete with an attacker’s attempt to modify the resource in between. The attacker wins the race by changing the resource after verification but before use.
What is a TOCTOU gap?
The TOCTOU gap is the window of time between checking a condition, such as file permissions or account balance, and acting on that condition. Even a gap of microseconds can be sufficient for automated exploits to intervene.
Is TOCTOU the same as CWE-367?
CWE-367 is the official Common Weakness Enumeration entry for TOCTOU race conditions. TOCTOU describes the vulnerability pattern, while CWE-367 provides the standardized classification and reference used by security tools and frameworks.
