Critical PHP Vulnerabilities: What Website Owners Need to Know and Do Now

A significant PHP security event is unfolding, and website owners should take action before the official patches arrive.

The PHP security team has announced an emergency security release for Wednesday, October 21, 2026 at 7am PDT / 10am EDT, covering two critical vulnerabilities rated CVSS 9.2. PHP is urging administrators to prepare now and upgrade as soon as the fixed releases are available. The project has also said it may move the release forward if technical details become public or evidence of exploitation appears in the wild. (⁠PHP)

That warning is unusually direct, and there is a good reason for it. Independent security researchers have published technical details and proof-of-concept material describing what appears to be a potentially serious remote-code-execution vulnerability in PHP’s session upload-progress handling. The publicly available research is detailed enough that security teams should assume exploit development will accelerate rapidly once the official advisory and patches are released. (⁠The Hacker News)

We do not want to overstate the situation or create unnecessary alarm. There is no evidence that every PHP website has been compromised, and a published proof of concept does not mean an attacker has already gained access to your server. But this is not a routine WordPress vulnerability that can simply be addressed during the next plugin update cycle. Because the suspected flaw is in PHP itself, the underlying server software needs to be addressed.

For websites that do not use PHP’s upload-progress feature, there is also a practical interim mitigation that can be applied now.

What is happening with PHP

PHP is one of the foundational components of the modern web. WordPress, WooCommerce, Drupal, Magento, Laravel, and countless custom applications rely on PHP to execute server-side code.

The security issue now under discussion appears to involve PHP’s built-in Session Upload Progress functionality. PHP provides this feature to track the progress of file uploads and make that information available through the session system. It is enabled by default, with the relevant configuration controlled by session.upload_progress.enabled. (⁠PHP)

The independent research published by JackalSyn describes memory-management problems involving stale pointers created during upload-progress processing. In practical terms, the research indicates that carefully constructed HTTP requests may be able to manipulate PHP’s memory state in a way that can ultimately lead to execution of attacker-controlled code. (⁠PHP)

The technical details are considerably more complicated than that, but website owners do not need to understand PHP internals to understand the risk. The important point is that this is potentially a remote code execution vulnerability in the PHP runtime itself.

That is what makes this event different from an ordinary vulnerable plugin.

A compromised plugin usually gives an attacker access through one particular application component. A vulnerable PHP runtime sits underneath the entire application. If an attacker can reliably exploit PHP before application-level protections can intervene, WordPress security plugins cannot simply repair the underlying problem.

Why the urgent timing matters

There is a familiar pattern in major software vulnerabilities. A vulnerability is discovered, a patch is prepared, technical details are published, proof-of-concept code appears, and attackers then adapt that research into automated scanning and exploitation.

We are approaching that transition right now.

The PHP team has already announced the severity of the issue and the release timetable. Researchers have published independent analysis and proof-of-concept material, including a detailed write-up of the suspected session.upload_progress exploit path. (⁠PHP)

The research with proof of concept scripts are already public here:

JackalSyn: PHP Upload Progress vulnerability research and proof of concept

We are linking to the research because transparency matters. Security administrators, developers, and hosting providers should be able to see what researchers are reporting and understand why defensive measures are being taken now.

The concern is not that every attacker has suddenly acquired a working exploit for every PHP installation. The concern is that the barrier to developing one is getting lower, while millions of Internet-facing systems continue to run PHP.

That is why the window before the official patch is important.

What agencies and website owners should do now

The most practical interim measure for many websites is to disable PHP’s Session Upload Progress feature:

session.upload_progress.enabled = Off

PHP’s own documentation states that this option is enabled by default and specifically recommends considering disabling it for applications that do not use upload-progress bars. (⁠PHP)

For most WordPress websites, this is an attractive mitigation because the feature is not required for normal WordPress operation.

Disabling session.upload_progress.enabled does not disable ordinary PHP file uploads. A WordPress administrator can still upload images, plugins, themes, and other media. What is disabled is PHP’s separate session-based mechanism for tracking upload progress.

That makes the setting relatively low risk for typical WordPress hosting environments.

The important configuration is:

session.upload_progress.enabled = Off

We recommend leaving the related cleanup setting alone:

session.upload_progress.cleanup = On

PHP’s documentation specifically says that cleanup should remain enabled. (⁠PHP)

This is an interim mitigation, not the permanent fix. Once the official PHP security updates are available, the PHP runtime should still be upgraded.

How to apply the PHP mitigation

If you manage your own server, the setting should be applied to the PHP runtime that actually serves web requests.

That point is important on modern hosting systems because command-line PHP and web PHP may use different configurations.

Adding the setting to a CLI php.ini does not necessarily change the configuration used by PHP-FPM, LiteSpeed PHP, Apache, or another web-facing PHP runtime.

After changing the configuration, the relevant PHP service must generally be reloaded or restarted.

For example:

systemctl reload php8.3-fpm

The exact service name varies by operating system and hosting platform.

You should then verify the setting using the configuration exposed by the web-serving PHP runtime, not simply assume that the change took effect because the CLI reports it.

