AppSec Knowledge Base


What Is a Race Condition Vulnerability?

A race condition attack happens when a computing system that’s designed to handle tasks in a specific sequence is forced to perform two or more operations simultaneously. This technique takes advantage of a time gap between the moment a service is initiated and the moment a security control takes effect. This attack, which depends on multithreaded applications, can be delivered in one of two ways: interference caused by untrusted processes (essentially a piece of code that slips into a sequence between steps of a secure programs), and interference caused by a trusted process, which may have the "same'' privileges. Without proper controls, different processes can interfere with each other. Other names used to refer to this vulnerability include Time of Check/Time of Use or TOC/TOU attacks.

Ask A Qualified AppSec Expert

Struggling with fixing a code weakness? Knowledgeable consultants at Veracode can help you out.

Ask in the Community

Rates of Race Condition Flaws in Software

What Happens During a Race Condition Attack?

Web applications, file systems, and networking environments are all vulnerable to a race condition attack. Attackers might target an access control list (ACL), a payroll or human resources database, a transactional system, a financial ledger, or some other data repository. Although race condition attacks don’t happen frequently — because they’re relatively difficult to engineer and attackers must exploit a very brief window of opportunity — when they do happen, they can lead to serious repercussions, including a system granting unauthorized privileges. What’s more, race condition attacks are inherently difficult to detect.

Anatomy of an Race Condition Flaw

When a normal update to an application or database takes place — and names, numbers, or other data are changed to reflect the most current state of information — a cybercriminal could unleash a race condition attack. This is possible because the database isn’t completely rewritten during the update process. As the update takes place, a gap exists, one that can last less than a second or up to a few minutes, during which the system is unprotected. This allows attackers to gain unauthorized access. During this brief period, an attacker can send queries that compromise the system and result in a race condition attack.

Impact of a Race Condition Attack

Once an intruder has breached a system using a race condition attack, it’s possible to alter, manipulate, or steal data, make changes to privileges, insert malicious code, unleash a denial of service (DoS) attack, and deactivate security controls. A race condition attack can also encompass APIs. In one high profile case, the FBI reported that attackers used this methodology to steal more than $1 million from Citibank using cash advance ATM kiosks at casinos located in California and Nevada. The attackers sent near identical queries within a 60-second time window.

Race Condition Flaw Examples

Here’s an example of a race condition vulnerability :(

/* vulp.c */



#define DELAY 10000

int main()


char * fn = "/tmp/XYZ";

char buffer[60];

FILE *fp;

long int i;

/* get user input */

scanf("%50s", buffer );

if(!access(fn, W_OK)){

/* simulating delay */

Laboratory for Computer Security Education 2

for (i=0; i < DELAY; i++){

int a = iˆ2;


fp = fopen(fn, "a+");

fwrite("\n", sizeof(char), 1, fp);

fwrite(buffer, sizeof(char), strlen(buffer), fp);



else printf("No permission \n");


This example was created by Wenliang Du at Syracuse University. It is part of a Set-UID program (owned by root). The example appends a string of user input to the end of a temporary file /tmp/XYZ. Since the code uses the root privilege, it checks whether the user actually has access permission for the file /tmp/XYZ. In fact, this is the specific purpose of the access() call. Once the program has verified that the intended user has the privilege, the program opens the file and writes the user input into the file.

At first glance, the program appears to be sound. However, it contains a race condition vulnerability. Due to the window (the simulated delay) between the check (access) and the use (fopen), there is a possibility that the file used by access is different from the file used by fopen, despite the fact that they share the file name /tmp/XYZ. A malicious attacker who can make /tmp/XYZ a symbolic link pointing to /etc/shadow can cause the user input to be appended to /etc/shadow. The program runs with the root privilege and so it can overwrite any file.

Preventing Damage and Remediating Code Are Critical

It’s critical to scan and review code for race condition vulnerabilities. This includes the use of static analysis. Overall, SANS Technology Institute points out: “Careful programming and good administration practices usually can clear [race condition vulnerabilities] up, but you've got to find them first.” This means educating development teams about the risks of race condition attacks and how to prevent them.

Veracode Can Aid in the Removal of Race Condition Flaws

Veracode Web Application Scanning can safely, accurately, and quickly discover web application flaws, including race condition, in running web applications, in either production or pre-production environments.

Veracode Static Analysis can accurately identify race condition vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing race condition and other security flaws through integrated eLearning materials.

Secure Coding Handbook

Learn best practices from the pros at Veracode.

Get the Handbook



contact menu