All our servers are updated already, read further for more details on this wide-spread PHP security concern.
October 23rd Update: PHP patches are all rolled out, but there are also signs that these vulnerabilities are much harder to execute successfully in real-world PHP use than initially thought.
The initial messaging made these PHP Remote Code Exploits (RCE) sound much closer to “remotely exploitable on any normal PHP server” than the evidence currently supports. What we’re seeing now is much more nuanced:
- The bugs are real and the RCE chain is apparently real, verified in local configurations against stock pre-patched PHP versions.
- They should absolutely be patched, especially on Internet-facing production servers.
- But exploitation appears to require a fairly specific and difficult chain of conditions to be successful.
- Triggering the underlying memory corruption or stale-state condition is not the same thing as getting reliable wide-spread RCE.
- But there’s currently a substantial gap between a researcher exploiting it, and mass exploitation of ordinary production PHP/WordPress servers.
- Wordfence seeing attack attempts but no confirmed compromised WordPress sites across millions of protected sites is particularly relevant real-world evidence:
So we'd characterize the current situation as high technical severity, but apparently much lower practical exploitability than the initial headlines implied.
That’s an important distinction in vulnerability communication: “Patch immediately” and “this is currently being mass-exploited against typical WordPress sites” are two very different statements.
We wanted to update this post with this just as important information so the real-world situation is well communicated as well.
Technical summaries of both exploits related to our servers
CVE-2026-109619: The attacker must first create stale request state through a specific fatal/error condition, then get a subsequent request handled by the same persistent PHP worker to trigger that stale state, followed by the necessary memory corruption and information-leak chain for RCE. The confirmed paths involve things like session.upload_progress or PHP 8.5 fatal-error backtraces, making exploitation highly conditional and worker-dependent.
On Our Servers: Our use of PHP-FPM significantly reduces exposure because the confirmed exploitation paths require stale request state to survive in a persistent worker and then be consumed by a subsequent request; typical FPM handling and worker lifecycle make the demonstrated paths substantially harder to trigger, particularly with session.upload_progress disabled.
CVE-2026-109618: The attacker must trigger a carefully timed out-of-memory condition that reaches PHP’s vulnerable request-initialization/shutdown path, then turn the resulting memory corruption into RCE. This is demonstrated against stock Apache mod_php, but the straightforward attack is defeated by PHP-FPM killing the worker after startup OOM, so a generic FPM/WordPress RCE has not been demonstrated.
On Our Servers: Our nginx + PHP-FPM architecture prevents the demonstrated startup-OOM exploit because FPM terminates the worker when request startup fails, whereas the confirmed RCE works against Apache mod_php; nginx itself isn’t the mitigation, but using PHP-FPM instead of mod_php is.
UPDATE: October 21, 2026 7:30am: PHP has now released patches for two critical unauthenticated RCE vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 Critical. The vulnerabilities involve PHP’s handling of out-of-memory conditions and stale request state, with multipart request parsing and Session Upload Progress among the confirmed attack paths. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Upgrade immediately. The temporary mitigations discussed below can reduce exposure to specific attack paths, but PHP explicitly states that they do not make an installation safe. (PHP)
A significant PHP security event is unfolding, and website owners should take action before the official patches arrive.
Update 10/21 12:10am: Disabling Session Upload Progress alone is not enough; a new server-level multipart mitigation is available to block exploitation while we wait for patched PHP releases.
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) You could add this near the end of the introduction:
Independent researchers have already published PHP2Shell proof-of-concept tooling, including php2shell.py, demonstrating how the underlying PHP vulnerabilities can potentially be turned into remote code execution, which is why we recommend applying available mitigations before widespread exploitation begins.
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.
Emergency Mitigation Part 1: Disable Session Upload Progress
The most practical interim measure for many websites is to disable PHP’s Session Upload Progress feature:
session.upload_progress.enabled = OffPHP’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 = OffWe recommend leaving the related cleanup setting alone:
session.upload_progress.cleanup = OnPHP’s documentation specifically says that cleanup should remain enabled. (PHP)
This is an interim partial mitigation, not the permanent fix. Once the official PHP security updates are available, the PHP runtime should still be upgraded.
Emergency Mitigation Part 2: Block Multipart Requests at the Web Server
We've now learned that part 1 does not prevent the issue completely. Because one of the reported attack paths involves PHP’s multipart request parsing itself, disabling session.upload_progress alone may not be sufficient. Until patched PHP packages are available, the strongest temporary mitigation is to prevent multipart requests from reaching PHP at all.
This can be done at the web server or reverse proxy layer, before PHP-FPM receives and processes the request. The tradeoff is important: blocking multipart requests will temporarily disable normal file uploads, including WordPress media uploads and any forms that accept attachments. For sites where uploads are not essential, this is a particularly effective temporary defensive measure. For sites that require uploads, it should be treated as an emergency measure and removed after PHP is patched and the exploit has been tested.
Nginx
For Nginx, add the following directive inside the affected site’s server context:
if ($http_content_type ~* "^multipart/form-data") {
return 403;
}This rejects requests using multipart/form-data, which is the content type normally used for browser-based file uploads. The request is rejected by Nginx before it is passed to PHP-FPM.
On Plesk, this can be added under Websites & Domains → Apache & nginx Settings → Additional nginx directives for an individual domain. After applying the change, verify the generated Nginx configuration and reload the web server.
For a broader emergency response, hosting providers can apply an equivalent rule at the server or reverse-proxy layer so that multiple hosted sites are protected without modifying every WordPress installation individually. Care should be taken with server-wide rules because they will affect legitimate upload functionality across all sites.
Apache
For Apache 2.4, the equivalent approach is to reject requests based on their Content-Type header before they reach PHP:
<If "%{HTTP:Content-Type} =~ m#(?i)^multipart/form-data#">
Require all denied
</If>This produces an HTTP 403 response for multipart form submissions and prevents the request from being handed off to PHP.
Apache configurations vary by hosting environment, so the rule should be placed in the appropriate virtual host or directory configuration rather than blindly added to .htaccess on every server. If Apache is operating behind Nginx or another reverse proxy, blocking the request at the outermost web server is preferable.
This Is a Temporary Emergency Control
These rules are not a permanent replacement for upgrading PHP. They are a containment measure designed to reduce exposure while the PHP security releases are being prepared and deployed.
Together, these controls provide defense in depth: the PHP setting removes one vulnerable feature from the runtime, while the web server rule prevents multipart requests from reaching PHP’s request parser in the first place.
Once patched PHP versions are available, upgrade PHP on affected servers, restart PHP-FPM, and test the published proof-of-concept against a controlled staging environment. After confirming that the patched runtime is no longer vulnerable, the temporary multipart blocking rules can be removed and normal upload functionality restored.
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-fpmThe 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 = Offhas 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.
UPDATED with both mitigation parts:
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" or starts_with(lower(http.request.headers["content-type"][0]), "multipart/form-data"))Set the action to Block.
A useful rule name is:
PHP Session Upload Progress Exploit MitigationCloudflare 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.
UPDATE: Cloudflare has implemented emergency WAF rules to prevent these exploits, from Dane Knecht, CTO of Cloudflare:
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 = OffWe 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.
Official and technical references
Cloud Maestro - Bulk Deploy Cloudflare WAF Rules and Bulk Manage DNS
PHP: Upcoming Critical Security Release
JackalSyn: PHP Upload Progress vulnerability research and PoC
Cloudflare: http.request.body.raw
Let's Connect, We Can Help
|
