The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.
View on MITRESome regular expression engines have a feature called "backtracking". If the token cannot match, the engine "backtracks" to a position that may result in a different token that can match. Backtracking becomes a weakness if all of these conditions are met: The number of possible backtracking attempts are exponential relative to the length of the input. The input can fail to match the regular expression. The input can be long enough. Attackers can create crafted inputs that intentionally cause the regular expression to use excessive backtracking in a way that causes the CPU consumption to spike.
Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Limit the length of the input that the regular expression will process.
No detection method information available for this CWE.
This example attempts to check if an input string is a "sentence" [REF-1164].
The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:
This example attempts to check if an input string is a "sentence" [REF-1164].
The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:
This example attempts to check if an input string is a "sentence" and is modified for Perl [REF-1164].
The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:
This example attempts to check if an input string is a "sentence" and is modified for Perl [REF-1164].
The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
View Detailsnpm package for user-agent parser prone to ReDoS due to overlapping capture groups
View DetailsMarkdown parser uses inefficient regex when processing a message, allowing users to cause CPU consumption and delay preventing processing of other messages.
View DetailsLong string in a version control product allows DoS due to an inefficient regex.
View DetailsJavascript code allows ReDoS via a long string due to excessive backtracking.
View DetailsNo relationship information available for this CWE.
CWE-1333: Inefficient Regular Expression Complexity is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. Some regular expression engines have a feature called "backtracking". If the token cannot match, the engine "backtracks" to a position that may result in a different token that can match. Backtracking becomes a weakness if all of these conditions are met: The number of possible backtracking attempts are exponential relative to the length of the input. The input can fail to match the regular expression. The input can be long enough. Attackers can create crafted inputs that intentionally cause the regular expression to use excessive backtracking in a way that causes the CPU consumption to spike.
If exploited, CWE-1333 (Inefficient Regular Expression Complexity) it can compromise Availability, leading to outcomes such as DoS: Resource Consumption (CPU).
Recommended mitigations for CWE-1333 include: Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers. Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process. Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
CWE-1333 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-1333, including CVE-2020-5243, CVE-2021-21317, CVE-2019-16215, CVE-2019-6785 and CVE-2019-12041. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-1333 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.