CVE-2024-4577 in PHP: how the critical PHP-CGI vulnerability in Windows works

Published on 2026-10-27 by frfrand

What is CVE-2024-4577, who discovered it, when it affects PHP on Windows, how it is exploited, and how to protect your website or server.

What happened with PHP and why it matters?

Imagine that your website works normally, but the server interprets part of an HTTP request as instructions for the program that runs PHP. That is what made CVE-2024-4577, published in June 2024, especially dangerous: under specific conditions, a remote attacker without logging in could make PHP-CGI receive options that should never come from the visitor. The result could be code execution or exposure of sensitive information.

Who discovered the vulnerability and how was it reported?

The research is attributed to Orange Tsai, from DEVCORE. The finding was communicated through security channels and the PHP Group published fixes. Identifying a flaw like this requires reviewing how one layer delivers data to another: here the unexpected point was in the character conversion of Windows and how PHP-CGI interpreted the result.

What systems and versions were affected?

The PHP Group record indicates the branches prior to 8.1.29, 8.2 prior to 8.2.20 and 8.3 prior to 8.3.8, in scenarios with Apache, PHP-CGI on Windows and certain code pages. A PHP installation on Linux is not automatically affected by this specific flaw; nor is it enough to see "PHP 8" to affirm that a site is vulnerable. The execution mode and configuration matter a lot.

How was it exploited?

Conceptually, the attacker sent a manipulated web request to take advantage of a character conversion known as Best-Fit. That transformation could cause an input treated as data to end up being interpreted as a PHP command-line option. Knowing the administrator's password was not necessary if the vulnerable configuration was reachable. It is not correct to assume that any PHP form causes this effect: the origin of the failure lies in the PHP-CGI/Windows integration.

Why is it considered so serious?

Remote code execution can allow reading configuration files, compromising credentials, altering the site, or installing malicious components with web service permissions. The CVE entry assigns critical severity. In addition, response agencies reported real exploitation; therefore, it was not enough to think it was an academic proof.

How to know if your site is at risk?

First, find out where PHP runs: Windows or Linux. Then check how: PHP-CGI, FastCGI, Apache module, or another mode. Review the exact version number and the applicable bulletin. If you use Windows with exposed PHP-CGI, prioritize the review; if the distribution maintains backported patches, compare the specific package with its security notice.

How is it fixed?

The solution is to update to a corrected and currently maintained version of PHP, following the manufacturer's or hosting provider's instructions. Versions 8.1.29, 8.2.20, and 8.3.8 fixed this CVE in their respective historical branches; this is not a recommendation to install old versions in 2026. If you manage Apache on Windows, check if you really need to expose PHP-CGI and remove that attack surface when it is not necessary. Test in a staging environment, keep backups, and monitor logs after the update.

Quick questions

Does it also affect WordPress? A WordPress running on a vulnerable PHP-CGI configuration could be exposed, although the flaw is in PHP, not in the WordPress core.

Does a firewall replace the patch? No. It can reduce exposure, but the main fix is to update and review the configuration.

What do I do if I suspect exploitation? Preserve logs, restrict access, review system integrity and credentials, and treat the incident as a potential server compromise.

Verifiable sources: Official CVE of the PHP Group · PHP ChangeLog · CERT-EU.

Where to follow alerts and request support?

At ArduMaker we explain new vulnerabilities and share guidance on version review, updates, and containment measures. You can check the ArduMaker CVE and support page. If your system does not use WordPress, still indicate the technology, version, and configuration when describing the case to evaluate what needs to be reviewed. A published alert does not mean that all servers of that technology are affected, nor that a pending update implies a confirmed intrusion.

Editorial update: October 2026. Always check the official notice for possible version changes and mitigations.

Practical example: a PHP website on Windows

Situation: a WordPress store runs on Windows with Apache and PHP-CGI. The administrator receives an alert about CVE-2024-4577. It is not enough to check the WordPress version: the problem lies in how Windows, Apache, and PHP-CGI interpret the request.

Check without attacking the website: on the server itself, run PowerShell and verify the PHP binary used by Apache:

& "C:\php\php.exe" -v

Then check in the Apache configuration that this is the PHP actually linked. Compare branch and version with the official advisory; avoid publishing a phpinfo() page on the Internet just to investigate.

Before: vulnerable PHP-CGI publicly reachable. After: updated runtime, processes restarted, and a normal test request confirming that login, payments, and forms still work. A backup allows rolling back if an old extension stops being compatible.

What the command does not prove: that your website was attacked. It only helps inventory the interpreter; the risk requires reviewing configuration and logs.