How to easily patch the critical PHP 7 vulnerability on web servers; step-by-step tutorial

A couple of days ago, vulnerability testing specialists reported the detection of CVE-2019-11043, a dangerous remote code execution vulnerability that can affect any PHP 7 website that uses PHP-FPM. The use of this feature is very common on websites with NGINX, which makes them especially vulnerable to the exploitation of this flaw.

It is important to note that the vulnerability resides in PHP-FPM, not NGINX, so the only permanent fix is to upgrade to the updated version of the PHP implementation: PHP 7.1.33, PHP 7.2.24 or PHP 7.3.11.

If exploited, the CVE-2019-11043 vulnerability could allow hackers to force the execution of their own arbitrary code on a remote server, using just a specially designed URL and adding a few characters, in addition to the payload of the attackers.

On the other hand, reports from experts in vulnerability testing mention that this flaw is too easy to exploit, because even users with limited concepts and no hacking knowledge could take control of an exposed system, as it would only requires a common NGINX configuration, whereby NGINX uses a regular expression in fastcgi_split_path_info to split a request into two parts.

Although it is best to update your PHP version immediately, in case this is not possible, down below its shown a way to mitigate the risk of exploiting this vulnerability:

  • You can add a try_files policy to the NGINX configuration to verify that the $uri variable resolves to a file (the PHP script) and rejects the request with code 404 (Not Found), otherwise:
location ~ [^/]\.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_param           PATH_INFO $fastcgi_path_info;
    try_files               $uri =404;

It is important to note that this mitigation only works if NGINX and PHP-FPM share the same docroot on the same host.

  • Use F5 BIG-IP ASM (Application Security Manager) to protect your application. Existing signature sets “Command Execution” and “Server-Side Code Injection” include attack signatures that will block most exploit attempts.
  • Add a ModSecurity rule to block requests that contain the suspicious character %0a or %0d:
SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

This mitigation method could cause false positives, so a threat actor could still find a way to exploit the vulnerability, mention experts in vulnerability testing from the International Institute of Cyber Security.