Unexpected clearing of $_SERVER superglobal when accessing $_ENV in PHP-FPM

Description

Summary:
When using PHP-FPM, accessing the $_ENV superglobal with filter_var() or directly can cause the $_SERVER superglobal to lose its values, specifically REMOTE_ADDR, which unexpectedly becomes null. Notably, this occurs even if the code accessing $_ENV is placed after an exit, which should prevent it from executing. This behavior does not occur when using PHP with other SAPIs, such as Apache’s mod_php.

Steps to Reproduce:

1. Create a PHP script with the following content:

<?php

$remoteAddr = filter_input(INPUT_SERVER, 'REMOTE_ADDR', FILTER_VALIDATE_IP);

if ($remoteAddr === null) {
    echo 'REMOTE_ADDR is not set';
} elseif ($remoteAddr === false) {
    echo 'Invalid IP address';
} else {
    echo "IP Address: $remoteAddr";
}

exit;

// Accessing $_ENV with filter_var, which should not execute due to the exit above
$appEnv = filter_var($_ENV['APP_ENV'], FILTER_SANITIZE_SPECIAL_CHARS);

2. Run this script using PHP-FPM with either Nginx or Apache as the reverse proxy.

3. Expected Behavior: The script should display the client’s IP address from $_SERVER['REMOTE_ADDR'] and then terminate execution after the exit statement, meaning the code below exit should never be executed or have any effect.

4. Actual Behavior: The script displays "REMOTE_ADDR is not set", indicating that $_SERVER['REMOTE_ADDR'] is unexpectedly null, despite the exit command being in place. This suggests that simply having the filter_var($_ENV['APP_ENV']... line in the script is enough to cause this behaviour, even though the line should never actually run due to the exit.

5. Modify the script to use filter_input for $_ENV:

$appEnv = filter_input(INPUT_ENV, 'APP_ENV', FILTER_SANITIZE_SPECIAL_CHARS);

6. Observed Behaviour: When filter_input is used instead of directly accessing $_ENV, the issue does not occur, and $_SERVER['REMOTE_ADDR'] is correctly set, even though this line should not execute due to the preceding exit.

Question:
Is this behavior expected when using PHP-FPM, or is it a quirk that should be addressed? The fact that this occurs even with the exit command in place suggests there might be an underlying issue in how PHP-FPM manages superglobals. If it’s expected, could it be documented more clearly to avoid confusion for developers relying on superglobals like $_SERVER and $_ENV?

PHP Version

PHP 8.3.10, observed down to PHP 5.6.40

Operating System

No response

Bắt đầu bằng cách tái hiện hành vi với PHP-FPM bằng script và các phiên bản đã mô tả, sau đó so sánh với một SAPI khác như Apache mod_php. Truy tìm mối liên hệ của filter_var() hoặc việc truy cập trực tiếp vào $_ENV với $_SERVER và REMOTE_ADDR, đồng thời kiểm tra các test FPM và superglobal hiện có. Được xem là hoàn tất khi hành vi đã được giải thích và được sửa hoặc ghi lại trong tài liệu, với coverage cho trường hợp thoát.