The product uses an expression in which operator precedence causes incorrect logic to be used.
While often just a bug, operator precedence logic errors can have serious consequences if they are used in security-critical code, such as making an authentication decision.

Primary

Implementation
Logic errors related to operator precedence may cause problems even during normal operation, so they are probably discovered quickly during the testing phase. If testing is incomplete or there is a strong reliance on manual review of the code, then these errors may not be discovered before the software is deployed.

Low

Confidentiality
Integrity
Availability
Varies by Context
Unexpected State
The consequences will vary based on the context surrounding the incorrect precedence. In a security decision, integrity or confidentiality are the most likely results. Otherwise, a crash may occur due to the software reaching an unexpected state.

Automated Static Analysis
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.)
High

Implementation
Regularly wrap sub-expressions in parentheses, especially in security-critical code.

In the following example, the method validateUser makes a call to another method to authenticate a username and password for a user and returns a success or failure code.

#define FAIL 0#define SUCCESS 1
...
int validateUser(char *username, char *password) {

int isUser = FAIL;

// call method to authenticate username and password

// if authentication fails then return failure otherwise return success
if (isUser = AuthenticateUser(username, password) == FAIL) {return isUser;}else {isUser = SUCCESS;}
return isUser;
}

However, the method that authenticates the username and password is called within an if statement with incorrect operator precedence logic. Because the comparison operator "==" has a higher precedence than the assignment operator "=", the comparison operator will be evaluated first and if the method returns FAIL then the comparison will be true, the return variable will be set to true and SUCCESS will be returned. This operator precedence logic error can be easily resolved by properly using parentheses within the expression of the if statement, as shown below.

...
if ((isUser = AuthenticateUser(username, password)) == FAIL) {
...

In this example, the method calculates the return on investment for an accounting/financial application. The return on investment is calculated by subtracting the initial investment costs from the current value and then dividing by the initial investment costs.

public double calculateReturnOnInvestment(double currentValue, double initialInvestment) {

double returnROI = 0.0;

// calculate return on investment
returnROI = currentValue - initialInvestment / initialInvestment;
return returnROI;
}

However, the return on investment calculation will not produce correct results because of the incorrect operator precedence logic in the equation. The divide operator has a higher precedence than the minus operator, therefore the equation will divide the initial investment costs by the initial investment costs which will only subtract one from the current value. Again this operator precedence logic error can be resolved by the correct use of parentheses within the equation, as shown below.

...
returnROI = (currentValue - initialInvestment) / initialInvestment;
...

Note that the initialInvestment variable in this example should be validated to ensure that it is greater than zero to avoid a potential divide by zero error (CWE-369).

CVE-2008-2516
Authentication module allows authentication bypass because it uses "(x = call(args) == SUCCESS)" instead of "((x = call(args)) == SUCCESS)".
https://www.cve.org/CVERecord?id=CVE-2008-2516

CVE-2008-0599
Chain: Language interpreter calculates wrong buffer size (CWE-131) by using "size = ptr ? X : Y" instead of "size = (ptr ? X : Y)" expression.
https://www.cve.org/CVERecord?id=CVE-2008-0599

CVE-2001-1155
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
https://www.cve.org/CVERecord?id=CVE-2001-1155

EXP00-C
Use parentheses for precedence of operation
Exact

EXP04-PL
Do not mix the early-precedence logical operators with late-precedence logical operators
CWE More Abstract

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CWE Content Team
MITRE
2009-07-16
1.5
2009-07-27

CWE Content Team
MITRE
2009-12-28
updated Observed_Examples

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Demonstrative_Examples, References, Relationships

CWE Content Team
MITRE
2017-11-08
updated Taxonomy_Mappings, Time_of_Introduction

CWE Content Team
MITRE
2019-01-03
updated Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Type

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Detection_Factors, Weakness_Ordinalities