CWE-478: Missing Default Case in Multiple Condition Expression

Extended Description

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.

Code Examples & CVEs

Demonstrative Examples

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:

Instead a default label should be used for unaccounted conditions:

BadC

#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:

GoodC

#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);                                               }

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.

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.

BadJava

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;                      }

GoodJava

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.

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.

BadPython

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.

GoodPython

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.

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

BadJavaScript

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.

GoodJavaScript

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").

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.

BadVerilog

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 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").

GoodVerilog

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

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-478 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-478, Missing Default Case in Multiple Condition Expression, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Missing Default Case in Multiple Condition Expression during Implementation

MITRE associates mitigation with Implementation; documented detection approaches include Automated Static Analysis; recorded impacts include Varies by Context, and Alter Execution Logic. Use these source-defined anchors to turn CWE-478 into implementation, review, and verification checks for the affected component.

CWE-478: Missing Default Case in Multiple Condition Expression — MITRE CWE

Triage CWE-478 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-478, Missing Default Case in Multiple Condition Expression, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-478

Apply MITRE's full root-cause mapping guidance when using CWE-478, Missing Default Case in Multiple Condition Expression. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-478 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-478, Missing Default Case in Multiple Condition Expression. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-478: Missing Default Case in Multiple Condition Expression?+

CWE-478: Missing Default Case in Multiple Condition Expression is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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.

What are the security consequences of Missing Default Case in Multiple Condition Expression?+

If exploited, CWE-478 (Missing Default Case in Multiple Condition Expression) it can compromise Integrity, leading to outcomes such as Varies by Context and Alter Execution Logic.

How do you prevent or mitigate Missing Default Case in Multiple Condition Expression?+

Recommended mitigations for CWE-478 include: 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.

Which programming languages are affected by Missing Default Case in Multiple Condition Expression?+

CWE-478 commonly affects C, C++, Java, C#, Python and JavaScript. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-478 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.

CWE-478: Missing Default Case in Multiple Condition Expression

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Phase

Description

Detection Methods