Opened 20 months ago
Last modified 4 months ago
#55067 new enhancement
Use of undefined constant ABSPATH - assumed 'ABSPATH' as of WP5.9
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.9 |
Component: | Security | Keywords: | has-patch 2nd-opinion |
Focuses: | Cc: |
Description
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.
Change History (12)
#2
@
20 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
@
20 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
@
20 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
@
20 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
@
17 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.
13 months ago
#7
- 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: https://core.trac.wordpress.org/ticket/55067
#8
@
4 months ago
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
nbcsteveb commented on PR #3211:
4 months ago
#10
a more recent, non-conflicting version of this PR is here: https://github.com/WordPress/wordpress-develop/pull/4585
#11
@
4 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
@
4 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.
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...
Will see if that causes other issues. If not, it's a simple operator workaround for apache :)