I have developed quite a number of WordPress and Magento websites over the years, and have watched PHP progress from version 5, through PHP 7, to PHP 8 today.
Over the past few days, I have been in crisis management mode at work because of PHP2Shell. The hardest part of our response involved legacy PHP 5.6 applications with no patch available to us.
Why PHP Still Matters to Businesses
- WordPress is built on PHP and powers millions of sites, from publishing sites to business websites.
- Drupal supports content publishing, workflows and integrations. Its PHP requirements vary with the Drupal release and its dependencies.
- Magento Open Source and Adobe Commerce bring PHP into ecommerce. Adobe maintains a compatibility matrix for the PHP versions supported by each Commerce release.
These sites can be tied to publishing workflows, customer accounts, catalogues, orders and integrations. Changing PHP means checking that those workflows still work.
That is why a PHP vulnerability involves application owners, hosting providers, infrastructure engineers and security teams.
What is PHP2Shell?
PHP2Shell is the name used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The official advisories rate both at CVSS v4.0 9.2. They concern memory handling inside the PHP runtime and can lead to unauthenticated remote code execution. The PHP Foundation's account gives the background to the release.
Updating WordPress, Drupal, Magento, a plugin or a Composer dependency does not by itself tell you whether PHP itself has been patched.
The original researchers demonstrated attacks against several PHP applications. Exploitation depends on the PHP build, server integration, configuration and application behaviour. Wiz's original research explains the demonstrations and their scope.
How Can an HTTP Request Become Code Execution?
PHP allocates memory for the request. Some internal data should exist only for that request, while the worker process may remain alive to handle more requests. The runtime has to keep those lifetimes consistent, including when something fails.
Calif describes what can happen when an error interrupts an operation after it has exposed internal state. If cleanup never finishes, PHP can be left referring to data that was only partly initialised or has already been freed.
CVE-2026-109618: Out-of-Memory Handling
In the vulnerable behaviour, PHP uses longjmp() to escape from the current native execution context when an out-of-memory error occurs. If that happens while a request structure is only partly initialised, the usual completion steps can be skipped. Request cleanup can later treat the incomplete structure as valid and access invalid memory. Calif's write-up traces this interruption pattern.
Multipart form processing is one way to create memory pressure. The amount of bookkeeping PHP allocates can be much larger than the request itself. A request-size limit and a memory-allocation limit therefore measure different things.
With Apache mod_php, cleanup can still run after request startup fails. The demonstrated sequence can happen before application code starts. An application's login page cannot intercept a request that triggers the problem at that earlier stage. Reference: the official OOM advisory.
CVE-2026-109619: Stale State Across Requests
The second class of problem involves state surviving longer than the memory it refers to.
In one documented path, PHP stores a pointer to request-owned data and a fatal error interrupts the matching cleanup. The request ends and its memory is freed, but the worker retains the pointer. A subsequent request handled by that worker reaches an early operation that consumes it.
This is a use-after-free: PHP acts on memory that no longer contains the original live object. Exploitation requires both a reachable operation that leaves the stale state and another operation that consumes it. The official advisory describes paths involving session upload progress, diagnostics and fatal-error backtraces. Reference: the official stale-state advisory.
PHP-FPM handles request startup differently from mod_php. Calif's research also documents FPM exploits that depend on application code.
What an Attacker Could Gain
Memory corruption does not automatically produce a working shell. An attacker has to turn the invalid state into useful control over execution, and differences between deployments can affect the result.
One way to turn this into RCE is to influence the allocations that replace freed memory. PHP may then mistake attacker-controlled bytes for its own bookkeeping and eventually use a forged object or function pointer. This is why recreating a suitable memory layout matters: triggering an error is only the start of the chain. JFrog's independent analysis walks through an example of the stale-bookkeeping path.
Wiz also demonstrated disclosure of PHP process memory, including secrets such as passwords, tokens and API keys. Information disclosure can be serious on its own and can help an attacker develop a code-execution chain. Its upload-progress example shows how PHP can decode session state during early request processing, before the application executes. Reference: Wiz's technical analysis.
Successful code execution initially runs with the PHP worker's privileges. What the attacker can then reach depends on that account's access, the files and secrets available to it, and the surrounding isolation. This does not automatically give an attacker root access.
How to Patch PHP2Shell on PHP 8
PHP released the following fixes on 21 October 2026 for the two original CVEs. These are the first fixed releases in each supported branch; use the current vendor-supported package containing the fixes.
Source: PHP's security announcement. PHP 8.2 reaches the end of upstream security support on 31 December 2026, according to the support schedule, so its emergency update should sit alongside a plan for the next supported branch.
The OOM fix replaces the abrupt escape with a soft failure at a VM safe point and immediate termination past a higher threshold. Other fixes reset long-lived state at request boundaries. JFrog's analysis explains the patch mechanics, while the PHP Foundation's account discusses the compatibility work.
1. Identify the PHP Runtime Serving the Application
For an initial inventory, these commands are useful:
php -v
php --iniThey describe the command-line PHP installation. A server may have multiple PHP versions, FPM pools, Apache modules or containers. Match the application to its web-serving runtime, package source, extensions and configuration before deciding which update it needs.
For a managed hosting service, ask the provider which PHP package revision addresses both CVEs and which sites or pools have received it.
2. Deploy the Patched Runtime Through Its Supported Channel
Use the security update supplied by the distribution, hosting provider or runtime vendor. Keep the installed PHP components and extensions consistent with that package set. For containers, rebuild from a verified patched base image and replace the running workloads. Existing containers keep running the old image until you replace them.
A vendor may backport a fix while retaining an older-looking upstream version number. Check its advisory and full package revision when verifying patch status.
3. Restart the Serving Workers and Verify the Application
Make sure the actual serving processes have been replaced or restarted, including every instance behind a load balancer. Check the running runtime and test the application paths that matter: login, publishing, uploads, imports, checkout and integrations, as applicable.
For a CMS or ecommerce platform, also check the vendor's runtime compatibility requirements. A patch within a supported PHP branch and a move to a different PHP branch have different compatibility implications.
The 23 October Follow-Up
PHP published a further informational advisory on 23 October about an unusual session-upload-progress configuration, to be tracked as CVE-2026-115560. It involves switching the session serialisation handler at runtime while upload progress is enabled.
The advisory recommends keeping session.upload_progress.enabled=0 where applicable until the next regular bugfix release; applications that never switch the handler at runtime can keep the feature enabled. Check the current PHP notice alongside the original updates.
What About PHP 7, PHP 5 and Older PHP 8 Branches?
PHP 8.1 and older no longer receive normal upstream security releases. PHP's announcement nevertheless links exceptional minimal source backports for PHP 7.4, 8.0 and 8.1. These require a maintained build and testing process; they do not restore ongoing upstream support. Reference: PHP's announcement.
Distribution and extended-support packages provide another possible route:
- Zend's announcement confirms PHP2Shell fixes for its covered PHP 7.2, 7.3, 7.4, 8.0 and 8.1 releases.
- TuxCare's PHP2Shell FAQ describes backports for its supported alt-php branches: PHP 5.2–5.6, 7.0–7.4 and 8.0–8.5. Availability depends on the operating system, architecture and package channel.
Confirm that your vendor covers both CVEs for your exact PHP branch, operating system, architecture and package revision.
If a suitable patched package exists, deploy it and plan the move to a supported PHP branch. Otherwise, decide whether the application can remain accessible, with which restrictions, while it is still vulnerable.
Our PHP 5.6 Response: Compensating Controls
We had legacy PHP 5.6 applications with no patch available to our team, so we made configuration changes, implemented WAF rules and applied an IP whitelist.
We edited php.ini to set the following values:
; Disable session upload progress
session.upload_progress.enabled = 0
; Remove PHP's own allocation limit: see the resource tradeoff below
memory_limit = -1
; Set POST-data and individual file upload limits
post_max_size = 32M
upload_max_filesize = 16MDisabling upload progress targets the documented session paths. It needs to take effect before request parsing, with every worker restarted. Other stale-state paths can remain. The researchers' mitigation guidance explains that scope.
memory_limit=-1 removes PHP's allocation cap to avoid the predictable limit-triggered OOM path. Underlying allocation failure remains possible. Assess an external memory boundary, such as a container or cgroup limit, and what happens when the application reaches it. The researchers' guidance also cautions against substituting RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure.
The 32M POST-data limit and 16M per-file upload limit also need to fit legitimate application workflows. The PHP manual explains the relationship between those two settings. The OOM advisory also recommends frontend controls on decoded request input.
WAF Rules and IP Whitelisting
We added WAF rules for request filtering and used an IP whitelist to restrict access to approved source addresses.
WAF protection depends on the requests a rule recognises and the paths passing through it. Cloudflare's technical write-up, for example, describes configuration-specific coverage. Check the current rules and make sure direct requests cannot bypass the WAF.
With an IP whitelist, legitimate users, integrations and support connections need an approved access path. That can change how a public-facing application is used.
These controls leave PHP unpatched. Record the remaining risk and set a review date.
Patching and Investigating Need to Run Together
Patching does not tell you whether someone exploited the server earlier.
AWS reported an exploitation attempt in MadPot telemetry from 17 October 2026, before disclosure. It also made clear that analysis was ongoing and whether those attempts would succeed on real systems was uncertain.
Review web-server, proxy and PHP logs alongside endpoint evidence. Look into unusual request patterns, repeated failures, worker churn, unexpected files or processes, and suspicious outbound activity. One error message cannot establish exploitation, and a quiet application log cannot rule it out.
This is one reason I value visibility across the stack. In my Wazuh homelab post, I wrote about moving beyond running systems to understanding what they are doing.
Where AI Fits Into This
Wiz describes using AI during discovery, exploit development and patch validation. Its report also explains how differences between PHP builds and memory layouts required adaptation and testing.
I think we need to be ready to act on these findings sooner. A current inventory, named application owners, tested updates and clear vendor responsibilities make that easier.
The PHP Foundation's account is also worth reading. It describes the engineering and coordination behind the fixes, and the need for experienced maintainers even as research tools become more capable.
For each PHP application, I want to know who owns it, which runtime it uses, and what is stopping it from moving to a supported version. Any temporary controls need a review date and a clear next decision.
Technical details and patch guidance checked on 25 October 2026. Refer to the linked PHP and vendor advisories for subsequent updates.