CWE-797 is the second child of CWE-795. The product accounts for special elements only at an absolute position, for example byte number 10, and misses special elements elsewhere in the data.
How it happens
Fixed-offset checks come from fixed-format thinking. The developer knows the first 12 bytes are a header, or that a field sits at a set position, and checks only that.
/* validates the character at offset 10 only */
if (buf[10] == '/' || buf[10] == '\\')
return -1;
process(buf);
Real data rarely stays where the author expects. Variable-length fields, different encodings and attacker-chosen padding move things around. Put the dangerous element at offset 9 or 11 and the check never sees it.
What an attacker gains
The record lists integrity and an unexpected state, and no observed CVEs. The unfiltered elements reach the downstream component with their meaning intact.
How to find it
- Look for index-based checks, fixed offsets and magic numbers in validation code.
- Ask what happens when the data is shifted by a few bytes or when a field is longer than expected.
- Fuzz the input by inserting special elements at every position.
How to fix it
- Validate the entire input. A full-length scan costs very little.
- Parse the structure properly, then validate each field's content.
- Enforce length limits so offsets cannot be pushed around.
- Use encoding or binding at the destination, and write tests that place each special element at every position.
Quick check
Why do fixed offsets fail?
Attackers control the layout of their own input, so they can place dangerous elements anywhere the check does not look.
