A critical remote code execution flaw in PHP-FPM, tracked as CVE-2019-11043, turned one of the most common Nginx + PHP deployment patterns on the internet into a one-shot RCE vector. The bug lives in how PHP-FPM's FastCGI handler computes PATH_INFO when Nginx is configured with a widely-copied regex location block for routing .php requests. An attacker who sends a crafted URL ending in a specific sequence of characters can trigger an integer underflow that corrupts memory ahead of a buffer, and with the right follow-up request, execute arbitrary PHP code — and by extension, arbitrary shell commands — on the target server. Because the vulnerable Nginx snippet was copied verbatim into countless tutorials, Docker base image docs, and CMS deployment guides (including setups behind Ghost, WordPress-on-PHP-FPM, and various homegrown stacks), the exposure was not a niche edge case; it was default-adjacent configuration used across a large slice of the PHP-hosting internet. This post breaks down the vulnerability, who was affected, how it was exploited, and the concrete steps defenders should take — plus how Safeguard helps teams find and close this exact class of gap before attackers do.
What Went Wrong
PHP-FPM (FastCGI Process Manager) is the process manager most production Nginx-plus-PHP stacks use to hand off .php requests from the web server to the PHP interpreter over the FastCGI protocol. To support "extra path" URLs like /index.php/some/extra/path, many Nginx configs use fastcgi_split_path_info to separate the script path from the trailing PATH_INFO segment and pass both to PHP-FPM.
The flaw sits in fpm_main.c, in the code path that parses and reconstructs PATH_INFO from the raw request URI. Under specific conditions — a URL containing a null byte or certain crafted trailing characters after .php — PHP-FPM's internal pointer arithmetic underflows, writing before the start of an allocated buffer. This memory corruption can be escalated from a crash (denial of service) into full remote code execution, since the corrupted memory region overlaps with structures PHP-FPM uses to track script execution state. In practice, published proof-of-concept exploits chain the underflow with a second request that plants attacker-controlled PHP code (or leverages php.ini directive injection) that FPM then executes.
The vulnerable configuration pattern looks like this, and if it looks familiar, that's because it's been pasted into thousands of deployment guides:
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
}
Any site using this exact regex — or a close variant — with an unpatched PHP-FPM behind it was exploitable with nothing more than a crafted HTTP request. No authentication, no prerequisite access, no social engineering.
Affected Versions and Components
- PHP 7.1.x prior to 7.1.33
- PHP 7.2.x prior to 7.2.24
- PHP 7.3.x prior to 7.3.11
- Any Nginx configuration pairing the vulnerable PHP-FPM versions with a
locationblock that enablesfastcgi_split_path_infoand forwardsPATH_INFO, which is the standard pattern for supporting "extra path info" URLs
PHP 7.4 was not affected at release, and PHP 8.x branches were never exposed to this specific code path. Standalone mod_php (Apache) deployments that don't route through PHP-FPM's FastCGI path-info parsing were also not affected by this particular bug, though they carry their own separate risk profile.
CVSS, EPSS, and Exploitation Context
CVE-2019-11043 carries a CVSS v3.1 base score of 9.8 (Critical) — network-exploitable, no privileges or user interaction required, with full impact to confidentiality, integrity, and availability, consistent with an unauthenticated pre-auth RCE. Because working, weaponized exploit code circulated publicly within days of disclosure, this CVE has consistently carried a very high EPSS (Exploit Prediction Scoring System) percentile, reflecting near-certainty of continued opportunistic scanning and exploitation attempts across the internet years after disclosure — it remains a favorite in mass-scanning toolkits and botnet exploitation chains precisely because the vulnerable Nginx pattern is so common and so rarely revisited once deployed. Security teams should treat any internet-facing host still running an affected PHP-FPM build as an active, not theoretical, target, and validate its presence or absence in vulnerability management and exposure-management programs regardless of whether it appears in a given point-in-time KEV snapshot.
Timeline
- Prior 2019 — Security researchers Andrew Danau and Omar Ganiev, working independently and later collaborating with the Wallarm security team, identified the underflow while investigating PHP-FPM's PATH_INFO handling.
- October 22, 2019 — A detailed technical writeup and working proof-of-concept exploit were published, demonstrating remote code execution against the common Nginx + PHP-FPM configuration.
- October 23–24, 2019 — The PHP project shipped patched releases: PHP 7.1.33, 7.2.24, and 7.3.11, closing the underflow in
fpm_main.c. - October 25–27, 2019 — Within days, internet-wide scanning campaigns were observed by multiple threat intelligence teams probing for vulnerable, unpatched PHP-FPM instances, confirming rapid weaponization at internet scale.
- Ongoing — The vulnerability continues to appear in automated exploitation frameworks and mass-scan toolkits, largely because legacy containers, unmaintained VPS hosts, and "set it and forget it" LAMP/LEMP stacks are frequently never rebuilt with a patched PHP base image.
Remediation Steps
1. Patch PHP-FPM immediately. Upgrade to PHP 7.1.33, 7.2.24, 7.3.11, or any later minor/major release (7.4+, 8.x). This is the only complete fix — everything else below is a mitigation, not a resolution.
2. Audit and harden the Nginx configuration, even after patching, since defense-in-depth here is cheap:
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_param PATH_INFO $fastcgi_path_info;
include fastcgi_params;
}
Adding try_files $uri =404; ensures Nginx only forwards requests that map to a file that actually exists on disk, closing off a large class of PATH_INFO manipulation before it ever reaches PHP-FPM.
3. Disable PATH_INFO support if your application doesn't use it. Most modern frameworks (Laravel, Symfony, WordPress with pretty permalinks) route entirely through front-controller URLs and never need fastcgi_split_path_info at all. If you don't use extra-path-info URLs, remove the directive entirely.
4. Rebuild container images, don't just patch running hosts. If you're running php:7.2-fpm or similar official images, pin to a patched tag and rebuild — patching a live container's PHP binary in place is not a durable fix and won't survive redeploys from a stale base image.
5. Add WAF/IDS signatures for anomalous PATH_INFO sequences (null bytes, malformed trailing segments after .php) as a stopgap for hosts pending a maintenance window, and monitor PHP-FPM logs for repeated worker crashes or restart loops, which are a strong indicator of active exploitation attempts.
6. Inventory your fleet. This vulnerability is a textbook case for why software composition visibility matters — the affected component (PHP-FPM) is often several layers removed from what an application team thinks of as "their code," buried in a base image or infrastructure team's Nginx template that nobody has revisited since it was written.
How Safeguard Helps
CVE-2019-11043 is a strong illustration of why version scanning alone isn't enough — the real risk hinges on whether a specific host actually runs the vulnerable Nginx PATH_INFO pattern alongside an unpatched PHP-FPM build, not merely whether an old PHP version shows up in an inventory. Safeguard's reachability analysis correlates your SBOM inventory with actual deployed configuration and code paths, so you can distinguish "PHP 7.2 is installed somewhere" from "this internet-facing service is running the exact exploitable configuration right now," cutting through alert fatigue on a CVE this old and this noisy. Griffin AI, Safeguard's agentic remediation engine, can trace the vulnerable dependency and Nginx configuration pattern across your entire fleet, prioritize the hosts with genuine internet exposure, and open auto-fix PRs that bump PHP-FPM to a patched release and harden the associated Nginx location block in the same change. Continuous SBOM generation and ingestion means that even PHP-FPM buried in third-party base images or infrastructure-as-code templates gets tracked going forward, so a five-year-old CVE like this one doesn't quietly reappear the next time someone spins up a container from an unpinned tag. For security teams managing sprawling legacy PHP estates, that combination of reachability context, automated fix generation, and continuous inventory is what turns a critical, internet-scale RCE into a routine, closed ticket.