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

  • Authentication module allows authentication bypass because it uses "(x = call(args) == SUCCESS)" instead of "((x = call(args)) == SUCCESS)".

  • Chain: Language interpreter calculates wrong buffer size (CWE-131) by using "size = ptr ? X : Y" instead of "size = (ptr ? X : Y)" expression.

  • 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. 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. 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. 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. 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. 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.

Plexicus Auto-Fix

Plexicus erkennt CWE-783 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.

Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.

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.

Bereit, wenn du es bist

Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.

Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.