Direct access to .php files in /wp-includes is not protected out of the box

[teo8976]

I can't believe I'm stumbling upon this in 2024.

To reproduce:

• fresh install of WordPress
• go to ​https://yourdomain.com/wp-includes/rss.php

Expected:
should give a "403 Forbidden" response

Observed:
actually executes /wp-includes/rss.php which results in an internal server error because of a call to an undefined function. The issue is not the error itself, it's the fact that a php file inside /wp-includes can be directly executed in the first place.

I know there are plugins that fix this and that I can fix it by creating an .htaccess file, but this should be secure and clean out of the box.

[SergeyBiryukov]

Hi there, welcome back to WordPress Trac!

Thanks for the ticket, we're already tracking this issue in #18546.

For a bit more context, errors like this are considered a server configuration issue rather than a security issue as per the ​Security FAQ:

Why are there path disclosures when directly loading certain files?
This is a server configuration problem. Never enable display_errors on a production site.

[teo8976]

we're already tracking this issue in #18546.

Not really. #18546 only talks about adding index.php in the directory, which prevents requesting /wp-includes or /wp-includes/ and (potentially, depending on server configuration, not in my case actually) getting a listing of the directory.

But that won't prevent a request to /wp-includes/any-existing-file.php (e.g. /wp-includes/rss.php) from directly executing php files in that directory that are only supposed to be included from other scripts. Which btw is also the potential security risk (although I hope you're already making sure that each of those files doesn't pose a security risk even if called from where it shouldn't be called).

errors like this are considered a server configuration issue

If you are talking about the errors being displayed because of display_errors, that's completely besides the point. The errors being displayed are not the issue. The issue is the php file being requested directly and executed, whether or not it triggers an error.

For example, if you request /wp-includes/pluggable.php, you will get a 200 response with a blank page, instead of a proper 404 page, and that is awfully wrong.

BTW I misspoke when I said:

Expected:
should give a "403 Forbidden" response

The correct response is a 404, with the pretty "page not found" page.
I am not allowed to edit the description of my own report??

[jorbin]

As pointed out previously, errors like this are a server configuration issue. If you would like a 403, 404 or even 418, you should configure your server to return it.

Marking as a duplicate of #36177, but it could also likely be considered a duplicate of #30806, #44700, #45773, #47154 and #48049 (and likely more).

Also, conversations can continue on closed tickets, there is no need to reopen if there is additional information to share.

[teo8976]

errors like this are a server configuration issue.

A server configuration issue in WordPress. I don't care what prefix you put before the word "issue", this is an issue that WordPress is responsible for.
It's not the responsibility of the user to figure out how to configure the server in the way that WordPress requires to function properly.

The installer should either create whatever configuration is necessary, or instruct the user to do so if it can't. If any such configuration is subject to possible user preferences (e.g. 404 vs 403, but I don't think that's the case here, this should be a 404), either choose a sensible default or ask the user to choose during the installation process.

Wordpress knows what urls correspond to valid pages and therefore it is responsible to make sure it doesn't responds with a 200 or show a blank page (and execute PHP files that are not supposed to be directly called, which is a potential security concern or at the very least could have all kinds of side effects), whether it does so from within PHP code, with a server configuration file that it makes sure to be in place, or in whatever way you see fit.

Also, note that I can configure my server to return a 404 response, but I cannot configure it to display WordPress's fancy 404 page.

I've never seen (in recent years) a framework that doesn't do this. It's unbelievable that I even need to argue that this is an issue.

Marking as a duplicate of #36177

That starts with

WordPress has some code that automatically creates a .htaccess file for users

When I installed wordpress, no .htaccess file was created at all. It's possible that initially I had some directory writing permission misconfigured, but I got no warning whatsoever about that, and no message was shown telling me that there was an option to create a .htaccess file, or that I should create one, nothing.