Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
CWE-367 Base Incomplete
Time-of-check Time-of-use (TOCTOU) Race Condition
This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and…
Definition
What is CWE-367?
This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data.
Think of this as a classic bait-and-switch attack against your code. Your application acts on a decision that was correct a moment ago but is now dangerously wrong. For example, your code might check that a file is owned by a safe user, but an attacker quickly swaps it with a symbolic link to a sensitive system file before your code opens it. This time-of-check to time-of-use (TOCTOU) gap is especially common in file system operations, but can also affect shared memory, process states, or even security tokens.
To defend against this, you must design your operations to be atomic—meaning the check and the use must happen as a single, uninterruptible action. Use file handles or descriptors instead of pathnames after validation, leverage file-locking mechanisms carefully, or employ secure APIs that internally manage state consistency. Always assume the environment can change between any two consecutive operations, and structure your code to minimize or eliminate these risky time windows.
Real-world impact
Real-world CVEs caused by CWE-367
-
TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
-
Chain: A multi-threaded race condition (CWE-367) allows attackers to cause two threads to process the same RPC request, which causes a use-after-free (CWE-416) in one thread
-
PHP flaw allows remote attackers to execute arbitrary code by aborting execution before the initialization of key data structures is complete.
-
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
-
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
How attackers exploit it
Step-by-step attacker path
- 1
The following code checks a file, then updates its contents.
- 2
Potentially the file could have been updated between the time of the check and the lstat, especially since the printf has latency.
- 3
The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.
- 4
The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges. This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.
- 5
This code prints the contents of a file if a user has permission.
Vulnerable code example
Vulnerable C
The following code checks a file, then updates its contents.
struct stat *sb;
...
lstat("...",sb); // it has not been updated since the last time it was read
printf("stated file\n");
if (sb->st_mtimespec==...){
print("Now updating things\n");
updateThings();
} Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-367
- Implementation The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
- Implementation When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
- Architecture and Design Limit the interleaving of operations on files from multiple processes.
- Implementation / Architecture and Design If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
- Implementation Recheck the resource after the use call to verify that the action was taken appropriately.
- Architecture and Design Ensure that some environmental locking mechanism can be used to protect resources effectively.
- Implementation Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
Detection signals
How to detect CWE-367
Plexicus auto-detects CWE-367 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-367?
How serious is CWE-367?
What languages or platforms are affected by CWE-367?
How can I prevent CWE-367?
How does Plexicus detect and fix CWE-367?
Where can I learn more about CWE-367?
Frequently asked questions
What is CWE-367?
This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data.
How serious is CWE-367?
MITRE rates the likelihood of exploit as Medium — exploitation is realistic but typically requires specific conditions.
What languages or platforms are affected by CWE-367?
MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.
How can I prevent CWE-367?
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check. When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
How does Plexicus detect and fix CWE-367?
Plexicus's SAST engine matches the data-flow signature for CWE-367 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-367?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/367.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-367
CWE-362 Parent
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
A race condition occurs when multiple processes or threads access a shared resource simultaneously without proper coordination, creating a…
CWE-1223 Sibling
Race Condition for Write-Once Attributes
This vulnerability occurs when an untrusted software component wins a race condition and writes to a hardware register before the trusted…
CWE-1298 Sibling
Hardware Logic Contains Race Conditions
A hardware race condition occurs when security-critical logic circuits receive signals at slightly different times, creating temporary…
CWE-364 Sibling
Signal Handler Race Condition
A signal handler race condition occurs when a program's signal handling routine is vulnerable to timing issues, allowing its state to be…
CWE-366 Sibling
Race Condition within a Thread
This vulnerability occurs when two or more threads within the same application access and manipulate a shared resource (like a variable,…
CWE-368 Sibling
Context Switching Race Condition
This vulnerability occurs when an application switches between different security contexts (like privilege levels or domains) using a…
CWE-421 Sibling
Race Condition During Access to Alternate Channel
A race condition occurs when an application opens a secondary communication channel intended for an authorized user, but fails to secure…
CWE-689 Sibling
Permission Race Condition During Resource Copy
This vulnerability occurs when a system copies a file or resource but delays setting its final permissions until the entire copy operation…
CWE-363 Child
Race Condition Enabling Link Following
This vulnerability occurs when a program checks a file's status before using it, creating a brief window where an attacker can replace…
Resources
Further reading
- MITRE — official CWE-367 https://cwe.mitre.org/data/definitions/367.html
- The CLASP Application Security Process https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf
- Portably Solving File TOCTTOU Races with Hardness Amplification https://www.usenix.org/legacy/events/fast08/tech/tsafrir.html
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.