CWE-440, Expected Behavior Violation, is simple to state. A feature, API or function does not perform according to its specification.
Callers trust the documented contract. If the implementation drifts from it, every caller inherits the gap.
How it happens
The cause is any mismatch between spec and code: a misread requirement, a shortcut, an unhandled edge case, or an inconsistency between two implementations of the same idea. MITRE's observed examples include:
- CVE-2003-0187: a program used large timeouts on unconfirmed connections because of an inconsistency in linked list implementations.
- CVE-2003-0465: strncpy in the Linux kernel acts differently from libc on x86.
MITRE also shows a hardware example from the Hack@DAC 21 OpenPiton SoC, where a RISC-V register module has to implement registers according to the specification.
What an attacker gains
The record lists quality degradation, varying by context. What an attacker gets depends on what the broken behavior guarded. If a boundary or a check was part of the spec, they get past it.
How to find it
Compare behavior against the written specification. Write tests from the spec, not from the implementation, and include edge cases and error paths. Differential testing against a reference implementation can expose differences quickly.
How to fix it
MITRE lists no formal mitigations. Practical steps:
- Keep a clear, testable specification.
- Turn each security-relevant sentence in the spec into a test.
- Review code against the spec, especially for parsing, limits and timeouts.
Quick check
How is this different from a plain bug?
A specification exists and the code departs from it. That makes the gap measurable, which is why spec-driven tests catch it well.
