[wp-trac] [WordPress Trac] #53271: How to stop direct access wp-includes files

[WordPress Trac]

#53271: How to stop direct access wp-includes files
----------------------------+------------------------
 Reporter:  classicalrehan  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  General         |     Version:  5.7.1
 Severity:  critical        |  Resolution:  duplicate
 Keywords:                  |     Focuses:
----------------------------+------------------------
Changes (by SergeyBiryukov):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  I18N => General
 * milestone:  Awaiting Review =>


Old description:

> Hi Team,
>
> I am getting 500 error due to WordPress loopholes,
> if someone trying to access directly this file then it's generating 500
> error because in these below file wp extend another class "Walker"
> without checking ABSPATH
>
> if ( ! defined( 'ABSPATH' ) ) {
>         exit; // Exit if accessed directly
>     }
>
> File: wp-includes/class-walker-nav-menu.php
> File: wp-includes/class-walker-comment.php
> File: wp-includes/class-walker-category-dropdown.php
>
> The walker class include in wp via wp-settings.php but in my case user
> are directly access file

New description:

 Hi Team,

 I am getting 500 error due to WordPress loopholes,
 if someone trying to access directly this file then it's generating 500
 error because in these below file wp extend another class "Walker" without
 checking ABSPATH
 {{{
 if ( ! defined( 'ABSPATH' ) ) {
         exit; // Exit if accessed directly
     }
 }}}
 File: wp-includes/class-walker-nav-menu.php
 File: wp-includes/class-walker-comment.php
 File: wp-includes/class-walker-category-dropdown.php

 The walker class include in wp via wp-settings.php but in my case user are
 directly access file

--

Comment:

 Hi there, welcome back to WordPress Trac! Thanks for the report.

 This has come up a few times before, for example in #36177, #30806,
 #44700, #45773, and most recently in #48049.

 Per the [https://make.wordpress.org/core/handbook/testing/reporting-
 security-vulnerabilities/ Security FAQ], these errors are considered a
 server configuration issue rather than a security issue:
 > ''' Why are there path disclosures when directly loading certain
 files?'''
 > This is a server configuration problem. Never enable `display_errors` on
 a production site.

 Instead of changing all PHP files to add a check for `ABSPATH`, this
 should be done in a central location, which is being discussed in #36177.

 Let's continue the discussion in that ticket, as it would be best to keep
 all discussion on the general idea of "blocking malicious requests" in a
 single place, even if any implemented change does not necessarily follow
 how the ticket originally intended on it being implemented.

 That said, it looks like this ticket is more about unnecessary error
 logging rather than a path disclosure. Still, blocking direct access to
 the files in question using the web server configuration file should
 resolve the issue for now, until any changes are implemented in core.

 See also a related similar ticket for bundled themes: #47154.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53271#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform