[php-src] Issue #24689: PHP-FPM: PHP_VALUE settings persist across requests
| From: | ultravistor | 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