CVE-2024-4577 – Critical PHP CGI Command Injection

What is CVE-2024-4577?

CVE-2024-4577 is a critical OS command‑injection flaw in the PHP interpreter when it is run on Windows in CGI mode. The vulnerability lets an attacker inject arbitrary shell commands and achieve code execution on the host. The CVSS score is 9.8, which places it in the highest severity band.

We keep a daily-updated list of vulnerabilities CISA has confirmed as actively exploited, including remediation deadlines.

The issue is a patch‑bypass for an older flaw that has been around for over a decade. It was published in early June and has already been seen in the wild, with ransomware operators confirming its use. CISA has added it to the Known Exploited Vulnerabilities catalog and now requires organisations to apply mitigations or stop using the affected product.

Who should care?

If you run any version of PHP on a Windows server that is configured to use the CGI binary, you are in scope. That includes web‑applications that rely on the traditional CGI SAPI, any legacy scripts that invoke php‑cgi.exe directly, and containerised workloads that still ship the Windows CGI binary.

Even if you think your PHP is up to date, you need to verify the exact branch you are on – the fix is only present in the most recent releases for each major branch. The table below lists the versions that are vulnerable and the point at which the fix was introduced.

Any system that accepts user‑supplied data and passes it to PHP in CGI mode is at risk. If you expose a web front‑end to the internet, the attack surface is large enough for an opportunistic attacker to try.

How the flaw works

PHP’s CGI binary builds a command line that it hands to the Windows command interpreter. When certain request parameters are concatenated into that command without proper sanitisation, an attacker can terminate the intended argument and inject additional commands. Because the Windows command interpreter will execute everything after the termination token, the attacker can run any program that the PHP process is allowed to run.

The underlying class of the bug is OS command injection – the code that should treat input as data instead treats it as part of a shell command. The exact code path that leads to the injection has not been disclosed publicly, but the impact is clear: arbitrary code execution with the privileges of the PHP process.

In practice, an attacker crafts a request that contains a specially‑formatted query string or POST body. That payload reaches the CGI binary, which then spawns a new command shell with the attacker‑supplied commands. If the PHP process runs under a privileged account, the attacker can move laterally, install ransomware, or create a backdoor.

How to determine if you are exposed

First, confirm that you are running PHP on Windows. The simplest check is to run the interpreter and look at the version string:

php -v

If the output mentions a Windows build, you are on the right platform.

Next, verify the Server API that PHP is using. Run:

php -i | findstr "Server API"

The line should read something like “Server API => CGI”. If it says “CLI”, “FPM”, or “FastCGI”, the specific CGI binary is not in use and the vulnerability does not apply.

If you are using a web server, you can also check the php‑cgi.exe process in the task manager or with a command such as:

tasklist /FI "IMAGENAME eq php‑cgi.exe"

Seeing that process confirms the CGI binary is active.

Finally, compare your exact PHP build against the table below. The table lists the last vulnerable release for each branch and the first release that contains the fix. If your build predates the fixed release for your branch, you must patch.

Mitigation and remediation

The recommended action from the vendor is to upgrade to the patched release for your branch. In plain English: download the latest PHP package that matches the major version you are currently using and replace the existing binaries. The upgrade will include the corrected CGI binary and any ancillary security fixes.

Steps to upgrade on a typical Windows server:

• Stop the web server service (for example, net stop w3svc for IIS).
• Back up the current PHP directory – copy the whole folder to a safe location.
• Download the newest PHP package for your major branch from the official PHP website.
• Extract the package to a temporary location.
• Replace the old php‑cgi.exe and any related DLLs with the new ones.
• Update any configuration files if the new package introduces new directives (the installer will usually provide a diff).
• Restart the web server service.
• Verify the version again with php -v and confirm the Server API is still CGI.

If you run multiple PHP branches on the same host, repeat the process for each branch.

For environments that cannot tolerate downtime, consider a rolling upgrade: spin up a new server with the patched PHP, shift traffic, then decommission the old host.

In addition to upgrading, you can mitigate the risk by disabling CGI mode altogether. Switch to FastCGI or the FPM SAPI if your web server supports it. For IIS, that means configuring the FastCGI module and pointing it at php‑fcgi.exe instead of php‑cgi.exe. For Apache, enable the mod_fcgid module and adjust the handler.

Disabling CGI removes the vulnerable code path entirely, which satisfies the CISA requirement to apply mitigations when a patch is not immediately available.

What to do if a patch is unavailable

In the unlikely event that you cannot upgrade – perhaps because a custom extension only works with the older CGI binary – you must apply defence‑in‑depth measures.

• Run the PHP process under a dedicated, low‑privilege account. Do not use an administrator or system account.
• Restrict the command interpreter’s ability to launch other programs. Use Windows AppLocker or Software Restriction Policies to allow only the binaries you truly need.
• Place a web‑application firewall (WAF) in front of the server and enable rules that block suspicious characters in query strings (such as pipe |, ampersand &, or backticks).
• Enable logging of all CGI requests and monitor for unusual command patterns. Alert on any request that contains characters commonly used in command injection.
• Consider network segmentation: keep the PHP CGI host on a subnet that does not have direct access to critical internal systems.

These steps do not eliminate the flaw, but they raise the effort required for an attacker to succeed. CISA explicitly allows you to continue using the product if you have applied mitigations that reduce the attack surface to an acceptable level.

Verification after remediation

Once you have applied the upgrade or mitigations, run the version check again and confirm the Server API still reports CGI (if you chose to stay on CGI). Then, perform a quick test to ensure the injection vector is no longer usable. A harmless payload such as:

GET /test.php?cmd=whoami HTTP/1.1

should not result in the system command being executed. If the response contains the raw command string instead of the system’s user name, the fix is in place.

Finally, scan the host with your vulnerability scanner to confirm that CVE-2024-4577 no longer appears as a finding.

Bottom line

The vulnerability is severe, the exploit is confirmed in the wild, and ransomware actors are already using it. The only reliable defence is to move to the patched PHP release for your branch or to stop using the CGI binary altogether. Check your environment, apply the upgrade, and verify the result. If you cannot patch right now, harden the host, restrict privileges, and monitor closely. The sooner you act, the less chance an attacker has to turn your server into a launchpad for ransomware.

Affected versions

Straight from the NVD record for CVE-2024-4577. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
php	8.1.0 up to 8.1.29	8.1.29
php	8.2.0 up to 8.2.20	8.2.20
php	8.3.0 up to 8.3.8	8.3.8