CWE-636 explained: when error handling fails open

CWE-636, Not Failing Securely, covers products that fall back to a weaker security state after an error even though a stronger option exists. Think of an access check that returns true when its lookup throws. It is a design choice more than a coding slip, which makes it easy to miss in review.

What MITRE says

The entry describes a product that reverts to a less secure state on failure, for example choosing a weak algorithm or applying overly permissive access control. The product inherits the weaknesses of that state, and administrators can be left with a false sense of security. The entry says this usually happens when developers choose to "fail functional" to reduce administration and support costs instead of failing safe.

It also notes that design flaws are rarely reported publicly, so most real examples come from implementation errors.

The network switch example

The demonstrative example in the entry is a switch that reverts to hub behavior when its address table overflows, broadcasting traffic where eavesdroppers can see it. The suggested fix is to cap entries per interface so one interface cannot exhaust the table for the others. Note the fix: contain the failure, do not let it spread.

Patterns to search for in code

These are my own review heuristics, not text from the entry.

1. A catch block that returns allow, true or an empty restriction list.
2. A timeout handler that continues the request.
3. A configuration parser that falls back to permissive defaults when a file is missing or malformed.
4. A feature that downgrades a cipher or protocol version when negotiation fails.
5. A policy check wrapped in a try that logs and moves on.

Each one is fine for a non-security feature and dangerous for a security control.

How to fix it

Make the secure state the default state. Set the error path to deny, then add explicit, logged exceptions where availability truly matters. Divide resources so one failing part cannot drag the others into a weak mode, as the entry's mitigations suggest. Use safe defaults for any configurable failure behavior.

Then prove it. Write a test that makes the dependency throw and asserts the request is refused.

How to spot it in production

Look at behavior during incidents. If error rates on a dependency rose and access denials did not, something may be failing open. Alert on the ratio, not just the error count.

Quick check

Sources

• CWE-636: Not Failing Securely ('Failing Open')

Last reviewed: 19 October 2026.