Use of undefined constant ABSPATH - assumed 'ABSPATH' as of WP5.9

[maveloweb]

Having to sift through unnecessary WP error_log(s). They result from wannabe-hackers trying to find exploits by requesting various WP files directly.

One example, though it's occurring in multiple folders, creating 'error_log' files in each directory...

[02-Feb-2022 18:25:07 UTC] PHP Warning: Use of undefined constant ABSPATH - assumed 'ABSPATH' (this will throw an Error in a future version of PHP) in wp-includes/class-wp-http.php on line 11

if ( ! class_exists( 'Requests' ) ) {
        require ABSPATH . WPINC . '/class-requests.php';

        Requests::register_autoloader();
        Requests::set_certificate_path( ABSPATH . WPINC . '/certificates/ca-bundle.crt' );
}

Simple fix...

if ( defined('ABSPATH') && ! class_exists( 'Requests' ) ) {

Other files such as 'wp-includes/blocks/index.php' are also adding to the error logs since ABSPATH is not examined prior to use. Another easy fix, near the top of the script...

defined('ABSPATH') || exit;

While this is not technically a WP bug, it would improve operator ability to focus on legitimate problems if unnecessary entries were not being added to error_log in multiple directories.

[maveloweb]

Giving this a shot with a new .htaccess file in wp-includes, but unsure if anything in that folder is needed via direct URI access by WP core...

<Files *.*>
Order Deny,Allow
Deny from all
</Files> 

Will see if that causes other issues. If not, it's a simple operator workaround for apache :)

[maveloweb]

Disregard that possible solution, throwing 404s left and right in admin area browser console. Will try another edit and post results once I find rules that work better.

[maveloweb]

This seems to do the trick in wp-includes/.htaccess

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^%{HTTP_HOST} [NC]
RewriteRule . - [R=403,L]

Will post another update if problems are encountered.

Note: Yes we know the HTTP_REFERER can be spoofed :P

[maveloweb]

Small update...

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^%{HTTP_HOST} [NC]
RewriteRule . - [R=403,L]

To block empty referrers as well.

[maveloweb]

Been a few days since last edit and no more error_log entries related to direct-calls after blocking HTTP_REFERER that doesn't match HTTP_HOST. I'd call that a win 😂

[cr0ybot]

While you've been able to avoid these errors with custom htaccess rules, it does seem that this should be fixed with simple checks for defined constants as in your original ticket description.

I assume that by simply being named "index.php" the "wp-includes/blocks/index.php" file is getting hit by bot traffic, perhaps?

Security: Check for undefined constant ABSPATH.

When some WordPress core files are accessed directly, the WordPress environment has not loaded and this may result in warnings or errors. Though this is not the typical use case, when bots (or a curious person) crawl the site this results in error log noise. This patch includes checks in /wp-includes/class-wp-http.php and /wp-includes/blocks/index.php for the ABSPATH constant definition to help reduce this log noise.

Props maveloweb.

Trac ticket: https://core.trac.wordpress.org/ticket/55067

[FolioVision]

Could you please finally accept the fix in ​https://github.com/WordPress/wordpress-develop/pull/3211 ? It's 2 lines of code and it's taking 9 months to accept.

Thanks,
Martin

[dd32]

#58496 was marked as a duplicate.

a more recent, non-conflicting version of this PR is here: ​https://github.com/WordPress/wordpress-develop/pull/4585

[jorbin]

I think this is something that is best solved at a hosting level by preventing direct PHP file access to wp-includes rather than by changing WordPress. Putting a check in each file for ABSPATH seems like an unnecessary use of server resources.

Adding the close tag and looking for a second opinion before marking this as wontfix

[maveloweb]

Primarily due to comment #2, I remain an advocate for checking required constants.

I do not see how one, or even a few, calls to defined() can be considered a server resources problem.

[azaozz]

Replying to maveloweb:

<Files *.*>
Order Deny,Allow
Deny from all
</Files> 

This would probably work, but should be only for .php files. There re many .js and .css files there too.

[azaozz]

Replying to jorbin:

I think this is something that is best solved at a hosting level by preventing direct PHP file access to wp-includes

Yep I tend to agree. There aren't (shouldn't be) any "entry points" in /wp-includes, however the .js and .css files should be accessible by the web server.

As far as I see almost all PHP files there do not have "loose" PHP code in them, i.e. only contain functions and classes and don't do anything even when loaded directly. This is the proper "architectural design" for all .php files in /wp-includes (and generally for all "includes" directories as the name suggests; files there can only be "included" in other files, not accessed directly).

However wp-includes/blocks/index.php does not follow these simple design rules and includes "loose" PHP code that runs in the global scope. Thinking there are several "PHP architectural design" bugs there that need fixing. This will also prevent any output if that file is accessed directly, just like most of the files in /wp-includes.

[azaozz]

Related/follow-up: #60352.

Closing this ticket as suggested by @jorbin in favor of #60352. Thinking that fixing the underlying issue would be preferable.