PHP team fixes nasty site-owning remote execution bug

The PHP development team has fixed a bug that could allow remote code execution in some setups of the programming language, possibly allowing attackers to take over any site running the code remotely.

PHP is a common programming language used to run dynamic websites. It operates everything from online forums to ecommerce systems. The bug, found in version 7 of PHP, only affects instances running the PHP FastCGI Process Manager (PHP-FPM), which is an alternative implementation of a standard PHP module called FastCGI. It lets an interpreter outside the web server execute scripts. The process manager version includes some extra features to support high-volume websites.

For the bug to work, the website must also be running the Nginx web server, which runs on around one in every three websites, according to W3techs.

When calling a script, the PHP language failed to check that its path was correct. The researcher used this to manipulate a variable within PHP that developers use to configure it. The researcher explained:

Using this technique, I was able to create a fake PHP_VALUE fcgi variable and then use a chain of carefully chosen config values to get code execution.

The team acknowledged the bug and began working on a patch, publishing an untested one on 6 October on its own forum so that its developers could test it. They also collaborated with the researcher to help prepare the patch for testing.

After some wrangling with the PHP team over a disclosure window, the researcher finally published the exploit code on 22 October after the developers had tested and committed the fix to the master repository.

The team fixed the bug in several point releases of PHP. Version 7.1 users should download PHP 7.1.33. Version 7.2 users need PHP 7.2.24, while version 7.3 users should opt for 7.3.11. As with all security releases, the PHP team urged users of the latest full release to upgrade to the latest point version.

The flaw also affected the default software configuration of Nextcloud, a company that publishes self-hosted content collaboration software. In a blog post explaining the issue, it advised users to upgrade, and also suggested making two changes in their Nginx configuration file before restarting the web server. It also promised updates to its Docker container when new PHP-FPM versions become available.

What if you can’t patch your PHP software because of some other dependency? Stanislav Malyshev, a member of the PHP team who helped fix the bug, told us:

Fortunately, at least for people running Nginx, several workarounds have been suggested, which all involve ensuring that request with broken PATH_INFO is not passed to PHP-FPM.

Readers could try one of the following, he said:

1. Adding the following line to the into the Nginx configuration file:

try_files $fastcgi_script_name =404;


2. Ensuring that the PATH_INFO value in PHP is not empty by changing the PATH_INFO line to:

fastcgi_param PATH_INFO $fastcgi_path_info if_not_empty;


He also explained that this configuration listed on the Nginx site is not vulnerable to the issue.