PHP2Shell Vulnerability 2026: Affected Versions & Fixes

What should you do now? Install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a later security release in your supported branch. A distribution or hosting vendor may instead provide a verified backported fix. Replace the running PHP workers after updating, then verify the website’s actual PHP runtime.

Important update: 23 October 2026. PHP has also published guidance about an unusual session upload progress RCE path, tracked as CVE-2026-115560. Review the additional setting below, including after installing the 21 October fixes.

In this guide

• What the vulnerabilities mean
• Affected and patched versions
• Who handles the update?
• How to check your PHP version
• Ubuntu and Debian updates
• RHEL, AlmaLinux and Rocky Linux
• Panels, containers and Windows
• 23 October session guidance
• How to verify the patch
• Frequently asked questions

What is the PHP2Shell vulnerability?

PHP2Shell describes two memory safety vulnerabilities in PHP’s request handling. Under exploitable conditions, an attacker can send requests that make PHP handle internal memory incorrectly. This can lead to remote code execution without logging in. The published severity is CVSS v4.0 9.2 out of 10: Critical.

CVE-2026-109618: Out-of-memory corruption

PHP allocates memory while preparing and processing a request. If an allocation fails at the wrong point, PHP can exit that operation while internal data is only partly prepared. The cleanup process may then use that unfinished data as if it were valid.

Think of it as a worker being told to tidy a desk using instructions that were never fully written. In PHP, that mistake can become memory corruption and, in a working exploit, execution of an attacker’s code.

The official advisory confirms unauthenticated code execution over HTTP against Apache’s mod_php. The code runs with the web worker account’s permissions; this does not automatically mean root access. PHP-FPM also needs patching, although its handling of failed request startup blocks that particular startup sequence.

CVE-2026-109619: Stale state between requests

A PHP worker may handle many requests over its lifetime. Some internal state can incorrectly keep pointing to memory belonging to an earlier request after that memory has been freed. A later request may use that old reference before PHP resets it.

This is a use-after-free problem. Successful exploitation depends on the application, configuration and reachable operations. The official advisory describes confirmed mod_php exploitation and a validated PHP-FPM path that depends on a suitable application operation. Switching from Apache to Nginx or PHP-FPM is therefore not a complete fix.

What could happen to an affected website?

Wiz Research reports potential server takeover and disclosure of PHP process memory. Depending on what is present in memory and what the worker can access, exposed information could include passwords, tokens and API keys. Its demonstrations included WordPress, Drupal and Joomla, but the issue is in PHP itself, so those applications are not the complete list of possible targets.

A vulnerable server is not proof of a hacked server. However, AWS reports exploitation attempts against its MadPot sensors dating back to 17 October 2026. AWS also says it is unclear whether those early attempts would have succeeded on real-world systems. Treat the patch as urgent without assuming that every exposed website has been compromised.

Which PHP versions are affected, and which versions fix PHP2Shell?

For the supported upstream branches, use this table to identify the first fixed release. Install a newer security release in the same branch if one is available when you update.

Older PHP is also a concern. Wiz reports that versions going back to PHP 5.4 are affected by at least one of the issues. That does not mean every old version has both flaws or identical exploit conditions.

PHP 8.1 and older have ended upstream support. Some vendors supply maintained fixes, and PHP has provided exceptional minimal source backports for 7.4, 8.0 and 8.1. These are not a restoration of normal upstream support. Use your vendor’s maintained package or plan an upgrade to a supported branch. PHP 8.2 security support ends on 31 December 2026, so users on that branch should also plan their next upgrade.

Why an older-looking PHP version might already be patched

A backport applies a security fix to an older package while keeping its base PHP version. Check the complete package version against the advisory for your operating system and repository.

For example, Ubuntu’s USN-8948-1 lists these fixed package versions:

These examples apply to the packages and Ubuntu releases in that notice. They do not certify a third-party build with a similar number.

Debian’s tracker lists 8.2.35-1~deb12u1 for Bookworm security and 8.4.27-1~deb13u1 for Trixie security as fixed for CVE-2026-109619; check both CVE tracker entries for your release.

Managed hosting vs VPS and cloud hosting: who must patch PHP?

On a managed plan that includes PHP runtime maintenance, the hosting provider normally installs the server patch. On a self-managed VPS or cloud virtual machine, you or your server administrator must arrange the update. Confirm the responsibility in your actual service plan.

“Cloud hosting” does not mean PHP is automatically maintained. Google Cloud’s incident guidance illustrates the difference: supported App Engine standard runtimes are patched automatically, while custom images, GKE workloads and some Cloud Run deployments need customer action.

If you do not manage the server, send your provider this request:

Please confirm that the PHP runtime serving my domain has fixes for CVE-2026-109618 and CVE-2026-109619. Please provide the full package or build version, confirm the running workers were replaced, and confirm that you have reviewed PHP’s 23 October session upload progress guidance.

How to check your current PHP version

