CWE-115, Misinterpretation of Input, is a broad base weakness. The product misinterprets an input, whether it comes from an attacker or from another product, in a security relevant way.
This is the "we read it differently than you meant it" family. It shows up wherever two components must agree on what data means, such as one product importing another's settings, or a filter and a consumer parsing the same message.
How it happens
MITRE's two observed examples are small but telling:
- CVE-2005-2225: a product saw a dangerous file extension in the free text of a group discussion and disconnected all users.
- CVE-2001-0003: a product did not correctly import and process security settings from another product.
The first is a false alarm turned into an outage: text was read as a file name. The second is the opposite risk, where security settings are silently misread and weaker rules apply than the administrator thought.
What an attacker gains
MITRE lists an unexpected state with an impact on integrity. The product behaves in a way nobody designed, and the attacker chooses the input that triggers it.
How to find it
MITRE recommends fuzzing: generating large numbers of diverse inputs, randomly or algorithmically, and running the code with them. Fuzzing suits this weakness because misreadings tend to be surprises that no one wrote a test for. Add review of every place where your code consumes another system's format, and test with deliberately odd but legal inputs.
How to fix it
MITRE's record lists no mitigation for this entry, so treat it as a design habit. Define input formats precisely, parse them once in one place, and have every consumer use the parsed result. When importing settings from another product, check the result against the source and fail loudly on anything you cannot map.
Quick check
Why is fuzzing a good fit?
Misinterpretation bugs come from inputs nobody thought of. Fuzzing produces many unexpected inputs and watches what the code does.
