The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition.
View on MITREThis can lead to critical code executing in situations where it should not.
This weakness can cause unintended logic to be executed and other unexpected application behavior.
Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities.
The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.
Omission of a break statement might be intentional, in order to support fallthrough. Automated detection methods might therefore be erroneous. Semantic understanding of expected product behavior is required to interpret whether the code is correct.
Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.
In both of these examples, a message is printed based on the month passed into the function:
Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.
In both of these examples, a message is printed based on the month passed into the function:
Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed.
No relationship information available for this CWE.
CWE-484: Omitted Break Statement in Switch is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product omits a break statement within a switch or similar construct, causing code associated with multiple conditions to execute. This can cause problems when the programmer only intended to execute code associated with one condition. This can lead to critical code executing in situations where it should not.
If exploited, CWE-484 (Omitted Break Statement in Switch) it can compromise Other, leading to outcomes such as Alter Execution Logic.
Recommended mitigations for CWE-484 include: Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities. The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.
CWE-484 can be detected using White Box and Black Box. Combining automated tooling with manual review typically yields the best coverage.
CWE-484 commonly affects C, C++, Java, C# and PHP. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
A CWE (Common Weakness Enumeration) like CWE-484 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.