Bug #53611 [Com]: fastcgi_param PHP_VALUE pollutes other sites

Edit report at https://bugs.php.net/bug.php?id=53611&edit=1 ID: 53611 Comment by: amid000 at yandex dot ru Reported by: jraxis at gmail dot com Summary: fastcgi_param PHP_VALUE pollutes other sites Status: Open Type: Bug Package: FPM related Operating System: Linux PHP Version: 5.5.0 Block user comment: N Private report: N New Comment: It looks like that this is not a bug actually. According to this article: https://www.php.net/manual/en/install.fpm.configuration.php >>PHP settings passed with php_value or php_flag will overwrite their previous value. So once it is overwritten once - the new value is used until it is overwritten again. Previous Comments: ------------------------------------------------------------------------ [2019-09-09 14:04:48] james at jamesreno dot com This issue is still affecting 7.3.9 This can cause serious security issues and needs to be addressed sooner than later. auto_prepend_file carrying over from one vhost to another is causing code execution in the wrong vhosts. Requiring the use of work-arounds to "clean up the mess" left over by previous requests is just crazy. When can we expect that the PHP sandbox properly cleans up its environment at the start and end of each request? ------------------------------------------------------------------------ [2019-07-17 09:50:49] mp at webfactory dot de Present at least in PHP 7.2.19. Of course, as it's FPM-related, it does not only affect nginx at in the OP's comment, but also Apache setups. Additional workaround solution: Use PHP_VALUE only for PHP_INI_SYSTEM settings and make sure you configure the same set of those in all virtual hosts. Use .user.ini files for all the rest. Values from .user.ini are cleaned up as one would expect. ------------------------------------------------------------------------ [2019-07-12 21:45:19] mp at webfactory dot de The PHP_VALUE/PHP_ADMIN_VALUE feature was added in https://github.com/php/php-src/commit/34ba9e39fafa3a980a1b69285f68b0e12ad6b876. There is no clean-up, so the modified values persist in the PHP-FPM worker and affect the next request served. To reproduce this more easily, configure PHP-FPM with a single worker (pm = static, pm.max_children = 1). To work around it, - explicitly configure the same set of INI settings in all virtual hosts - configure FPM to only serve one request per worker - use ini_set() in PHP userland instead of using PHP_(ADMIN_)VALUE, although not possible for all settings ------------------------------------------------------------------------ [2018-11-24 09:33:48] php-bugtracker at trash-me dot com Is there any chance, that this bug gets fixed anytime soon? IMHO that's a major problem for shared hosting environments, where multiple users share a common FPM-Pool. Settings from the vhost-configuration of one user might change settings on vhosts of other users in an unpredictable way. Especially, when working with sensitive settings, such as open_basdir, disable_functions or session.save_path, this bug leads to serious security issues. ------------------------------------------------------------------------ [2017-04-04 15:23:01] thciobanu at yahoo dot com I can confirm this issue is still valid for php 7.0.12 and 7.1.3. Excerpt from nginx.conf: location ~ \.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ _pre\.php$ { root /var/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PHP_VALUE "auto_prepend_file=/var/www/html/die.php"; include fastcgi_params; } # cat /var/www/html/index.php <?php die("index\n"); # cat /var/www/html/die.php <?php die("foo\n"); and index_pre.php is just a symlink to index.php: # curl http://localhost/index.php index # curl http://localhost/index_pre.php foo # curl http://localhost/index.php foo ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53611 -- Edit this bug report at https://bugs.php.net/bug.php?id=53611&edit=1