1. Check the command-line version

Connect to your own server over SSH and run:

php -v
php --ini

The first command shows the PHP version used by that command. The second shows its configuration files. This is the command-line runtime, which can differ from the PHP version serving your website. A missing php command also does not prove that no website uses PHP; a panel, container or custom path may provide it. PHP documents these command-line options in its manual.

2. Check the website’s runtime

Start with your hosting panel or application’s system information page. If you need a direct check, a developer can temporarily place this small file behind server-level access control on the same virtual host and PHP handler:

<?php
header('Content-Type: text/plain; charset=utf-8');
header('Cache-Control: no-store');
echo 'PHP version: ', PHP_VERSION, "\n";
echo 'PHP handler: ', PHP_SAPI, "\n";
echo 'Loaded INI: ', php_ini_loaded_file() ?: '(none)', "\n";
echo 'Session upload progress: ',
    ini_get('session.upload_progress.enabled') ? 'enabled' : 'disabled', "\n";

Open it through that domain, record the result and delete the file immediately. Avoid leaving a public phpinfo() page online. PHP’s manual explains how version reporting and configuration loading work.

Repeat the check for each domain, PHP handler and backend server. With vendor backports, also verify the installed package revision; a browser version string alone is not enough.

Before updating: identify how PHP was installed

The commands below are examples for the stated environments. They are not a universal script. Package names, enabled repositories and service names vary.

• Record your operating system, PHP packages and web handler. On Linux, cat /etc/os-release identifies the OS.
• Take an application-consistent database backup and preserve your application and server configuration. A VM snapshot can be an additional recovery point.
• Use a short maintenance window or a rolling update across healthy backends. Keep emergency patch testing focused on essential business functions.
• Keep the package source that maintains your installation. Panel-managed, containerized and source-built PHP need their own update route.

Updating within your existing maintained PHP branch usually gives a smaller compatibility change than switching branches. Unsupported installations need either a confirmed vendor fix or a planned supported-version migration.

How to patch PHP on Ubuntu or Debian

Use this route for PHP maintained through your server’s APT repositories. Ubuntu documents refreshing the package index and upgrading installed packages as the normal update process.

Step 1: Inventory the installed PHP packages

cat /etc/os-release
dpkg -l 'php*' 'libapache2-mod-php*'
apt-mark showhold

In dpkg -l, rows starting with ii are installed packages. Note every PHP branch, the web handler and installed extensions.

Step 2: Refresh and inspect the available update

sudo apt update
apt-cache policy php8.3-common php8.3-cli php8.3-fpm
sudo apt-get -s upgrade

The package names above are a PHP 8.3 example; substitute the packages actually installed on your machine. Compare the installed and candidate versions with your vendor’s notice. The simulation shows the proposed system upgrade without installing it.

Step 3: Install the update

sudo apt upgrade

This updates eligible installed packages across the system, not only PHP. Review the proposed transaction. Update every installed PHP branch used by an application, together with its associated common, CLI, FPM or Apache module packages and extensions. Resolve held or kept-back PHP packages rather than assuming the command patched everything.

If there is no fixed candidate, check your security repositories, package source and vendor support entitlement. Ubuntu’s older-release notice lists some fixes under Ubuntu Pro or its Legacy Support add-on; availability is not identical on every installation.

Step 4: Restart the PHP runtime that serves the website

List services to identify their actual names:

systemctl list-units --type=service --all 'php*-fpm.service'

For an installed PHP 8.3 FPM service, this is an example:

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

For Apache running PHP as mod_php on a typical Debian or Ubuntu installation:

sudo systemctl restart apache2
sudo systemctl status apache2 --no-pager

Run the restart appropriate to your handler. Restart every relevant FPM service if multiple PHP branches are active. Restart long-lived PHP application workers through your process manager as well. Restarting Nginx alone does not replace PHP-FPM processes.

How to patch PHP on RHEL, AlmaLinux or Rocky Linux

Use this route for system PHP packages maintained through DNF. AlmaLinux, Rocky Linux and third-party repositories publish their own builds and advisories; verify the release for your actual vendor. Red Hat confirms affected RHEL products and directs customers to its incident bulletin for evolving package availability.

cat /etc/os-release
dnf list installed 'php*'
sudo dnf --refresh check-update 'php*'
sudo dnf updateinfo info --cve CVE-2026-109618
sudo dnf updateinfo info --cve CVE-2026-109619

dnf check-update returns exit code 100 when updates are available; this is expected. CVE-filtered results depend on the repository publishing advisory metadata. No matching output is not proof that the server is safe.

For the standard system package names, review and apply:

sudo dnf upgrade --refresh 'php*'

Keep the pattern quoted so the shell does not expand it into local filenames. Check the transaction covers every PHP package in use. Names such as ea-php*, alt-php* or version-prefixed software collections require their vendor’s package route.

For the standard php-fpm service:

sudo systemctl restart php-fpm
sudo systemctl status php-fpm --no-pager

