Harden handling of PHP superglobals to prevent notices and potential data integrity issues

[vishalkakadiya]

WordPress core relies on several values from PHP superglobal variables. In some cases, these values are accessed directly without first verifying their existence or applying proper sanitization. This can lead to potential security data integrity concerns and PHP notices.

This pull request addresses a subset of these issues by adding appropriate existence checks and sanitization to ensure safer and more robust handling of superglobal data.

### Detail

WordPress core relies on several values from PHP superglobal variables. In some cases, these values are accessed directly without first verifying their existence or applying proper sanitization. This can lead to potential security concerns and PHP notices.

This pull request addresses a subset of these issues by adding appropriate existence checks and sanitization to ensure safer and more robust handling of superglobal data.

@sabernhardt I have reverted that suggested changes now.

[mukesh27]

@vishalkakadiya Could you please address review feedback so we can process to commit.

[vishalkakadiya]

@mukesh27 I have addressed the feedback now. Thank you!

There's not actually any security hardening here, is there? The introduction of wp_unslash() simply prevents erroneous backslashes from showing up (as WP adds them to $_SERVER for back-compat reasons).

There's not actually any security hardening here, is there? The introduction of wp_unslash() simply prevents erroneous backslashes from showing up (as WP adds them to $_SERVER for back-compat reasons).

@westonruter Make sense, the ticket title may be confusing. But the goal is to sanitize the superglobal variables without directly using them in code. Do you have any suggestions/opinions on this?

The goal makes sense. It's more about data integrity, though.

[westonruter]

In 61606:

Site Health: Account for missing or slashed $_SERVER data in WP_Debug_Data.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/10870

Follow-up to [56056], [45156], [44986]

Props vishalkakadiya, sabernhardt, peterwilsoncc, mukesh27, westonruter.
Fixes #64599.

[johnbillion]

@vishalkakadiya What server configuration do you have that leads to REQUEST_TIME being missing from the $_SERVER superglobal please?

[vishalkakadiya]

@johnbillion Thanks for the question.

While $_SERVER['REQUEST_TIME'] is typically available in standard web server setups, it isn’t guaranteed across all environments. In particular, certain FastCGI/FPM configurations, proxied requests, CLI contexts (e.g., WP-CLI, cron, unit tests), or hardened server setups may not define it.

Since WordPress runs in a wide range of execution contexts, relying on $_SERVER['REQUEST_TIME'] without an existence check can potentially lead to undefined index notices in edge cases.

This change is intended as a small defensive hardening measure to ensure safer access to superglobals and improve robustness across diverse environments.

[westonruter]

@vishalkakadiya it seems to be available in the CLI context actually:

$ php -r 'var_dump($_SERVER["REQUEST_TIME"]);'
int(1770792603)

Have you found a specific PHP configuration where it is not available?

[vishalkakadiya]

@westonruter I haven't encountered a specific PHP configuration where REQUEST_TIME is missing.

This change is primarily part of a defensive coding approach — adding an existence check to guard against potential notices.

[siliconforks]

Replying to johnbillion:

What server configuration do you have that leads to REQUEST_TIME being missing from the $_SERVER superglobal please?

<?php
/*
Plugin Name: Very Bad Plugin
*/
unset( $_SERVER['REQUEST_TIME'] );

[johnbillion]

I think it's fine for this change to stay in now that it's in, and defensive programming certainly has value, but inventing hypothetical situations or configuration that's not actually seen in the wild isn't a great use of time when there are 8,000 open tickets that are better deserving of time from contributors.

Just something to bear in mind for the future. We don't need to work on hypothetical bugs when real ones remain unaddressed.

[vishalkakadiya]

@johnbillion Sure thing!