PHP2Shell: How to Patch CVE-2026-109618 and CVE-2026-109619, and Verify Your PHP Runtime Is Patched

Updating WordPress will not fix PHP2Shell.

Neither will updating your plugins, changing your administrator password, or installing another WordPress security plugin.

On 21 October 2026, the PHP project released emergency security updates addressing two critical vulnerabilities in the PHP interpreter itself: CVE-2026-109618 and CVE-2026-109619.

Both have a CVSS v4.0 severity score of 9.2. Under specific conditions, an unauthenticated attacker can execute code on a server running vulnerable PHP.

These are not vulnerabilities in WordPress, Drupal, Laravel or any particular application. They exist in PHP's request processing and memory management.

In one demonstrated attack involving Apache mod_php, exploitation can happen before application code executes. That means application-level authentication, security plugins and normal request validation may never have an opportunity to intervene.

For businesses running PHP applications, the priority is to identify the PHP runtime serving each website, install the appropriate security update, restart the affected processes and verify that the fix is actually running.

There is one complication: the PHP version displayed by a hosting dashboard or the php -v command is not always sufficient to determine whether a system is patched.

This guide explains the vulnerabilities, fixed versions, vendor backports, temporary mitigations and practical verification steps.

PHP2Shell: The key facts

The impact extends beyond a single content management system.

Cloudflare, citing W3Techs, reported that PHP was used by almost 70% of websites at the time of disclosure. The widespread use of PHP explains why a vulnerability in the interpreter can affect a much larger range of applications than a typical plugin or framework security issue.

Sources: PHP security announcement, PHP's CVE-2026-109618 advisory and severity score, PHP's CVE-2026-109619 advisory and severity score, Cloudflare and AWS Security.

What are CVE-2026-109618 and CVE-2026-109619?

Although they were disclosed together, these are two distinct memory-safety vulnerabilities.

CVE-2026-109618: Memory corruption during out-of-memory handling

PHP enforces memory limits to restrict how much memory a request can consume.

Under certain circumstances, PHP can encounter an out-of-memory condition while internal request data has been only partially initialised.

When request processing stops, the cleanup process may incorrectly handle that unfinished data. The resulting memory corruption can potentially be exploited to execute attacker-controlled code.

The PHP security advisory confirms that Apache mod_php is particularly exposed because the vulnerable cleanup sequence can occur before the application begins executing.

This distinction matters for applications such as WordPress.

An attacker does not necessarily need to authenticate, identify a vulnerable plugin or reach application-specific PHP code to trigger the demonstrated mod_php attack path.

Official advisory: GHSA-w8hw-w9fx-j79w.

CVE-2026-109619: Stale internal state between requests

PHP workers often process multiple HTTP requests during their lifetime.

The second vulnerability involves internal state that can remain accessible after the memory belonging to an earlier request has been released.

When another request reaches the same worker, PHP may reference that stale state before it has been properly reset.

This creates a use-after-free condition.

Researchers demonstrated that the flaw can lead to remote code execution and disclosure of memory belonging to the PHP worker.

Depending on the application, process memory may contain authentication tokens, database credentials, API keys and other sensitive information.

Confirmed attack paths include PHP's session upload-progress handling. PHP-FPM is also affected, although the conditions required for exploitation vary across server interfaces and applications.

Official advisory: GHSA-6wmf-4rv5-p3rp. Research background: Calif's PHP2Shell technical analysis.

Does every affected PHP installation have the same risk?

No.

The PHP project identifies every installation serving web requests as requiring attention, but exploit reliability depends on the PHP build, configuration, server interface, extensions and available attack paths.

Apache mod_php has a demonstrated application-independent attack path.

PHP-FPM has other confirmed attack paths, including session-related conditions that can involve multiple requests reaching the same worker.

These distinctions affect incident investigation and temporary mitigation choices. They do not change the recommendation to patch affected PHP installations.

Which PHP versions fix PHP2Shell?

The PHP project published four security releases on 21 October 2026.

PHP also published minimal source-level backports for PHP 7.4, 8.0 and 8.1.

These are not new official releases of those unsupported PHP branches.

Some Linux distributions and commercial long-term support providers deliver security updates to older versions through their own package maintenance processes.

For those installations, the vendor's complete package revision and security advisory determine whether the fix is present.

A version that appears older than PHP's published fixed release is therefore not automatically unpatched.

Source: PHP release announcement, 21 October 2026.

Why php -v does not prove your website is patched

