CWE-240 covers products that do not handle, or handle incorrectly, the case where two or more structural elements should be consistent but are not.
The textbook form is a message that says one thing about itself in one place and shows another in the data. A declared length that does not match the actual length. A count that does not match the items. A type tag that does not match the content.
How it happens
The parser reads the declared value and trusts it. It then allocates, copies or loops based on that number, never comparing it with what was really received.
MITRE's observed examples:
- CVE-2014-0160: the "Heartbleed" bug received an inconsistent length parameter, which enabled an out of bounds read and returned memory that could include private cryptographic keys and other sensitive data. MITRE records this as a chain with CWE-130 and CWE-126.
- CVE-2009-2299: a web application firewall consumed excessive memory when an HTTP request had a large Content-Length value but no POST data.
What an attacker gains
The record lists integrity, "varies by context" and an unexpected state. The two examples show the range: disclosure of memory contents in one, resource exhaustion in the other.
How to find it
The record names no detection methods. Practical options:
- Send inputs whose length, count and type fields disagree with the data.
- Fuzz the parser with mutated header fields.
- In code review, mark every place a received length is used and look for a comparison with the real size.
How to fix it
The record lists no mitigations. General steps:
- Never trust a declared length. Compare it with the number of bytes actually received before using it.
- Cap allowed sizes at a sensible maximum.
- Reject the input when fields disagree, and log it.
- Keep protocol libraries current. Heartbleed lived in a widely used library, which is why knowing what you ship matters. A free scan at gold.safeguard.sh/scan runs in the browser with no login, keeps your file on your machine, and covers up to 100 dependencies.
Why length fields deserve suspicion
Of all the fields that can disagree with their data, lengths are the most dangerous, because code uses them to decide how much to read, copy or allocate. A length that is too large pulls in memory the sender never supplied. That is the pattern MITRE records for Heartbleed, where an inconsistent length parameter led to an out of bounds read.
The second example runs the other way. A large Content-Length with no body made a firewall consume excessive memory. The code reserved space for data that never came. Both cases come from the same mistake: acting on a declaration before checking it against reality.
A useful review habit is to find every integer in a message format that describes another part of the message, and write next to it the check that ties it to the real data. If the check does not exist, you have found the bug.
Quick check
What made Heartbleed an inconsistent element problem?
The request carried a length value that did not match the real data length, and the code trusted the declared number.
