Imagine a mansion with high-end security. Cameras, sensors, armored doors. Every visitor undergoes verification.
However, kitchen supplies are delivered through the service entrance. The guards check the main gates, while a trusted supplier hands boxes directly to the chef.
One day, a box contains something entirely different from what the label says.
And the problem isn't even that the guards are doing a poor job. Simply put, nobody checked how the handover between two trusted participants in the system was arranged.
A very similar situation arises in web infrastructure at the boundary between NGINX and PHP-FPM.
The web server accepts an external request. It then passes the necessary data to the PHP interpreter via the FastCGI protocol. Usually, this setup works reliably. But configuration errors or data processing vulnerabilities can turn this internal interface into an attack vector.
This raises an uncomfortable question: what happens if the problem isn't in the site's code, but in the mechanism that runs that code?
When Site Protection Fails to Protect the Interpreter Itself
NGINX accepts HTTP requests, selects a routing path, and forwards PHP requests to the corresponding handler.
PHP-FPM manages the PHP worker processes that execute server-side scripts.
Between them sits FastCGI—the protocol used to transmit request parameters, environment variables, and data.
This architecture involves several fundamentally different classes of threats:
- Request routing errors targeting PHP scripts.
- Insecure transmission of FastCGI parameters.
- An unprotected PHP-FPM network interface.
- Memory vulnerabilities in specific PHP versions.
- Application-level flaws that allow unwanted operations.
These should not be conflated. An incorrect PATH_INFO does not automatically mean a memory corruption vulnerability, and access to FastCGI does not guarantee remote code execution. Yet, under certain conditions, the consequences can be severe.
A Real-World Case: CVE-2019-11043
In October 2019, vulnerability CVE-2019-11043 was disclosed.
It affected certain versions of PHP 7 and NGINX configurations running PHP-FPM. A flaw in processing PATH_INFO could lead to process memory corruption and, ultimately, remote code execution.
A combination of several circumstances played a critical role: a vulnerable PHP version, specific handling of the request path, and a lack of proper checks for whether the PHP file actually existed.
The issue was patched in PHP 7.1.33, 7.2.24, and 7.3.11.
This is an important historical example: even if application developers avoided SQL injections and do not accept dangerous file uploads, a flaw at the server handler level can create an independent attack path.
However, applying the mechanics of CVE-2019-11043 to every modern PHP-FPM installation is incorrect.
Why Attackers Target RAM
When exploiting certain vulnerabilities, an attacker aims to alter the behavior of a running process without leaving behind a traditional malicious file in the website's directory.
This complicates detection by tools that monitor strictly for file modifications.
Nevertheless, the phrase "fileless attack" can be misleading.
Even when malware is not written to disk, traces may remain in network telemetry, proxy logs, process events, system auditing, and memory.
The absence of a new PHP file does not guarantee the absence of an attack. Furthermore, a lack of suspicious entries in a standard access.log is not proof of security.
It is crucial for specialists to distinguish between three distinct concepts:
Memory corruption. An error in memory handling that can disrupt process execution and, under specific conditions, grant control to an attacker.
FastCGI configuration injection. The risk of altering PHP's behavior through an improperly secured interface and configuration parameters.
Fileless execution. Performing malicious actions without the traditional step of saving an executable file to disk.
These mechanisms may appear in different attacks, but they do not automatically form a single mandatory chain.
How to Secure the NGINX + PHP-FPM Stack
The first rule is to keep PHP and related components updated. No web server configuration can substitute for patching a known vulnerability.
The second is to restrict access to PHP-FPM. The FastCGI socket should be accessible only to the processes that genuinely require it. If TCP is used, the interface should not be unnecessarily exposed to the internet.
The third is to verify PHP request routing. NGINX must not pass arbitrary non-existent paths to the PHP handler. Specific rules must align with the application's architecture, especially if it relies on PATH_INFO.
The fourth is application isolation. Dedicated OS user accounts, restricted write permissions, minimal access to secrets, and service compartmentalization reduce the impact of a compromise.
The fifth is controlling outbound connections. A server may require external APIs, payment gateways, and mail services. Therefore, a sensible network policy restricts unnecessary directions rather than disabling all outbound traffic with a single command.
The sixth is leveraging system-level hardening mechanisms. Systemd constraints, seccomp, AppArmor, or SELinux can limit what a compromised process can do. However, these should be implemented after compatibility testing, not by blindly copying a universal set of directives.
Finally, robust logs and monitoring outside the PHP application itself are essential. If an attacker gains control over a worker process, trusting that process's own logs is no longer an option.
Why WAFs Are Not Enough
Cloudflare WAF and other web application firewalls remain valuable defensive tools.
They help block many known attacks, suspicious requests, and automated traffic.
However, a WAF does not patch a vulnerable PHP interpreter, replace a secure FastCGI configuration, or guarantee the detection of unknown exploitation methods.
Therefore, true security is determined not by a single product, but by a combination of updates, sound architecture, least-privilege access, and observability.
The Last Line of Defense
The most dangerous administrator mistake is assuming that the absence of an alert means the absence of a problem.
The website may look fine. The database will keep responding. Visitors will notice nothing.
Yet if a server process has acquired capabilities it shouldn't have, the consequences may surface much later.
Real security begins where even a compromised component is denied the freedom to control the entire system.
This is precisely why you need to protect not only the front doors of the digital mansion, but also the service corridors running between its internal mechanisms.
Technical Sources
- CVE-2019-11043, CVE Record: https://www.cve.org/CVERecord?id=CVE-2019-11043
- PHP-FPM Documentation: https://www.php.net/manual/en/install.fpm.configuration.php
- systemd.exec Documentation: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
- Qualys Technical Analysis: https://blog.qualys.com/product-tech/2019/10/30/php-remote-code-execution-vulnerability-cve-2019-11043