CWE-790 is a class level weakness. It says a product receives data from an upstream component and either does not filter special elements or filters them incorrectly before passing the data to a downstream component.
Because it is a class, you will not usually meet it by name. It is the umbrella over narrower entries such as incomplete filtering (CWE-791) and the position-based variants that follow it in the catalog.
How it happens
A special element is a character or sequence that means something to the downstream component. A quote in SQL, an angle bracket in HTML, a slash in a file path, a semicolon in a shell. When data crosses from one component to another, those elements can change the meaning of the message.
Teams respond by writing a filter that removes or blocks the dangerous elements. Filters fail in a few repeatable ways:
- They skip some elements, so an unlisted one slips through.
- They handle only the first occurrence.
- They check only a certain position in the string.
- They run before another step that changes the data again.
Each pattern has its own entry beneath CWE-790, which is why this family exists.
def clean(s):
return s.replace("'", "") # drops quotes, ignores backslashes, comments, other forms
What an attacker gains
The MITRE record lists the consequence as integrity and an unexpected state. The real impact depends on the downstream component: injection into a query, a command, a page or a path. The record has no observed CVEs for this class entry, so look to the specific child weaknesses for concrete cases.
How to find it
- Map each place where data leaves your code for another interpreter, database, shell, renderer or file system.
- At each crossing, find out what the downstream component treats as special.
- Check whether the code removes characters by hand. Hand-written filters are the warning sign.
- Test with every special element, in multiple copies, in different positions and in different encodings.
How to fix it
The record offers no mitigations, so rely on well-established practice:
- Avoid filtering as the main control. Use the safe interface of the downstream component: parameterized queries, argument arrays for process calls, context-aware output encoding.
- Where you must validate, use an allowlist of what is permitted instead of a blocklist of what is not.
- Validate and encode at the right moment, as late as possible and for the destination context.
- Test the filter with hostile input, not only normal input.
Quick check
Why is a blocklist filter fragile?
It only stops the elements its author thought of. Anything missed, repeated or encoded differently gets through.