One of the easiest mistakes during a PHP security incident is treating the version string as the complete security assessment.

Consider the command:

php -v

It reports the installed command-line PHP version.

It does not necessarily identify the PHP runtime serving incoming web requests.

A hosting environment may use different PHP installations for command-line tasks, web applications and internal control-panel components.

There is also the question of security backports.

A Linux distribution may apply a security patch to an older upstream version while retaining the original PHP version number.

That means two systems displaying the same PHP version can have different security states.

Example: Ubuntu 24.04 LTS

Ubuntu's official security notice USN-8948-1 identifies this fixed PHP 8.3 package revision:

8.3.6-0ubuntu0.24.04.13

Compare that with PHP's first fixed upstream release:

8.3.36

Both can contain the relevant security fixes.

The Ubuntu build includes distribution-maintained patches even though its upstream version component remains 8.3.6.

An administrator can inspect the complete package revision using:

dpkg-query -W 'php8.3*'

Check available packages:

apt-cache policy php8.3-fpm

Where the packaged changelog is present, inspect it for the CVE references:

zgrep -E 'CVE-2026-10961[89]' \
  /usr/share/doc/php8.3-common/changelog.Debian.gz

A missing changelog entry is not definitive proof of exposure. The complete package revision should be compared with the official vendor advisory.

For Ubuntu 24.04, the published fixed revision is 8.3.6-0ubuntu0.24.04.13.

Other Ubuntu releases have different package names and revision numbers. Do not reuse the 24.04 package number as a universal test.

Reference: Ubuntu Security Notice USN-8948-1.

What should WordPress administrators check?

In WordPress, open:

Tools > Site Health > Info > Server

Record the PHP version reported for the website.

This provides a useful starting point, but it does not necessarily establish the vendor patch revision.

If the hosting provider controls PHP updates, request confirmation that:

1. Both CVE-2026-109618 and CVE-2026-109619 have been fixed in the PHP runtime serving the website.
2. The installed build corresponds to an official patched version or documented vendor backport.
3. Relevant PHP processes have been restarted after patching.
4. Other environments serving the same application have been included in the update.
5. The provider has reviewed relevant security events during the exposure period.

Updating WordPress core, Elementor, WooCommerce, Wordfence or another plugin does not replace the PHP security update.

These components have their own security maintenance requirements, but PHP2Shell exists at a different layer.

cPanel and CloudLinux: Why there can be more than one PHP update

On cPanel-based hosting, website PHP and the internal PHP used by control-panel services may be maintained separately.

Checking only one does not establish that both have received the PHP2Shell fixes.

For websites, cPanel publishes patched EasyApache4 package versions.

CloudLinux also publishes security updates for its own PHP packages, including versions that retain older upstream numbers.

An example from cPanel's October 2026 advisory is the CloudLinux EasyApache4 PHP 8.4 package:

8.4.26-2

The first fixed upstream PHP 8.4 release is 8.4.27.

The lower-looking number does not necessarily indicate that the CloudLinux package is vulnerable. The vendor's security backport and complete package revision matter.

Where administrative access permits, the package changelog can be examined using the applicable PHP branch:

rpm -q --changelog ea-php84-php-cli \
  | grep -E 'CVE-2026-(109618|109619)'

Administrators should also confirm the relevant cPanel & WHM security update and any separate CloudLinux PHP variants.

For shared hosting customers without package-level access, documented provider confirmation is a valid part of verification.

Sources: cPanel security advisory and CloudLinux guidance.

Docker and Kubernetes: A patched image is not a patched deployment

PHP security updates also matter in container-based deployments.

Updating an image in a registry does not automatically update containers already running in production.

For example, an application built from a PHP base image can continue using the vulnerable runtime until its image is rebuilt and the workload is replaced.

A correct container remediation process includes:

1. Identify the deployed PHP image and version.
2. Confirm an updated image contains both PHP security fixes.
3. Rebuild dependent application images.
4. Deploy the new images.
5. Confirm that all running replicas use the patched image.
6. Verify application health after deployment.

For Kubernetes deployments, check the image digests used by the running pods rather than relying only on image tags.

For Docker Compose, recreating the service is necessary after producing or obtaining the fixed image.

The security state that matters is the PHP runtime actually serving requests, not the version available in a registry or the completion of a build pipeline.

How to respond to PHP2Shell

The remediation process should be organised around verification, not just performing an update command.

Step 1: Identify the affected PHP runtimes

