Last updated April 29, 2012. Created by pwolanin on March 25, 2010.
Edited by Tor Arne Thune, Damien Tournoud, coltrane. Log in to edit this page.

Security advisories such as SA-CONTRIB-2010-027 and SA-CONTRIB-2010-030 have pointed out the risk of passing user input through regular expressions that use the /e flag which causes matches to be evaluated as PHP code.

Mistakes in escaping strings can lead to arbitrary code execution vulnerabilities - this will likely lead to total compromise of your Drupal site.

For this reason, the /e flag should be avoided as insecure. It is generally possible to instead use preg_replace_callback() to transform the matches and generate a replacement string while avoiding the risk that user input may be executed as PHP.

Looking for support? Visit the forums, or join #drupal-support in IRC.


This rule doesn't seem to handle escaped slashes (/) or using alternate delimiters - eg #.

I have a line like this, which is valid regex and doesn't specify any flags, but DrupalCS thinks it does because of the "/feed" part.

("/\/([^\/]+)\/feed.*$/", $feed_name, $matches);

I have the same issue, you solve this "bug" ?

[at]Killua99 ~~

I got the same issue with following statement

preg_match("/version\s*:\s*["\']([^"\']+)["\']/", $file_part, $matches)