Opened 7 years ago
Closed 13 months ago
#41999 closed enhancement (wontfix)
/wp-includes/theme-compat/embed.php causes unnecessary errors in request log
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.8.2 |
Component: | Embeds | Keywords: | close |
Focuses: | Cc: |
Description (last modified by )
FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to undefined function get_header() in [...]/wp-includes/theme-compat/embed.php on line 13"
It's being called directly: "GET /wp-includes/theme-compat/embed.php HTTP/1.1"
Of course people shouldn't, but they do, for a purpose: to derive certain information or find vulnerabilities.
It also clutters error logs, which may cause real errors to get missed.
Other WP include and plugin files that contain direct code (rather than only function/class definitions), have a catch for this:
if ( ! defined( 'ABSPATH' ) ) { exit; // Exit if accessed directly. }
I suggest this gets added to the top of the /wp-includes/theme-compat/embed.php file.
Easy fix.
thanks
Change History (5)
#1
@
7 years ago
- Description modified (diff)
- Keywords close added
- Type changed from defect (bug) to enhancement
#3
@
6 years ago
@swissspidy
.htaccess is a hug performance drain and it's usage is strongly discouraged upon by Apache 2.4 plus nginx doesn't even support the construct. So if this file is a common foot printing vector why not fix this in the file?
#4
@
6 years ago
This is not unique to embed.php
though. One could just as well try to access wp-includes/default-filters.php
and get a similar warning. The only real way to prevent this is in the server settings. Turning off error display and direct access to PHP files can be done in both Apache and nginx.
#5
@
13 months ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
Hello @arjenlentz,
Welcome back to WordPress Core. I'm following up on older close candidate tickets to help resolve them. For this ticket, I'm closing it as wontfix
(with explanation). However, if there's more information available today that can help to further enlighten the use case, risks, and benefits, please reopen.
tl;dr
IMO this use case seems to be an instance of doing it wrong and the fatal error thrown is the expected behavior and outcome.
Longer explanation:
It's being called directly: "GET /wp-includes/theme-compat/embed.php HTTP/1.1"
Of course people shouldn't, but they do, for a purpose: to derive certain information or find vulnerabilities.
It also clutters error logs, which may cause real errors to get missed.
The scenario shared is not normal use case, but rather an intentional action as noted. Thus, the errors thrown are valid as these fatals prevent further processing.
For example, someone seeking to derive information by directly loading the embed.php
file will get a fatal error at the start of the file's load. No information other than a fatal for get_header()
happens.
As @swissspidy shared, this is not unique to embed.php
. Many files are not meant to be directly loaded as they have dependencies to other code. Loading them before that other code gets loaded will cause a fatal error.
This particular file is designed in a theme-way, by-design for classic themes to model. All the files in the wp-includes/theme-compat/
directory are template files which get loaded into memory when a classic theme does not have the file. None are meant to be directly loaded.
Only some files include such checks, not all.
IMHO this is something that should be prevented on the web server level using
.htaccess
or similar.