err 500 after upgrade to 50.2

I changed htaccess on root folder to default and remove htaccess file from wp-admin folder

I have this error on log:

[Tue Jul  1 09:21:49 2014] [alert] [client XXX.XXX.XXX.XXX] /home/www/.htaccess: RewriteCond: cannot compile regular expression '\\/+(\\*|%2a)+(%20|\\s){1,}+HTTP+(:/|/)'\n

[Tue Jul  1 10:22:03 2014] [alert] [client XXX.XXX.XXX.XXX] /home/www/wp-admin/.htaccess: RewriteCond: cannot compile regular expression '\\/+(\\*|%2a)+(%20|\\s){1,}+HTTP+(:/|/)'\n

I commented the two lines in the htaccess files from the root and wp-admin folders, and the 50.2 has work good… What do these lines?

# RewriteCond %{THE_REQUEST} \?+(%20{1,}|[^\s])+HTTP+(:/|/) [NC,OR]
# RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}+HTTP+(:/|/) [NC,OR]

Looks like your particular server or mod_security cannot process this line of .htaccess code.
RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}+HTTP+(:/|/) [NC,OR]

The other new line of code is being processed by your particular server or mod_security.

These 2 new security filters are replacements for these old security filters that were problematic.

RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]

If you want to experiment and find out exactly which part of the code your particular server or mod_security cannot process then you could remove parts of the security code until you find out which part of the code your particular server or mod_security cannot process correctly or you can just leave the 1 security rule commented out or just use the old security rule. This security rule is not that important so you can just leave it commented out.

This seems like a very isolated issue with a particular mod_security SecRule/SecFilter. We created step by step instructions in this forum topic https://forum.ait-pro.com/forums/topic/error-500-and-unable-to-access-admin/#post-15909 for how to make this change in BPS Custom Code to save the change permanently.

This is an isolated host/server specific problem with a mod_security SecRule/SecFilter on that host/server. Custom Code steps provided in the link above resolve the issue.

I found a solution. The problem in expression
(20%|\s){1}.

The following two lines of the original and modified

# RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}+HTTP+(:/|/) [NC,OR]
RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s)+HTTP+(:/|/) [NC,OR]

IMHO these expressions are the same

(20%{1,}|[^\s])+
(20%|[^\s])+

following lines?

# RewriteCond %{THE_REQUEST} \?+(%20{1,}|[^\s])+HTTP+(:/|/) [NC,OR]
RewriteCond %{THE_REQUEST} \?+(%20|[^\s])+HTTP+(:/|/) [NC,OR]

Great! You can add that solution to BPS Custom Code for your particular server/website.

Copy the entire section of BPS Query String Exploits code from your root .htaccess file and paste it into this Root Custom Code text box: CUSTOM CODE BPSQSE BPS QUERY STRING EXPLOITS

Click the Save Root Custom Code button.

Copy the entire section of BPS Query String Exploits code from your wp-admin .htaccess file and paste it into this wp-admin Custom Code text box: CUSTOM CODE BPSQSE-check BPS QUERY STRING EXPLOITS AND FILTERS

Click the Save wp-admin Custom Code button.

Go to the Security Modes page, click the Create secure.htaccess file AutoMagic button and activate Root BulletProof Mode and wp-admin BulletProof mode.

{1,} means match 1 or more of the previous things. What I suspect is happening is that you have a mod_security SecRule or SecFilter that is also checking for this particular exploit and the BPS Security filter is actually triggering mod_security into seeing an exploit taking place due to the way mod_security processes code.

It could of course be something else that just cannot process that particular Regex code. So far there have only been 2 cases of this particular issue out of 40,000+ upgrades (BPS Pro 9.0 + BPS .50.2) total.

Hm. I think that the + and {1,} is the same. Is not true?

This line also works fine:

# RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}+HTTP+(:/|/) [NC,OR]
RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}HTTP+(:/|/) [NC,OR]

Yes, you are correct. I believe that the extra “+” sign after {1,} is a technical mistake that should be corrected since it is redundant. Also technically the forward slashes (:/|/) should be escaped to be code correct.

Both of these lines would match the exact same pattern.

RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s){1,}HTTP+(:\/|\/) [NC,OR]
RewriteCond %{THE_REQUEST} \/+(\*|%2a)+(%20|\s)+HTTP+(:\/|\/) [NC,OR]

And “http” should either be put into a group or just use .* instead. Looks like this filter needs more work. ??

\/+(\*|%2a)+(%20|\s){1,}HTTP.*(:\/|\/)

Argh. Yep, I have confirmed that signals got crossed and the security rule/filter was supposed to be…

\/+(\*|%2a)+(%20|\s)+HTTP(:\/|\/)