This weakness occurs when a regular expression engine evaluates code embedded within a regex pattern or subject string, rather than treating the pattern as a…
This weakness occurs when a regular expression engine evaluates code embedded within a regex pattern or subject string, rather than treating the pattern as a literal string to match. If an attacker can control the regex pattern or the input being matched, they can inject code that executes with the privileges of the application. This is a high-severity flaw because regex is often assumed to be a safe, data-only operation.
Some programming languages and regex libraries support "code interpolation" or "eval-like" features within regex patterns — typically through special syntax that allows variables or expressions to be evaluated at pattern-compilation time. When user input flows into the regex pattern itself (rather than just the subject string being matched), an attacker can inject malicious code disguised as regex syntax. The regex engine then compiles and executes that code as part of pattern evaluation. Even in languages without explicit code-interpolation features, unsafe dynamic pattern construction combined with certain regex flags or modes can create similar risks.
Successful exploitation allows arbitrary code execution with the same privileges as the application. An attacker could read sensitive files, modify data, create backdoor accounts, or pivot to other systems. The impact is equivalent to a direct code-injection vulnerability, but it often goes undetected because developers assume regex operations are inherently safe and don't apply the same input-validation rigor they would to eval() or SQL queries.
import re
user_pattern = request.args.get('search_pattern')
text = "user data here"
# Dangerous: pattern comes directly from user input
result = re.search(user_pattern, text)Why it's vulnerable:
In Python, while the re module itself does not evaluate code within patterns, if the application uses eval() or similar constructs to build the pattern dynamically, or if it uses a regex library with code-interpolation features (like some Perl-compatible regex engines), user-controlled patterns can execute arbitrary code.
import re
user_pattern = request.args.get('search_pattern')
text = "user data here"
# Safe: escape the pattern so it's treated as literal text
escaped_pattern = re.escape(user_pattern)
result = re.search(escaped_pattern, text)<?php
$user_pattern = $_GET['pattern'];
$text = "user data here";
// Dangerous: pattern from user input passed to preg_replace with /e modifier
$result = preg_replace("/" . $user_pattern . "/e", "strtoupper('$1')", $text);
?>Why it's vulnerable:
The /e modifier (deprecated in PHP 5.5.0, removed in PHP 7.0.0) caused the replacement string to be evaluated as PHP code. If the pattern itself is user-controlled, an attacker can inject code that executes during regex processing.
<?php
$user_pattern = $_GET['pattern'];
$text = "user data here";
// Safe: escape the pattern and use preg_replace_callback instead of /e
$escaped_pattern = "/" . preg_quote($user_pattern, '/') . "/";
$result = preg_replace_callback($escaped_pattern, function($matches) {
return strtoupper($matches[0]);
}, $text);
?>re.escape() (Python) or preg_quote() (PHP) before compiling the pattern.
/e modifier in PHP preg_replace(), or any regex flag that enables code evaluation.
Look for unexpected code execution, unusual process spawning, or file modifications that correlate with regex-search requests. Check application logs for regex-related errors or warnings, and review any custom regex patterns in your codebase to confirm they do not originate from user input. If your application uses PHP with the /e modifier in preg_replace(), it is vulnerable and must be updated immediately.