If your installation actually uses Apache mod_php, restart its httpd service instead. Custom collections can have different service names. Red Hat’s DNF documentation covers package and security updates.

How to update PHP in other hosting environments

cPanel and WHM

Server administrators should use WHM → Software → EasyApache 4 → Run System Update to update installed EasyApache packages. Then use MultiPHP Manager to confirm the PHP branch and handler assigned to each domain. Updating the system’s default PHP alone may miss a website assigned another branch. A shared-hosting customer should request this work from the host.

Plesk

Follow Plesk’s PHP2Shell advisory and install the latest applicable PHP component and Plesk updates. Its notice includes fixes for the PHP engine used by the panel itself: Plesk Obsidian 18.0.81 Update 4 and 18.0.80 Update 11.

Plesk also documents Linux rebuilds of PHP 7.4.33, 8.0.30 and 8.1.34 with unchanged base version numbers. Its fixed builds are dated 21 October 2026. Check the complete vendor build information, not just php -v, and replace the affected runtime processes.

Docker and Kubernetes

Updating PHP on the host does not update PHP inside an existing container. Change the image reference or Dockerfile to a verified patched build that preserves your required PHP variant and extensions.

For a Compose service built from your Dockerfile, these are example commands. Replace php-service with the real service name:

docker compose build --pull --no-cache php-service
docker compose up -d --no-deps --force-recreate php-service
docker compose exec php-service php -v

Docker documents --pull as requesting a newer base image. It cannot help if your Dockerfile still pins a vulnerable version or digest. For a service using a prebuilt image, update its reference, pull it and recreate the service instead of running a build.

In Kubernetes, update the workload’s image and complete the rollout to all pods. Google Cloud’s guidance explicitly requires updating affected GKE images and redeploying. Verify that old replicas and rollback targets will not reintroduce vulnerable PHP.

Windows, custom stacks and source-built PHP

For manually managed Windows PHP, obtain the fixed package from PHP’s official download channel. Match the required architecture, Thread Safe or Non Thread Safe build, web-server integration and extensions. Test it with your configuration, switch the web handler to the new installation and replace its running processes. Bundled stacks should follow their stack vendor’s update instructions.

For source-built PHP, rebuild a fixed official release with your existing required build options and compatible extensions, then redeploy it. Package-manager commands will not replace a separate custom binary.

23 October update: review session upload progress after patching

PHP’s additional advisory suggests keeping this setting disabled until the next regular bugfix release:

session.upload_progress.enabled=0

The unusual path requires a configured php_binary or php_serialize session handler, a runtime switch to php before session_start(), and enabled session upload progress. Applications that never change the serialize handler at runtime can keep the feature enabled. PHP identifies the follow-up issue as CVE-2026-115560.

Apply the setting in the web runtime’s startup configuration and restart its workers. For example, on a conventional Debian or Ubuntu PHP 8.3 FPM installation, edit the loaded FPM configuration, often /etc/php/8.3/fpm/php.ini, and restart php8.3-fpm. Confirm the actual path for your installation.

For this early request-processing control, do not rely on an application’s ini_set() or FPM .user.ini. PHP’s stale-state advisory requires configuration that takes effect before request parsing. Check whether disabling upload progress affects your application’s progress indicator.

This setting is additional guidance. It does not replace the PHP2Shell runtime update.

How to verify that the PHP patch is active

Use this verification sequence after updating each server:

• Check packages: record the full installed package revision or image digest and match it to the correct vendor advisory.
• Check live PHP: confirm each domain’s web runtime, not only the SSH command-line version. On multiple backends, check each instance directly through an authorized route.
• Check processes: ensure every relevant PHP worker was replaced and services are healthy. Review failed restarts and startup errors.
• Check the application: test login, enquiry forms, file uploads, checkout or payments, API requests and scheduled tasks as applicable.
• Check deployment sources: update templates, container builds and deployment configuration so the next deployment uses the fixed build.

Keep the output, deployment time and vendor notice with your maintenance record. A successful package download alone does not show what is running.

What if you cannot patch immediately?

PHP’s release announcement states that updating is the complete solution. A WAF or reduced upload limits should not be treated as proof of safety.

Ask your administrator to apply the current official temporary guidance while arranging the update. Avoid casually copying the emergency memory_limit=-1 mitigation: it removes PHP’s normal per-request memory ceiling and requires careful resource controls.

The UK NCSC recommends considering taking an affected system offline if temporary mitigations cannot be applied promptly. It also recommends checking for evidence of compromise and backdoors where immediate updating or disabling was not possible.

Does patching remove an existing compromise?

No. A runtime update closes the vulnerable code paths; it does not remove files, accounts or persistence already created by an attacker. If compromise is suspected, preserve evidence, investigate affected systems and recover through an incident response process. Review logs extending back at least to the earliest reported attempts on 17 October, rather than starting only on disclosure day.

PHP2Shell FAQs