Make WordPress Core

Opened 2 years ago

Closed 3 months ago

#55067 closed enhancement (wontfix)

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

Reported by: maveloweb's profile maveloweb Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.9
Component: Security Keywords: has-patch
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 (15)

#1 follow-up: @maveloweb
2 years ago

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

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

Last edited 2 years ago by maveloweb (previous) (diff)

#2 @maveloweb
2 years 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
2 years 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
2 years 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
2 years 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
2 years 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.

20 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
11 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
11 months ago

#58496 was marked as a duplicate.

nbcsteveb commented on PR #3211:

11 months ago

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

#11 follow-up: @jorbin
11 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
10 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 10 months ago by maveloweb (previous) (diff)

#13 in reply to: ↑ 1 @azaozz
3 months ago

Replying to maveloweb:

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

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

#14 in reply to: ↑ 11 @azaozz
3 months ago

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.

#15 @azaozz
3 months ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Related/follow-up: #60352.

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

Note: See TracTickets for help on using tickets.