For a managed hosting environment, the simpler option is to ask the hosting provider to confirm that:

session.upload_progress.enabled = Off

has been applied to the PHP versions actually serving the website.

If you rely on a managed hosting provider, ask them what they are doing now, before the patch arrives. A competent hosting provider should be able to tell you which PHP versions your websites are actually using, whether the upload-progress feature is enabled, what temporary mitigation is being applied, and how quickly the patched PHP releases will be deployed.

A second layer: Cloudflare WAF

Websites using Cloudflare can add another layer of defense by looking for the default PHP upload-progress parameter in POST requests. We use and recommend Cloud Maestro - Bulk Deploy Cloudflare WAF Rules and Bulk Manage DNS.

The default PHP parameter is:

PHP_SESSION_UPLOAD_PROGRESS

For Cloudflare customers with access to request-body inspection, a Custom WAF rule can use:

http.request.method eq "POST" and http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS"

Set the action to Block.

A useful rule name is:

PHP Session Upload Progress Exploit Mitigation

Cloudflare documents http.request.body.raw as the unaltered HTTP request body and supports it for WAF rules. However, this capability is plan-dependent. Cloudflare currently documents the raw request-body field as requiring an Enterprise plan, and it also applies request-body size limits when inspecting requests. (⁠Cloudflare Developer Docs)

That means this rule should be viewed as defense in depth, not as a substitute for securing PHP.

It also has an important limitation: because Cloudflare’s body inspection can be truncated, a signature-based rule cannot guarantee that every malicious request will be detected. The origin server will still receive the complete request body even when Cloudflare’s inspected representation is truncated. (⁠Cloudflare Developer Docs)

In other words, the hierarchy is straightforward:

Cloudflare WAF rule for additional filtering, PHP configuration mitigation immediately, and the official PHP security update as the real fix.

What Press Wizards is doing

For our managed hosting environments, we are NOT waiting for the first wave of exploit traffic before responding.

We are treating this as an infrastructure-level security event and are taking preventative action now while the official PHP fixes are being prepared.

Where the functionality is not required, we are disabling:

session.upload_progress.enabled = Off

We are also preparing to deploy the corrected PHP releases as soon as they are available through the appropriate operating-system and hosting software channels.

We have also bulk deployed Cloudflare WAF rules across the fleet of sites we manage that are active and proxied in Cloudflare (all maintenance plan sites, and most client sites we host).

Our approach is deliberately layered. The temporary PHP mitigation reduces exposure to the suspected vulnerable code path. Firewall and WAF protections can provide an additional barrier at the network edge. Monitoring, backups, malware detection, and server-level security controls remain important safeguards as well.

Most importantly, we are not treating the configuration change as the end of the process. Once fixed PHP packages are available, the PHP runtime still needs to be upgraded.

Please also learn about our WordPress Maintenance Plans if you don't already have one.

What about older PHP versions?

This is another serious reason for concern. Are you running a site on PHP older than v8.2?

The current PHP project supports security fixes only for its maintained release branches. As of October 2026, those are PHP 8.2, 8.3, 8.4, and 8.5. PHP 8.1 reached end of life on December 31, 2025, and earlier branches have been unsupported for considerably longer. (⁠PHP)

The independent research surrounding this incident has suggested that the underlying problem may affect substantially older PHP releases as well. The complete official affected-version matrix, however, is being established through the PHP security release process.

That distinction matters.

We are comfortable saying that older, unsupported PHP versions represent a more serious risk because they are outside the normal upstream security-support lifecycle. We should not, however, claim that PHP has promised to patch every historical PHP branch affected by the underlying bug.

The practical answer for sites running PHP 8.1 or older is not to wait and hope. Those environments should be treated as legacy infrastructure and moved to a supported PHP branch whenever the application allows it.

This is not a reason to panic

There is a natural tendency for security coverage to become alarmist whenever a critical vulnerability receives a high CVSS score and proof-of-concept code becomes public.

We want to avoid that. A vulnerable PHP installation is not automatically a compromised PHP installation. A proof of concept is not the same thing as a successful attack against every server. There is also no reason for website owners to assume that an attacker has already obtained access simply because their site is running PHP.

At the same time, this is not a situation where complacency is appropriate.

The combination of a high-severity PHP runtime vulnerability, public technical research, proof-of-concept material, and a large Internet-facing install base creates the conditions for rapid automated exploitation. The sensible response is neither panic nor delay.

It is preparation, now.

The bigger lesson for website owners

This incident is a useful reminder that website security is broader than WordPress.

Keeping WordPress, themes, and plugins updated is essential, but those applications ultimately depend on the operating system, web server, PHP runtime, database, firewall, DNS, and other layers of infrastructure beneath them.

When the vulnerability is in PHP itself, the response has to move down that stack.

That is also why managed hosting can be valuable during incidents like this. The website owner should not have to discover a critical PHP vulnerability, determine which FPM pools are using which versions, figure out where the correct configuration lives, research temporary mitigations, monitor vendor packages, and then manually perform emergency upgrades across multiple servers.

Those are infrastructure responsibilities.