PHP2Shell fixes target two critical PHP remote code execution flaws

PHP planned to release fixes at 14:00 UTC on October 21 for two critical PHP2Shell remote-code-execution vulnerabilities, each rated 9.2 out of 10. At the time of reporting, the project had not identified the affected versions, the vulnerable component, or the fixed releases, and no exploitation had been reported.

The lack of technical disclosure means administrators cannot independently validate whether a particular configuration change blocks the flaws. PHP said that full details, including affected and fixed versions, would accompany the release. The immediate priority is therefore to prepare for the update and reduce exposure until it can be installed.

The upload-progress setting is not a complete defence

A workaround circulating on social media recommends setting session.upload_progress.enabled=0. This disables Session Upload Progress, a default-enabled feature that records file-upload status for subsequent requests. GMO Flatt Security initially said the change could help with some probability, but later clarified that it is not a complete fix and that bypasses are expected.

Gina Peter Banyard, a PHP core developer and documentation writer funded by the PHP Foundation, gave a more direct assessment: the only mitigation is patching or upgrading PHP. The connection between PHP2Shell and Session Upload Progress has not been confirmed by PHP, while an independent audit has challenged the specific bug theory being circulated.

Disabling the setting may still be sensible where an application does not need upload-progress bars. PHP's manual notes that stored file and field names are not validated and may contain PHP code. However, the change must not be treated as protection from the two disclosed flaws.

Prepare the runtime update and limit exposure

Teams should rehearse their update procedure, post-update checks, configuration changes and any emergency restart approvals before the fixed packages arrive. The component to update is the runtime serving web traffic—PHP-FPM, mod_php or CGI—not an application such as WordPress or Laravel that runs on top of PHP.

PHP supports branches 8.2 through 8.5. Organizations using PHP 8.1, 7.x or 5.x should not expect an upstream fix, because those branches are end of life. A Linux distribution or hosting provider may choose to backport a package, but its timetable can differ from PHP's upstream release.

If an update cannot be applied immediately, CERT-EU advises considering isolation of internet-facing applications from public networks. Practical options include VPN access, allowlisted clients or authenticated edge access, while verifying that the origin server cannot be reached directly around those controls.

Verify configuration and retain evidence

For sites that disable Session Upload Progress, confirm the effective value on the web-serving process rather than with php -i on a shell. The INI_PERDIR directive can be configured in php.ini, .htaccess or .user.ini. CGI and FastCGI read .user.ini files, but mod_php does not; PHP also re-reads those files every 300 seconds by default.

GMO Flatt also recommends reducing server privileges, limiting stored data and removing credentials, including cloud roles, where possible. Logging should remain enabled and be retained somewhere secure for later investigation. A web application firewall may offer only a weak stopgap because it sees limited traffic patterns and can miss variants.

When PHP publishes its advisory, administrators should check the fixed version for each branch, the full affected-version range, any confirmed mitigation guidance and whether session handling changed. After deployment, review logs for activity before the patch window; the practical business implication is to treat runtime patch readiness and temporary access restriction as the dependable controls until every public-facing PHP service is running the verified fixed build.