CWE-783 Base Draft Low likelihood

Operator Precedence Logic Error

This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or misapplying the rules of operator precedence.

Definition

What is CWE-783?

This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or misapplying the rules of operator precedence.

At its core, this is a programming mistake where the order in which operations are evaluated (like comparison before logical AND) doesn't match the developer's intent. For example, writing `if (x & 1 == 0)` might be intended to check if the least significant bit is zero, but due to precedence, it's actually evaluated as `if (x & (1 == 0))`, leading to an incorrect result. While this can manifest as a simple bug in non-critical code, it becomes a serious security flaw when it appears in security-critical decision points. A common and dangerous example is within authentication or authorization logic, where a flawed expression could incorrectly grant access or bypass a security check entirely, directly compromising the application's security.

Auswirkungen in der Praxis

Real-world CVEs caused by CWE-783

CVE-2008-2516

Authentication module allows authentication bypass because it uses "(x = call(args) == SUCCESS)" instead of "((x = call(args)) == SUCCESS)".
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.
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.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

1
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.
2
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.
3
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.
4
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.
5
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).

Verwundbares Codebeispiel

Vulnerable C

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.

Verwundbar C

#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;
  }

Sicheres Codebeispiel

Secure C

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.

Sicher C

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

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Präventions-Checkliste

How to prevent CWE-783

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

Erkennungssignale

How to detect CWE-783

SAST High

Führe statische Analyse (SAST) auf der Codebasis aus und suche im Datenfluss nach dem unsicheren Muster.

DAST Moderate

Führe dynamische Application-Security-Tests gegen den Live-Endpoint aus.

Runtime Moderate

Beobachte Runtime-Logs auf ungewöhnliche Exception-Traces, fehlerhafte Eingaben oder Versuche, Autorisierung zu umgehen.

Code review Moderate

Code Review: Markiere jeden neuen Code, der Eingaben von dieser Oberfläche ohne validierte Framework-Helper verarbeitet.

CWE-783

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Request AI Swarm Pentest

Häufig gestellte Fragen

Frequently asked questions

Was ist CWE-783?

This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or misapplying the rules of operator precedence.

Wie gravierend ist CWE-783?

MITRE stuft die Exploit-Wahrscheinlichkeit als niedrig ein — eine Ausnutzung ist selten, die Schwachstelle sollte aber dennoch behoben werden, sobald sie entdeckt wird.

Welche Sprachen oder Plattformen sind von CWE-783 betroffen?

MITRE lists the following affected platforms: C, C++.

Wie kann ich CWE-783 verhindern?

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

Wie erkennt und behebt Plexicus CWE-783?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-783 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-783?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/783.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-783

CWE-670 Parent

Bereit zu validieren, was zählt.

Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.

Pentest buchen

Operator Precedence Logic Error

What is CWE-783?

Real-world CVEs caused by CWE-783

Angreiferpfad Schritt für Schritt

Vulnerable C

Secure C

How to prevent CWE-783

How to detect CWE-783

Don't catalog this weakness. Prove it's reachable.

Frequently asked questions

Weaknesses related to CWE-783

Always-Incorrect Control Flow Implementation

Use of Incorrect Operator

Incorrect Block Delimitation

Omitted Break Statement in Switch

Reachable Assertion

Execution After Redirect (EAR)

Further reading

Bereit zu validieren, was zählt.

Prüfen Sie, ob AI Swarm Pentest zu Ihrer Umgebung passt.

Anfrage erhalten. Nächsten Schritt buchen.

Sample evidence handover

Server-Side Request Forgery in `webhooks/receiver`