CWE-232, Improper Handling of Undefined Values, applies when a product does not handle, or mishandles, a value that is not defined or not supported for a given parameter, field or argument name.
Clients and servers that exchange typed or enumerated values are the usual place: protocol fields, driver types, status codes, feature flags.
How it happens
The code handles the values it knows and assumes those are the only ones. When a new or unexpected value arrives, nothing in the code says what to do. MITRE's observed example is CVE-2000-1003: a client crashes when the server returns an unknown driver type.
// Vulnerable: no branch for unknown values
Driver d;
switch (type) {
case "mysql": d = new MySqlDriver(); break;
case "pg": d = new PgDriver(); break;
}
d.connect(); // NullPointerException if type is anything else
What an attacker gains
MITRE lists integrity: the product ends up in an unexpected state. In the example, the result was a client crash caused by a response from the server.
How to find it
MITRE lists no detection methods. Send values outside each documented set: an unknown enum, an unsupported type, an out-of-range code. Review switch and lookup statements for missing default branches.
How to fix it
MITRE gives no mitigations. A simple rule covers most cases: every decision on a value needs an explicit answer for values you do not recognize, and that answer should be to refuse safely.
switch (type) {
case "mysql": d = new MySqlDriver(); break;
case "pg": d = new PgDriver(); break;
default: throw new IllegalArgumentException("Unsupported driver type");
}
Catch that error at the boundary, report it cleanly, and keep the rest of the system running.
Quick check
Why not default to the most common value?
Guessing can move the product into a state the sender did not intend. Refusing is safer.
