CWE-768: Incorrect Short Circuit Evaluation
The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
Last updated
Overview
Usage of short circuit evaluation, though well-defined in the C standard, may alter control flow in a way that introduces logic errors that are difficult to detect, possibly causing errors later during the product's execution. If an attacker can discover such an inconsistency, it may be exploitable to gain arbitrary control over a system. If the first condition of an "or" statement is assumed to be true under normal circumstances, or if the first condition of an "and" statement is assumed to be false, then any subsequent conditional may contain its own logic errors that are not detected during code review or testing. Finally, the usage of short circuit evaluation may decrease the maintainability of the code.
Real-world CVEs
1 recorded CVEs are caused by CWE-768 (Incorrect Short Circuit Evaluation). The highest-severity and most recent are shown first. 1 new CWE-768 CVE has been recorded so far in 2026.
Common consequences
What can happen when CWE-768 is exploited.
Varies by Context
Affects: Confidentiality, Integrity, Availability
Widely varied consequences are possible if an attacker is aware of an unexpected state in the product after a conditional. It may lead to information exposure, a system crash, or even complete attacker control of the system.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-768, grouped by where in the lifecycle they apply.
Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.
How to detect it
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.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following function attempts to take a size value from a user and allocate an array of that size (we ignore bounds checking for simplicity). The function tries to initialize each spot with the value of its index, that is, A[len-1] = len - 1; A[len-2] = len - 2; ... A[1] = 1; A[0] = 0; However, since the programmer uses the prefix decrement operator, when the conditional is evaluated with i == 1, the decrement will result in a 0 value for the first part of the predicate, causing the second portion to be bypassed via short-circuit evaluation. This means we cannot be sure of what value will be in A[0] when we return the array to the user.
Vulnerable example
#define PRIV_ADMIN 0When compiled and run, the above code will output a privilege level of 1, or PRIV_REGULAR for every user but the user with id 0 since the prefix increment operator used in the if statement will reach zero and short circuit before setting the 0th user's privilege level. Since we used calloc, this privilege will be set to 0, or PRIV_ADMIN.
Terminology & mappings
Mapped taxonomies
- CLASP: Failure to protect stored data from modification
- Software Fault Patterns: Glitch in computation (SFP1)
Frequently asked questions
Common questions about CWE-768.
- What is CWE-768?
- The product contains a conditional statement with multiple logical expressions in which one of the non-leading expressions may produce side effects. This may lead to an unexpected state in the program after the execution of the conditional, because short-circuiting logic may prevent the side effects from occurring.
- What CVEs are caused by CWE-768?
- 1 recorded CVEs are attributed to CWE-768, including CVE-2026-35378.
- How do you prevent CWE-768?
- Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.
- How is CWE-768 detected?
- 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.)
- What are the consequences of CWE-768?
- Exploiting CWE-768 can lead to: Varies by Context.
- Is CWE-768 actively exploited?
- 1 recorded CVEs are caused by CWE-768; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-768) (opens in a new tab)
- CWE-768 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-768
Get alerted the moment a new CWE-768 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.