Default .htaccess config creates rewrite infinite loops for path-based multisite installations

[rob006]

Default .htaccess config for path-based multisite installations looks like that:

RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L] 

The problem is in these lines:

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

? sign makes expression ([_0-9a-zA-Z-]+/) optional, so rule works also for request like http://example.com/wp-config/file.png and basicly try to internal redirect request to the same address. If file does not exist, it creates infinite internal loops that causes internal server errors.

There is no sense create rewrite rules for main site of network and site prefix should no be optional for rewrites. Correct .htaccess content should be:

RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

[lisota]

This appears to be the same issue as https://core.trac.wordpress.org/ticket/20746.

That bug has been active for 4 years already and is easily reproduced. @johnbillion, is there a particular core committer that might be able to look at this issue with multisite rewrite rules?

[johnjamesjacoby]

Hey everyone!

IIRC, the reason these rules are lenient is because of TinyMCE, namely wp-includes/js/tinymce/wp-tinymce.php. This file is requested directly by the browser via an iframe, hence it needs to be open-world executable.

If not for that, I believe all of wp-includes could be denied completely, which would simplify these rules a bit, and allow them to be more specific.

I agree that the solution for #20746 looks like it would address this issue, too, but I'm afraid to close this ticket without a more confident fix on that one. And, if it turns out the fix is somewhat unrelated, we've accidentally confused our future selves, so I'm in favor of leaving this ticket open, at least until we've more deeply confirmed the relationship between them.

[thomaswm]

Replying to lisota:

This appears to be the same issue as https://core.trac.wordpress.org/ticket/20746.

You're right. This ticket is a duplicate of #20746.