Safeguard
Application Security•

CWE-484 Omitted Break Statement in Switch: Accidental Fallthrough

A missing break makes one case run the code of the next. Learn why fallthrough bugs are hard to tell from intent and how to make intent explicit.

Safeguard Security Team
2 min read

CWE-484, Omitted Break Statement in Switch, occurs when a switch or similar construct is missing a break, so code for more than one condition runs when only one was intended. MITRE lists C, C++, Java, C#, PHP and describes it as not language specific.

MITRE says this can lead to critical code executing in situations where it should not.

How it happens

In C style languages, a case keeps running into the next one until a break, return or similar exit.

// Vulnerable: ADMIN falls through into USER
switch (level) {
    case ADMIN:
        enableAdminTools();
        // missing break
    case USER:
        enableUserTools();
        break;
    case GUEST:
        enableReadOnly();
        break;
}

Here the admin case also enables user tools, which may be intended. Reorder the cases or add a new one in the wrong spot and a lower privilege path runs a higher privilege action.

The difficulty is that fallthrough is sometimes intentional. MITRE notes that omitting a break so one case falls into another is often indistinguishable from an error.

What an attacker gains

The record lists altered execution logic: unintended code runs and the application behaves unexpectedly. The impact depends on what the extra code does. The record has no observed CVEs.

How to find it

MITRE offers three views. White box review needs a human, since an omitted break might be deliberate and automated tools can be wrong about it. Black box testing cannot tell this from other errors with the same visible behavior. Automated static analysis can find some instances.

Compiler warnings for implicit fallthrough help here. Enable them and mark intended cases with the language's explicit fallthrough annotation or comment.

How to fix it

MITRE's advice has two parts.

  1. Avoid fallthrough. If you truly need it, document it clearly in the switch and examine all the logical possibilities.
  2. Where the goal is shared behavior, an if statement is clearer and much safer.
if (level == ADMIN) {
    enableAdminTools();
}
if (level == ADMIN || level == USER) {
    enableUserTools();
}
if (level == GUEST) {
    enableReadOnly();
}

Each privilege rule is now written out in one place.

Quick check

Why can't a tool simply flag every missing break?

Because some are intentional. A person must decide whether the fallthrough matches the expected behavior of the product.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.