Addressing the PHP-FPM Vulnerability (CVE-2019-11043) with NGINX

Owen Garrett of F5

Sr. Director, Product Management

October 29, 2019

A recently reported vulnerability, tracked as CVE-2019-11043, can affect websites that use PHP‑FPM to execute PHP pages. PHP‑FPM usage is particularly common at NGINX‑powered websites because NGINX does not have an in‑process PHP runtime. Instead, NGINX acts as a reverse proxy for application servers and process managers such as PHP‑FPM.

The vulnerability lies in PHP‑FPM itself, not NGINX, so the only guaranteed solution is to upgrade to the patched release (or later) of your PHP version: PHP 7.1.33, PHP 7.2.24, or PHP 7.3.11.

What Is the Nature of the Vulnerability?

NGINX communicates with PHP‑FPM using the FastCGI protocol. Each FastCGI message contains a set of environment variables. One of these, PATH_INFO, is derived from other request parameters. If its value is unexpectedly empty, this can ultimately cause memory corruption in the PHP‑FPM binary. It is possible to exploit this situation and make the PHP‑FPM binary run arbitrary commands on the local server.

This vulnerability can be triggered by a common NGINX configuration, whereby NGINX uses a regular expression in the fastcgi_split_path_info directive to split the request URI into two parts. One way to trigger the vulnerability is to embed a line break (%0a) or carriage return (%0d) character into the request URI, which is then not correctly handled by the regular expression.

Mitigating Against the Vulnerability

As mentioned above, the only certain way to address this vulnerability is to upgrade to the patched release (or later) of your PHP version: PHP 7.1.33, PHP 7.2.24, or PHP 7.3.11.

If you are not able to upgrade your PHP binary immediately, there are several partial mitigations you can make:

1. Various sources have suggested adding a try_files directive to the NGINX configuration to verify that the $uri variable resolves to a file (the PHP script) and rejecting the request with code 404 (Not Found) if not:

   location ~ [^/]\.php(/|$) {
       fastcgi_split_path_info ^(.+?\.php)(/.*)$;
       fastcgi_param           PATH_INFO $fastcgi_path_info;
       try_files               $uri =404;
       #...
   }

   Note that this mitigation only works if NGINX and PHP‑FPM share the same docroot on the same host.

   PHP configurations vary depending on the needs of the upstream application. Please test changes like this to verify they do not impact your application.

2. Use F5 BIG-IP ASM (Application Security Manager) to protect the application. The existing “Command Execution” and “Server Side Code Injection” signature sets include attack signatures that block most attempts to discover and exploit this PHP‑FPM vulnerability.

   Editor – Since this blog was published, the F5 Security Team has released an additional signature that is specific to this vulnerability. For details, see F5 DevCentral.

3. Add a ModSecurity rule to block requests that contain the suspicious %0a or %0d character:

   SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

   This solution is described in the Wallarm’s original report about the vulnerability; it may cause false positives and an attacker might still find other ways to exploit the vulnerability.

Using a Different PHP Process Manager

Rather than rely on PHP‑FPM, you can use NGINX Unit to run your PHP applications. NGINX Unit is a high‑performance, open source application server and process manager that supports numerous languages and frameworks in addition to PHP. It can auto‑scale PHP applications in response to load, and concurrently run applications that use different PHP runtimes. We provide binaries, source, and Docker images for free.

See the NGINX Unit documentation for instructions on configuring and operating NGINX Unit for WordPress, a popular, high‑traffic, PHP‑powered application. The deployment takes advantage of the support for serving static files in NGINX Unit 1.11.0 and later.