[php-src] Issue #24689: PHP-FPM: PHP_VALUE settings persist across requests

From: Date: Sun, 25 Oct 2026 14:07:15 +0000
Subject: [php-src] Issue #24689: PHP-FPM: PHP_VALUE settings persist across requests
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-253184@lists.php.net to get a copy of this message
Issue: https://github.com/php/php-src/issues/24689 Author: ultravistor ### Description ## Description I haven't thoroughly tested the exact reproduction steps or conditions yet, but I have observed this behavior for years: settings passed via PHP_VALUE appear to persist throughout the lifetime of a PHP-FPM worker. SetEnvIf ^ ^ "PHP_VALUE=post_max_size=40G;" SetEnvIf ^ ^ "PHP_VALUE=upload_max_filesize=2G;" This of course doesn't work; only the latter setting is supposed to work. But in reality, both post_max_size and upload_max_filesize are often set with this configuration. Recently, I realized this could be a bug, as it seems I can actually place an .htaccess file anywhere in the document root with "PHP_VALUE=post_max_size=100G", and then post_max_size becomes 100G even above the directory where I placed the .htaccess file, if the request is handled by the same PHP-FPM worker. The issue seems to be that once a PHP-FPM worker receives an .htaccess-originated PHP_VALUE, it doesn't clear the value when it finishes processing the request, and the next request for any page handled by the same worker uses the same value. ## Expected behavior Each request should start from the PHP/FPM configuration baseline. A PHP_VALUE override supplied for request A should affect request A only. If request B does not contain that override, request B should see the configured default/pool value. ## Actual behavior For example: Request A: ``` PHP_VALUE=upload_max_filesize=2G ``` The request reports: ``` upload_max_filesize=2G ``` Request B is then handled by the same FPM worker without a PHP_VALUE override for upload_max_filesize. Request B still reports: ``` upload_max_filesize=2G ``` instead of the configured baseline value. The behavior is reproducible when both requests are handled by the same FPM worker. ## Reproduction PHP script: ``` <?php echo "pid=", getmypid(), "\n"; echo "upload_max_filesize=", ini_get('upload_max_filesize'), "\n"; echo "post_max_size=", ini_get('post_max_size'), "\n"; ``` 1. Send a request with PHP_VALUE=upload_max_filesize=2G. 2. Confirm that the override is applied. 3. Send another request handled by the same FPM worker without that override. 4. Observe that the previous value remains active. ## Environment - PHP: 8.5.12 - SAPI: FPM/FastCGI - OS: macOS - PHP built from source ## Investigation The FastCGI INI parser applies PHP_VALUE / PHP_ADMIN_VALUE through fpm_php_apply_defines_ex(). That path ultimately modifies the zend_ini_entry through the FPM master INI alteration path. In contrast, request-scoped INI changes made through the normal Zend INI alteration API are registered in EG(modified_ini_directives), preserving the original value so that request deactivation can restore it. This may explain why an FPM FastCGI override can survive request deactivation, but further investigation is needed to determine the correct fix without changing the semantics of FPM pool-level php_value and php_admin_value settings. ### PHP Version ```plain PHP 8.5.12 ``` ### Operating System macOS

« previous php.bugs (#253184) next »