PHP2Shell: Researchers Warn Against Relying on Incomplete Workarounds for Two Critical PHP Flaws
Security researchers are warning organizations not to rely on a single PHP configuration change to protect against two critical vulnerabilities collectively referred to as PHP2Shell. The flaws carry a reported severity score of 9.2 out of 10, and the PHP project has not confirmed any configuration-based workaround that can replace installing the official security update.
The PHP project scheduled the fixes for October 21, 2026, at 14:00 UTC. At the time of the reported disclosure, the updates had not yet been released, and the full technical details, affected versions, and fixed builds remained undisclosed.
Until the patches become available, security teams are advised to reduce exposure by restricting public access to vulnerable PHP applications, limiting the privileges and resources available to compromised servers, and preparing to deploy the official update as soon as it is released.
Cloudflare has reported early attempts to exploit the vulnerabilities and introduced emergency Web Application Firewall (WAF) rules for sites using its services. However, these rules are intended as temporary protection, not a substitute for patching. No confirmed compromises had been reported in the disclosure, the circulating public exploit code had not been demonstrated to work, and neither vulnerability was listed in the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog at the time of reporting.
The PHP Configuration Workaround Is Not a Complete Fix
A workaround circulating among security professionals involves disabling PHP's Session Upload Progress feature through the following configuration directive:
session.upload_progress.enabled=0
The feature, enabled by default, tracks the progress of file uploads so that another request can retrieve the current status.
Tokyo-based security firm GMO Flatt Security initially recommended disabling the feature as a precaution. The company acknowledged that it could not confirm whether the change fully addressed the vulnerabilities but believed it might reduce risk.
Later on October 21, the firm clarified that the setting was not a complete mitigation and warned that attacks bypassing it could be possible. It advised administrators to prepare their update procedures, monitor for suspicious traffic, and install the official fix immediately after release.
PHP project representatives also cautioned against relying on configuration changes. PHP core developer Gina Peter Banyard stated that patching or upgrading PHP was the only mitigation she could recommend. Joe Ferguson, the release manager for the upcoming PHP 8.6 release, similarly warned that PHP INI settings would not provide sufficient protection.
There is also uncertainty about whether Session Upload Progress is directly responsible for the vulnerabilities. PHP has not confirmed the underlying technical details, and an independent code audit has challenged claims that the suspected issue exists in released PHP versions. That audit comes from an anonymous account, so the official PHP advisory and source-code changes will be needed to resolve the disagreement.
Consequently, disabling Session Upload Progress may be a reasonable precaution where the feature is unnecessary, but organizations should not treat it as a security fix.
How to Verify the Configuration Change
Administrators who have already disabled Session Upload Progress do not necessarily need to reverse the change. However, they should understand its limitations and confirm that the setting applies to the PHP process handling web requests.
The directive can be configured through php.ini, .htaccess, or .user.ini, depending on the server environment.
A .user.ini file is read by PHP's CGI and FastCGI implementations, but not by PHP running as an Apache module. PHP also caches these files and, by default, checks for changes every 300 seconds. As a result, configuration updates may take several minutes to take effect.
Administrators should verify the effective setting in the actual PHP-FPM, CGI, or Apache module environment serving the application rather than relying exclusively on the output of a command-line PHP configuration check.
Prepare to Install the Official Patch
GMO Flatt Security recommends preparing the update process before the release becomes available. Organizations should identify the PHP runtime used by each exposed application, confirm their deployment procedures, prepare validation checks, and coordinate any required service restarts or emergency maintenance.
The PHP project provides security fixes for its four supported branches, PHP 8.2 through 8.5. The exact affected versions and corresponding fixed releases were expected to be announced alongside the official update.
Updating an application framework or content management system does not necessarily update the PHP runtime underneath it. Administrators must ensure that the actual runtime handling web requests receives the security fix, whether it is PHP-FPM, mod_php, CGI, or another deployment configuration.
Organizations using managed or shared hosting should contact their providers to confirm when patched PHP builds will become available. Hosting vendors generally need to package and distribute updated builds after the upstream fix is released.
Reduce Exposure if Immediate Patching Is Impossible
For systems that cannot be patched immediately, CERT-EU recommends considering the isolation of internet-facing applications from public networks until a fix can be applied.
Where taking a service offline is not practical, organizations should place exposed applications behind VPN access, authenticated gateways, or IP allowlists. They should also verify that attackers cannot bypass these controls by connecting directly to the origin server.
Additional defensive measures include:
- Reduce privileges: Run PHP applications with the minimum permissions required and restrict access to sensitive system resources.
- Remove unnecessary credentials: Eliminate stored secrets and unnecessary cloud-role permissions that could be abused following a compromise.
- Limit sensitive data: Reduce the amount of confidential information stored on internet-facing servers.
- Preserve security logs: Ensure logs are enabled, retained securely, and available for incident investigation.
- Review unsupported versions: Upgrade end-of-life PHP branches or isolate affected systems until a supported and appropriately patched runtime is available.
PHP versions older than 8.2, including PHP 8.1, 7.x, and 5.x, are end-of-life and do not receive security fixes directly from the PHP project. Linux distributions or hosting providers may independently backport security patches, so administrators should consult the relevant vendor advisories instead of judging patch status solely by the displayed PHP version number.
Multipart Request Blocking May Reduce Exposure
Some researchers have suggested blocking requests containing a multipart/form-data body at the web server before they reach PHP. This approach targets a suspected entry point associated with the reported vulnerabilities, but the underlying flaw had not been officially confirmed in the disclosure.
If administrators choose to apply this restriction, they should account for requests beyond the POST method. PHP 8.4 introduced request_parse_body(), which allows applications to parse multipart request bodies on other HTTP methods as well. A rule that blocks only POST requests may therefore leave other request paths available.
Blocking multipart requests can also disrupt file uploads and forms that use multipart encoding, even when they do not contain files. Organizations should assess the operational impact before implementing the restriction.
As with disabling Session Upload Progress, multipart request filtering should be considered a temporary risk-reduction measure, not a guaranteed defense.
Cloudflare Deploys Emergency WAF Rules
Cloudflare has released emergency WAF rules intended to block known exploitation paths, including for customers on its free tier. The company has described the rules as a temporary measure ahead of the official PHP patch.
These protections apply only to traffic passing through Cloudflare. They may not cover direct connections to origin servers or previously unknown exploitation techniques, and they cannot replace updating the underlying PHP runtime.
Organizations using other WAF or edge-security providers should check whether equivalent protections are available, while recognizing that unconfirmed vulnerability details limit confidence in any pre-patch rule.
What Security Teams Should Check After the Release
At the time of the disclosure, exploitation remained unconfirmed. Cloudflare had observed early attempts, but the circulating public proof-of-concept code had not been demonstrated to work against released PHP builds. Researchers had also published material claiming to demonstrate an exploit chain, while an independent audit disputed aspects of the suspected vulnerability.
These findings may change as the PHP project publishes its official advisory and researchers validate the fixed versions.
When the update becomes available, administrators should:
- Confirm the affected and fixed PHP versions listed in the official advisory.
- Upgrade the runtime serving web traffic and verify that the intended package or build is installed.
- Review the official technical explanation before deciding whether any temporary configuration restrictions can safely be removed.
- Test application functionality, particularly file uploads and multipart forms, after applying the update.
- Examine historical application, endpoint, and network logs for suspicious activity that occurred before patching.
The official PHP downloads page and the project's security advisories are the primary places to verify the release details.
The key takeaway: PHP2Shell requires a patch-first response. Disabling Session Upload Progress, filtering multipart requests, and deploying WAF rules may reduce exposure in specific environments, but none should be treated as a confirmed replacement for the official security update.
