Direct access to wp-settings.php results in a fatal error due to undefined ABSPATH constant.

[matinlk]

When attempting to directly access wp-settings.php via a browser (e.g., navigating to https://example.com/wp-settings.php), a fatal error is triggered:

[16-Apr-2025 19:58:43 UTC] PHP Fatal error:  Uncaught Error: Undefined constant "ABSPATH" in /.../wp-settings.php:34

Stack trace:
#0 {main}
  thrown in /.../wp-settings.php on line 34

This occurs because ABSPATH is not defined unless wp-settings.php is loaded through wp-config.php.

Suggested Solution:

To avoid direct access and prevent such fatal errors, I recommend adding a conditional check at the top of the wp-settings.php file like this:

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

[dilipbheda]

I believe we can resolve this by including the following code to load the WordPress bootstrap files:

/** Ensure the WordPress bootstrap is loaded before proceeding. */
require __DIR__ . '/wp-load.php';

I've noticed similar usage in other core files like

• wp-comments-post.php
• wp-cron.php
• wp-login.php

[Presskopp]

I don't get a fatal. Depending on the permalink settings I get a 404 or 301. How can I reproduce the issue?

[dilipbheda]

@Presskopp, when you directly open the URL ​http://localhost:8889/wp-settings.php

Ref: ​https://tinyurl.com/2az6ezys

[Presskopp]

Replying to dilipbheda:

@Presskopp, when you directly open the URL ​http://localhost:8889/wp-settings.php

You're right, I had a typo in my url, I'm sorry.

[Presskopp]

related: #58987

[SirLouen]

Combined Bug Reproduction and Patch Test Report

Description

This report validates that the patch works as expected.

Patch tested: https://core.trac.wordpress.org/attachment/ticket/63303/63303.patch

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.4.6
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.4.6)
• Browser: Chrome 135.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Bug Reproduction

1. Open <sites_url>/wp-settings.php
2. 🐞Bug occurs

Expected Results

• No errors, white page.

Actual Results

1. ✅ Issue resolved with patch.

Additional Notes

Technically, all the root files include wp-load.php except for this one. And this has been historically. I wonder when this started happening, or if this has been for so long.

I'm not sure if this file has to be directly accessed like wp-cron.php or the liking. Since obviously wp-load.php is not required by this file I would rather suggest using classic a die alternative, instead of loading wp-load.php

Supplemental Artifacts

Attach better alternative 63303.2.patch as suggested by OP

[SirLouen]

Replying to sabernhardt:
Bruh, haven't you checked my last post?👎

[sabernhardt]

I just edited the formatting and filepath in the description and removed the version (because I could reproduce the error with WordPress 5.6, this is not new to 6.8).

[SirLouen]

Replying to sabernhardt:

I just edited the formatting and filepath in the description and removed the version (because I could reproduce the error with WordPress 5.6, this is not new to 6.8).

Ok, I saw a convoluted text with all the diff changes in my email digest, so I confused the message.

Btw, in the last couple of reports I've been observing that you only are posting suggestions, you can't attach reports to Milestones?

[sabernhardt]

I do not commit code changes, so ultimately any time I edit the milestone it is no more than a recommendation.

Back to the topic of this ticket, I do not have an opinion about exit/die() or wp_load.php. Also, other files might need to block direct access just as much as wp-settings.php (it is one of the files included on #62722).

[SirLouen]

Replying to sabernhardt:

Back to the topic of this ticket, I do not have an opinion about exit/die() or wp_load.php. Also, other files might need to block direct access just as much as wp-settings.php (it is one of the files included on #62722).

Great catch.
I advocate for triaging harder.

I do not commit code changes, so ultimately any time I edit the milestone it is no more than a recommendation.

Even a good milestone recommendation will bring attention and prob get more useful commits into cycles. Zillions of good patches are being lost in the space.
For example, if you can propose 6.8.2 to #62722, would be great.