The code does not have a default case in an expression with multiple conditions, such as a switch statement.
If a multiple-condition expression (such as a switch in C) omits the default case but does not consider or handle all possible values that could occur, then this might lead to complex logical errors and resultant weaknesses. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system.

Primary

Implementation

Integrity
Varies by Context
Alter Execution Logic
Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.

Automated Static Analysis
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.)
High

Implementation
Ensure that there are no cases unaccounted for when adjusting program flow or values based on the value of a given variable. In the case of switch style statements, the very simple act of creating a default case can, if done correctly, mitigate this situation. Often however, the default case is used simply to represent an assumed option, as opposed to working as a check for invalid input. This is poor practice and in some cases is as bad as omitting a default case entirely.

The following does not properly check the return code in the case where the security_check function returns a -1 value when an error occurs. If an attacker can supply data that will invoke an error, the attacker can bypass the security check:

#define FAILED 0#define PASSED 1int result;...result = security_check(data);switch (result) {
case FAILED:printf("Security check failed!\n");exit(-1);
//Break never reached because of exit()
break;
case PASSED:printf("Security check passed.\n");break;

}
// program execution continues...
...

Instead a default label should be used for unaccounted conditions:

#define FAILED 0#define PASSED 1int result;...result = security_check(data);switch (result) {
case FAILED:printf("Security check failed!\n");exit(-1);
//Break never reached because of exit()
break;
case PASSED:printf("Security check passed.\n");break;
default:printf("Unknown error (%d), exiting...\n",result);exit(-1);

}

This label is used because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling.

In the following Java example the method getInterestRate retrieves the interest rate for the number of points for a mortgage. The number of points is provided within the input parameter and a switch statement will set the interest rate value to be returned based on the number of points.

public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";...public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
switch (points) {
case 0:result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);break;
case 1:result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);break;
case 2:result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);break;

}return result;
}

However, this code assumes that the value of the points input parameter will always be 0, 1 or 2 and does not check for other incorrect values passed to the method. This can be easily accomplished by providing a default label in the switch statement that outputs an error message indicating an invalid value for the points input parameter and returning a null value.

public static final String INTEREST_RATE_AT_ZERO_POINTS = "5.00";public static final String INTEREST_RATE_AT_ONE_POINTS = "4.75";public static final String INTEREST_RATE_AT_TWO_POINTS = "4.50";...public BigDecimal getInterestRate(int points) {
BigDecimal result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);
switch (points) {
case 0:result = new BigDecimal(INTEREST_RATE_AT_ZERO_POINTS);break;
case 1:result = new BigDecimal(INTEREST_RATE_AT_ONE_POINTS);break;
case 2:result = new BigDecimal(INTEREST_RATE_AT_TWO_POINTS);break;
default:System.err.println("Invalid value for points, must be 0, 1 or 2");System.err.println("Returning null value for interest rate");result = null;

}
return result;
}

In the following Python example the match-case statements (available in Python version 3.10 and later) perform actions based on the result of the process_data() function. The expected return is either 0 or 1. However, if an unexpected result (e.g., -1 or 2) is obtained then no actions will be taken potentially leading to an unexpected program state.

result = process_data(data)
match result:
case 0:
print("Properly handle zero case.")
case 1:
print("Properly handle one case.")

# program execution continues...

The recommended approach is to add a default case that captures any unexpected result conditions, regardless of how improbable these unexpected conditions might be, and properly handles them.

result = process_data(data)
match result:
case 0:
print("Properly handle zero case.")
case 1:
print("Properly handle one case.")
case _:
print("Properly handle unexpected condition.")

# program execution continues...

In the following JavaScript example the switch-case statements (available in JavaScript version 1.2 and later) are used to process a given step based on the result of a calcuation involving two inputs. The expected return is either 1, 2, or 3. However, if an unexpected result (e.g., 4) is obtained then no action will be taken potentially leading to an unexpected program state.

let step = input1 + input2;
switch(step) {
case 1:
alert("Process step 1.");
break;
case 2:
alert("Process step 2.");
break;
case 3:
alert("Process step 3.");
break;

}
// program execution continues...

The recommended approach is to add a default case that captures any unexpected result conditions and properly handles them.

let step = input1 + input2;
switch(step) {
case 1:
alert("Process step 1.");
break;
case 2:
alert("Process step 2.");
break;
case 3:
alert("Process step 3.");
break;
default:
alert("Unexpected step encountered.");

}
// program execution continues...

The Finite State Machine (FSM) shown in the "bad" code snippet below assigns the output ("out") based on the value of state, which is determined based on the user provided input ("user_input").

module fsm_1(out, user_input, clk, rst_n);
input [2:0] user_input;
input clk, rst_n;
output reg [2:0] out;
reg [1:0] state;
always @ (posedge clk or negedge rst_n )

begin

if (!rst_n)

state = 3'h0;

else
case (user_input)

3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;

endcase

end
out <= {1'h1, state};

endmodule

The case statement does not include a default to handle the scenario when the user provides inputs of 3'h6 and 3'h7. Those inputs push the system to an undefined state and might cause a crash (denial of service) or any other unanticipated outcome.
Adding a default statement to handle undefined inputs mitigates this issue. This is shown in the "Good" code snippet below. The default statement is in bold.

case (user_input)
3'h0:
3'h1:
3'h2:
3'h3: state = 2'h3;
3'h4: state = 2'h2;
3'h5: state = 2'h1;
default: state = 2'h0;

endcase

Failure to account for default case in switch

SFP4
Unchecked Status Condition

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CLASP
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities

CWE Content Team
MITRE
2009-05-27
updated Description, Name

CWE Content Team
MITRE
2010-06-21
updated Demonstrative_Examples

CWE Content Team
MITRE
2011-03-29
updated Demonstrative_Examples

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-06-27
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated References, Relationships

CWE Content Team
MITRE
2014-06-23
updated Description, Other_Notes, Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Relationships

CWE Content Team
MITRE
2018-03-27
updated Relationships

CWE Content Team
MITRE
2019-01-03
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated References, Relationships, Type

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Relationships

Drew Buttner
MITRE
2022-08-15
Suggested name change and other modifications, including a new demonstrative example.

Failure to Account for Default Case in Switch
Failure to Use Default Case in Switch
Missing Default Case in Switch Statement