CWE-480, Use of Incorrect Operator, covers the case where a product accidentally uses the wrong operator and changes the logic in security relevant ways. MITRE says these errors are generally a typo. It lists C, C++, Perl and notes the weakness is not language specific.
Typos sound harmless until the changed line is the one that decides whether a user may log in.
How it happens
Operators look alike and behave differently.
The assignment and comparison variants have their own entries: CWE-481, assigning instead of comparing, and CWE-482, comparing instead of assigning. This page covers the wider family, such as a wrong boolean operator or a loose comparison where a strict one was needed.
Two observed examples from the record, both described as chains. CVE-2022-3979: a data visualization program written in PHP uses the != operator instead of the type strict !== operator when validating hash values, which can lead to an incorrect type conversion. CVE-2021-3116: a Python based HTTP proxy server uses the wrong boolean operators, producing an incorrect comparison that identifies an authentication failure only if all three conditions are met instead of any one of them.
The PHP case is a good teaching example. Loose comparison converts types before comparing, so two different values can compare as equal.
<?php
// Vulnerable pattern: loose comparison of a hash
if ($expected != $supplied) {
deny();
}
<?php
// Fixed: type strict, and a timing safe compare for secrets
if (!hash_equals($expected, $supplied)) {
deny();
}
The boolean case is the same idea in logic form.
# Vulnerable: denies only if ALL three checks fail
if not user_ok and not pass_ok and not token_ok:
deny()
# Fixed: deny if ANY check fails
if not (user_ok and pass_ok and token_ok):
deny()
What an attacker gains
MITRE lists altered execution logic: unintended logic runs and the application behaves unexpectedly. In the examples above that meant bypassed validation and authentication.
How to find it
MITRE says this weakness can be found easily with static analysis, both automated and manual. It adds a caution: an operator can look wrong but actually be right, reflecting unusual logic in the program. A human has to judge the flagged lines.
Two cheap additions. Write unit tests for the failing side of every security check, not only the passing side. And ask reviewers to read each authentication condition aloud as a plain sentence.
How to fix it
The record lists no mitigations for this entry. Practical steps that follow from the detection advice: run a static analyzer and linter on every commit, use strict comparison operators in languages that offer them, and keep security conditions short enough to read at a glance.
Try it yourself
Run a code scan against a snippet with a loose comparison and see how it is reported.
Click through it at your own pace, or open it full screen.
Quick check
Why test the failing path of a check?
A wrong operator often passes every happy path test. Only a test with bad credentials or bad input shows that the check really denies.
Is every flagged operator a bug?
No. MITRE notes that an operator can look incorrect and still be correct. Review each hit.
