CWE-236 is the case where a product does not handle, or handles incorrectly, a parameter, field or argument name that it does not define or support.
Every parser meets input it was not written for. The question is whether the code has a deliberate answer for it.
How it happens
A protocol or API evolves. A peer sends a field the receiver has never seen, or sends a valid field in a context where it makes no sense. The receiver either assumes the field can never appear, or has a code path that was never exercised.
MITRE lists two observed cases:
- CVE-2002-1488: a crash in an IRC client through a PART message for a channel the user is not in.
- CVE-2001-0650: a router crash or bad route modification using BGP updates with an invalid transitive attribute.
Both involve input that was structurally allowed but unexpected.
What an attacker gains
The record lists integrity and an unexpected state. In the examples that meant a crash, which is a denial of service, and in the router case a changed route.
How to find it
The record names no detection methods. Useful checks include:
- Send fields and attributes your code does not define and watch what happens.
- Fuzz protocol messages with unknown names, types and values.
- Read the parser and look for any branch that assumes a name is always known.
How to fix it
The record has no mitigation list, so this is general practice.
- Have an explicit default branch for unknown names. Ignore them safely, or reject the message.
- Log the rejection so odd traffic is visible.
- Treat unknown attributes in network protocols as untrusted, not as impossible.
- Test with unknown inputs on every release.
Quick check
Should unknown parameters be ignored or rejected?
Either can be right. What matters is that the choice is deliberate and tested, so unknown input never reaches code that assumes it is known.
