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.