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.
CWE-484 Base Brouillon
Omitted Break Statement in Switch
This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code execution 'falls through' and unintentionally runs the logic for…
Définition
What is CWE-484?
This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code execution 'falls through' and unintentionally runs the logic for subsequent cases, leading to unexpected behavior.
A missing 'break' statement causes a switch block to fail its primary purpose: executing one distinct code path. Instead, it cascades from the matched case into the code for the cases below it. This 'fall-through' behavior is a common logic error that can bypass critical security checks, corrupt data, or trigger functions that should only run under specific conditions.
While some languages allow intentional fall-through for specific patterns, omitting 'break' by mistake is a frequent source of bugs. To prevent this, developers should adopt a defensive coding style, such as always adding a 'break' as the default action and using linter rules to flag missing statements. Explicitly commenting any intentional fall-throughs makes the code safer and more maintainable.
Impact réel
Real-world CVEs caused by CWE-484
Aucune référence CVE publique n'est liée à ce CWE dans le catalogue MITRE pour le moment.
Comment les attaquants l'exploitent
Parcours de l'attaquant étape par étape
- 1
Identifier un chemin de code qui traite des entrées non fiables sans validation.
- 2
Élaborer une charge utile qui exploite le comportement non sécurisé — injection, traversal, débordement ou abus de logique.
- 3
Délivrer la charge utile via une requête normale et observer la réaction de l'application.
- 4
Itérer jusqu'à ce que la réponse divulgue des données, exécute le code de l'attaquant ou élève les privilèges.
Exemple de code vulnérable
Vulnerable Java
In both of these examples, a message is printed based on the month passed into the function:
public void printMessage(int month){
switch (month) {
case 1: print("January");
case 2: print("February");
case 3: print("March");
case 4: print("April");
case 5: print("May");
case 6: print("June");
case 7: print("July");
case 8: print("August");
case 9: print("September");
case 10: print("October");
case 11: print("November");
case 12: print("December");
}
println(" is a great month");
} Exemple de code sécurisé
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Liste de contrôle de prévention
How to prevent CWE-484
- Implementation 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.
- Implementation The functionality of omitting a break statement could be clarified with an if statement. This method is much safer.
Signaux de détection
How to detect CWE-484
Since this weakness is associated with a code construct, it would be indistinguishable from other errors that produce the same behavior.
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.)
Plexicus détecte automatiquement CWE-484 et ouvre une PR de correction en moins de 60 secondes.
Codex Remedium analyse chaque commit, identifie cette faiblesse précise et livre une pull request prête à être relue avec le correctif. Pas de tickets. Pas de transferts.
Questions fréquentes Qu'est-ce que CWE-484 ?
Quelle est la gravité de CWE-484 ?
Quels langages ou plateformes sont affectés par CWE-484 ?
Comment puis-je prévenir CWE-484 ?
Comment Plexicus détecte et corrige CWE-484 ?
Où puis-je en savoir plus sur CWE-484 ?
Frequently asked questions
Qu'est-ce que CWE-484 ?
This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code execution 'falls through' and unintentionally runs the logic for subsequent cases, leading to unexpected behavior.
Quelle est la gravité de CWE-484 ?
MITRE évalue la probabilité d'exploitation comme Moyenne — l'exploitation est réaliste mais nécessite généralement des conditions spécifiques.
Quels langages ou plateformes sont affectés par CWE-484 ?
MITRE lists the following affected platforms: C, C++, Java, C#, PHP.
Comment puis-je prévenir CWE-484 ?
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.
Comment Plexicus détecte et corrige CWE-484 ?
Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-484 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.
Où puis-je en savoir plus sur CWE-484 ?
MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/484.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.
Faiblesses associées
Weaknesses related to CWE-484
CWE-710 Parent
Improper Adherence to Coding Standards
This weakness occurs when developers don't consistently follow established coding standards and best practices, which can introduce…
CWE-1041 Frère
Use of Redundant Code
This weakness occurs when a codebase contains identical or nearly identical logic duplicated across multiple functions, methods, or…
CWE-1044 Frère
Architecture with Number of Horizontal Layers Outside of Expected Range
This occurs when a software system is built with either too many or too few distinct architectural layers, falling outside a recommended…
CWE-1048 Frère
Invokable Control Element with Large Number of Outward Calls
This weakness occurs when a single function, method, or callable code block makes an excessively high number of calls to other objects or…
CWE-1059 Frère
Insufficient Technical Documentation
This weakness occurs when a software or hardware product lacks comprehensive technical documentation. Missing or incomplete details about…
CWE-1061 Frère
Insufficient Encapsulation
This weakness occurs when a software component exposes too much of its internal workings, such as data structures or implementation logic.…
CWE-1065 Frère
Runtime Resource Management Control Element in a Component Built to Run on Application Servers
This weakness occurs when an application built to run on a managed application server bypasses the server's high-level APIs and instead…
CWE-1066 Frère
Missing Serialization Control Element
This weakness occurs when a class or data structure is marked as serializable but lacks the required control methods to properly handle…
CWE-1068 Frère
Inconsistency Between Implementation and Documented Design
This weakness occurs when the actual code implementation deviates from the intended design described in its official documentation,…
Prêt quand vous l'êtes
Arrêtez de payer par développeur.
Commencez à fermer la boucle.
Plexicus est l'ASPM natif IA qui scanne, filtre, corrige, penteste et explique — de façon autonome. Développeurs illimités, dépôts illimités, actions IA à usage équitable. Vrai niveau gratuit, €269/mo annuel quand vous êtes prêt.