Determine which PHP installation serves each application.

Include relevant control-panel components, application containers and additional environments that can receive traffic.

Document the PHP branch, package origin and responsible update mechanism.

Step 2: Install the appropriate security update

Use the official upstream PHP security release or a vendor-maintained package containing both fixes.

For unsupported branches, confirm whether a vendor supplies a documented backport and establish a migration plan.

Avoid unofficial patches or plugins claiming to fix the interpreter.

Step 3: Restart affected PHP processes

Installing a package does not guarantee that existing long-running PHP processes are using the updated executable or libraries.

Restart or recreate the appropriate PHP workers through the platform's supported maintenance process.

For container deployments, replace running workloads with the updated images.

Step 4: Verify the running version and package

Record the installed package revision and compare it against the official vendor advisory.

Confirm the expected runtime is serving the application.

Where applicable, verify worker replacement or process restart through service health information.

Step 5: Review the exposure period

Patching prevents continued exposure to the fixed code paths.

It does not prove the server was never compromised while the vulnerable code was running.

Review relevant application, web-server, PHP and security monitoring data for suspicious activity during the exposure period.

The AWS report of pre-disclosure attempts makes this step particularly important.

What if PHP cannot be patched immediately?

PHP published temporary configuration measures for environments where an update cannot be installed straight away.

These measures reduce exposure to particular attack paths. None is a complete fix for PHP2Shell.

The session upload-progress setting must take effect before PHP parses incoming request data.

Apply it through php.ini, a suitable PHP-FPM pool configuration or another applicable server-level mechanism.

Application-level ini_set() and PHP-FPM .user.ini settings are too late for this particular mitigation.

The memory_limit=-1 option also requires caution. It changes PHP's memory management behaviour and can increase the consequences of resource-heavy requests. It must not be applied casually without evaluating resource isolation and request limits.

PHP explicitly warns against using RLIMIT_AS or RLIMIT_DATA as substitutes because they can trigger the vulnerable allocation-failure path.

Restart the relevant PHP workers after changing applicable settings.

Where a patch cannot be applied and exposure cannot be adequately reduced, CERT-EU recommends considering isolation of affected public-facing applications until a fix is installed and verified.

References: PHP security guidance and CERT-EU advisory 2026-018.

Does Cloudflare protect against PHP2Shell?

Cloudflare announced WAF protections for known PHP2Shell attack patterns.

According to Cloudflare's 21 October technical announcement, protections were deployed for customers using its Free and paid WAF offerings.

Those rules provide an additional defensive layer.

They are not a substitute for updating PHP.

Two limitations are particularly important.

First, WAF filtering only applies to traffic passing through the relevant protection. Traffic that bypasses the protected path may not receive the same inspection.

Second, WAF rules identify recognised malicious behaviour. New attack variants or application-specific paths may not match existing signatures.

Cloudflare itself recommends applying the PHP security updates while keeping the WAF protections enabled.

Source: Cloudflare PHP2Shell protection announcement.

Has PHP2Shell been exploited?

Amazon Threat Intelligence published evidence of attempts against PHP2Shell before public disclosure.

Its MadPot honeypot telemetry recorded an exploitation attempt on 17 October 2026, four days before the PHP security updates became public.

AWS subsequently observed additional attempts on 21 October and activity following release of the patches.

Its report described broader exploitation activity, while also noting that the success of some observed attempts against real-world systems had not been established.

This distinction matters.

An exploitation attempt is evidence of malicious activity. It is not proof that any particular application was compromised.

For incident responders, 17 October is a useful starting date for reviewing historical evidence where logs are available.

Source: AWS Security, 21 October 2026.

How to investigate possible PHP2Shell compromise

A useful investigation should examine system and application behaviour rather than depend entirely on matching a known exploit string.

Relevant signals include:

• Unexpected PHP worker crashes, segmentation faults or restarts.
• Unusual memory exhaustion errors and bursts of HTTP 500 responses.
• Unexpected multipart upload activity.
• PHP or web-server processes launching shell commands or network utilities.
• Unexpected changes to application files or scheduled tasks.
• Unrecognised application administrator accounts.
• Unexplained outbound connections originating from web application processes.

These are investigative indicators, not definitive proof of PHP2Shell exploitation.

Some can also result from ordinary application faults or unrelated security incidents.

What to do if compromise is suspected

Preserve relevant logs and evidence before making destructive changes.

Isolate affected workloads where practical and investigate the permissions available to the PHP process.

