CWE-186, Overly Restrictive Regular Expression, describes a pattern that is too narrow, so dangerous values are not detected.
MITRE is clear that this is not about complex patterns. It is about a pattern that does not match all the values you meant it to.
How it happens
MITRE's own example is tiny. Take the expression /[0-8]/ where the intention was /[0-9]/. It is simple, but the value 9 does not match. If the pattern spots unwanted values, you get a false negative. If it accepts valid values, you reject good input.
A real example from the record is CVE-2005-1604. A ".php.ns" file name bypassed a ".php$" pattern but was still parsed as PHP by Apache. The pattern assumed that only names ending in .php would run as PHP, and the web server's behavior disagreed.
What an attacker gains
MITRE lists bypass of a protection mechanism, an access control impact.
How to find it
The record lists no detection methods. In practice:
- Test every pattern against values at the edge of the intended set.
- Check what the downstream system accepts, not what you assume it accepts. Learn how the file handler, parser or server treats variants.
- Keep a list of values that must be caught and run it as a unit test.
How to fix it
These are general steps, as no mitigations are listed.
- Write down what the pattern should match, then test each member of that set.
- Where the pattern decides what is safe, flip the logic to an allowlist of what you know is safe.
- Align your filter with how the downstream system really interprets names.
Quick check
How is this different from an incorrect regex in general?
It is the specific case of a pattern that is too narrow, so values you meant to catch are never matched.
