Make WordPress Core

Opened 22 months ago

Last modified 6 months ago

#55067 new enhancement

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

Reported by: maveloweb's profile maveloweb Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.9
Component: Security Keywords: has-patch 2nd-opinion
Focuses: Cc:


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::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.

Change History (12)

#1 @maveloweb
22 months ago

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

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

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

Version 0, edited 22 months ago by maveloweb (next)

#2 @maveloweb
22 months ago

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.

#3 @maveloweb
22 months ago

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

#4 @maveloweb
22 months ago

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.

#5 @maveloweb
22 months ago

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 😂

#6 @cr0ybot
20 months ago

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?

This ticket was mentioned in PR #3211 on WordPress/wordpress-develop by Michelleeby.

15 months ago

  • Keywords has-patch added

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:

#8 @FolioVision
6 months ago

Could you please finally accept the fix in ? It's 2 lines of code and it's taking 9 months to accept.


#9 @dd32
6 months ago

#58496 was marked as a duplicate.

nbcsteveb commented on PR #3211:

6 months ago

a more recent, non-conflicting version of this PR is here:

#11 @jorbin
6 months ago

  • Keywords close 2nd-opinion added

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

#12 @maveloweb
6 months ago

  • Keywords close removed

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.

Last edited 6 months ago by maveloweb (previous) (diff)
Note: See TracTickets for help on using tickets.