Apply the security update and replace affected workloads where required.

Review filesystem integrity, persistence mechanisms, application accounts and unexpected changes.

Rotate credentials and secrets that may have been accessible to the PHP process, including database passwords, API credentials and authentication material.

Because CVE-2026-109619 can expose process memory, the investigation should account for the possibility of credential disclosure even without evidence of an ordinary application login.

Patching a compromised system does not automatically remove an existing backdoor.

The longer-term engineering lesson

PHP2Shell illustrates a recurring problem in production infrastructure: installing a package and verifying a running application are two different operations.

An organisation needs to know which runtime serves an application, where updates come from, how dependencies are rebuilt and how a corrected version reaches production.

That requires more than a periodic reminder to update software.

It requires a repeatable release process, visibility into deployed dependencies, controlled restarts and a way to confirm that every relevant workload has moved to the updated build.

The same problem appears with operating-system libraries, container base images, application frameworks and third-party dependencies.

ELASYN's DevOps and cloud infrastructure engineering work includes deployment pipelines, container orchestration, monitoring and production operations.

These practices are directly relevant to urgent security updates. A fixed package is useful only once it reaches the production processes that need it.

Our practical CI/CD pipeline guide explains how automated validation and controlled deployment make application releases more repeatable.

Frequently asked questions

Does updating WordPress fix PHP2Shell?

No. PHP2Shell affects the PHP interpreter. Updating WordPress core, themes and plugins is important, but the PHP runtime requires its own security update.

Is PHP-FPM vulnerable to PHP2Shell?

Yes. PHP-FPM is included in the PHP project's affected deployment types. The available attack paths and prerequisites differ from Apache mod_php, but PHP-FPM still requires patching.

Is PHP 8.3.6 vulnerable?

An unpatched upstream PHP 8.3.6 build is affected. However, Ubuntu 24.04 provides a patched PHP 8.3.6 package through a security backport. Check the complete package revision and relevant vendor advisory.

Can PHP 7.4 still be protected?

Some long-term support providers distribute security backports for PHP 7.4. PHP also published minimal source-level backports. These do not restore normal upstream support. A supported PHP branch remains the preferred long-term destination.

Does Cloudflare fix PHP2Shell?

No. Cloudflare can block recognised malicious request patterns, but the PHP runtime must still be updated. WAF protection is an additional control, not a runtime patch.

What information should I request from my hosting provider?

Ask for confirmation that both CVEs have been addressed, the full patched PHP package revision, confirmation that the runtime serving your website has been updated, and verification that affected PHP workers have been restarted.

Can PHP2Shell give an attacker root access?

The confirmed remote code execution impact is code execution with the permissions of the affected PHP worker. It does not automatically provide root access. Further impact depends on process permissions and other weaknesses.

Does patching prove a website was not compromised?

No. Installing the fix removes the known vulnerable code paths, but it does not establish that exploitation did not occur before patching. Review the exposure period and investigate suspicious activity where appropriate.

What Australian businesses should do now

For any business operating PHP-based applications, the immediate priorities are straightforward:

Confirm the runtime, verify the patched package, ensure the updated processes are running, and review earlier exposure.

Do not assume a green status indicator in a website dashboard establishes that the PHP interpreter has been fixed.

The important evidence comes from the runtime actually serving requests and the vendor's documented security update.

PHP2Shell is a reminder that application security depends on maintaining the software beneath the application as well as the application itself.

If your organisation needs help reviewing PHP patch status, rebuilding affected application deployments or establishing a repeatable infrastructure update process, speak with ELASYN about a technical review.

The initial consultation is free. Bring details of the application and hosting platform so the discussion can focus on the specific remediation requirements.

Primary sources and technical references

1. PHP Project: October 2026 security release
2. CVE-2026-109618: Official PHP security advisory
3. CVE-2026-109619: Official PHP security advisory
4. PHP Foundation: Security release and engineering background
5. Ubuntu Security Notice USN-8948-1
6. cPanel: Critical PHP Security Release
7. CloudLinux: PHP security package guidance
8. Cloudflare: PHP2Shell WAF protection
9. AWS: PHP2Shell exploitation observations
10. CERT-EU Security Advisory 2026-018
11. Calif: PHP2Shell technical research
12. Rapid7: PHP2Shell analysis and mitigation

Last reviewed: 22 October 2026. Vendor package availability, detection guidance and documented attack activity may change. Always consult current security advisories before applying changes.