php2shell: two critical PHP flaws require urgent updates

Published on October 22, 2026 · Explorer Soft

PHP has released emergency fixes for two critical vulnerabilities that can allow attackers to run code without signing in. Known together as php2shell, the flaws affect the software that executes PHP applications. Website owners need to update the PHP installation serving their sites, then restart the affected processes and check that the new version is in use.

What the vulnerabilities do

The PHP team published fixes for CVE-2026-109618 and CVE-2026-109619 on October 21, 2026. Updating a CMS, its plugins or its Composer dependencies does not fix these flaws: the underlying PHP installation needs the security update. [1]

CVE-2026-109618 concerns how PHP handles running out of memory. An interrupted operation can leave internal data only partly initialized; when PHP later cleans up the request, it can use that data incorrectly. The PHP advisory describes a demonstrated attack against Apache with mod_php that runs before the application itself. PHP-FPM terminates a worker if this failure occurs during request startup, but the advisory also identifies possible attack paths during application execution. [2]

CVE-2026-109619 involves data left over from an earlier request. A worker process can retain a reference to memory that has already been freed, then use it while handling a later request. Whether an attacker can exploit this depends on the configuration and the operations they can trigger. Turning off error display does not resolve the problem. [3]

In its October 21 alert, the Canadian Cyber Centre cited reports of a publicly available proof of concept, while stating that it had not identified active exploitation at that point. That finding is time-specific and offers no assurance about an individual installation. [9]

Which versions contain the fixes?

For packages built directly from PHP's releases, the first fixed version in each supported branch is shown below. [1]

PHP branch	First fixed release
8.2.x	8.2.35
8.3.x	8.3.36
8.4.x	8.4.27
8.5.x	8.5.12

Linux distributions may apply the same fixes to an older PHP version without changing its main version number. This is called backporting. Check the complete package version against your distributor's security advisory before deciding whether a system is vulnerable. Red Hat explains this distinction in its backporting guidance. [8]

For example, Ubuntu lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS as fixed for both vulnerabilities. Those are specific Ubuntu package releases; the shorter numbers “8.3.6” and “8.1.2” alone do not establish that the fixes are present. [4] [5]

PHP 8.1 and older branches no longer receive regular security releases from the PHP project. If you still use one, check whether your long-term support provider supplies the fixes and plan a move to a supported branch.

Find the PHP installation that actually serves the site

A server can run several PHP versions at once. The result of php -v tells you which version the command line uses; it may differ from the version handling web requests.

For each domain, record its PHP handler, executable path, package or container image, and the person responsible for updating it. Include separate FPM pools, Apache modules, CGI and LSAPI installations, FrankenPHP, and PHP bundled with other products. Prioritize sites exposed to the internet. The PHP team considers the risk highest for mod_php. [1]

Check the web server's virtual host and FastCGI configuration. If you need to confirm the version through a web request, use a temporary, access-restricted page that reports only PHP_VERSION and PHP_SAPI, then remove it. Avoid leaving a public phpinfo() page on the server.

How to update common deployments

Save the current configuration and check your backups before making changes. Allow time for a restart and application tests. The examples below need to be adapted to the packages and services your site uses.

Ubuntu and Debian

First identify the repository supplying PHP and the installed components. Ubuntu's USN-8948-1 lists its fixed packages. For Debian, use Debian's own security tracker and advisory; Ubuntu package numbers do not apply. Update the shared PHP components, the Apache module or PHP-FPM service, and the required extensions together. [6]

# Example: Ubuntu 24.04 with PHP 8.3 FPM from Ubuntu's repositories
sudo apt update
apt-cache policy php8.3-common php8.3-fpm php8.3-cli
sudo apt install --only-upgrade php8.3-common php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm

Review the proposed package changes before accepting them. For Apache with mod_php, also update libapache2-mod-php8.3, run apache2ctl configtest and restart Apache. Where multiple PHP versions are installed, check each service separately. Restarting Nginx does not replace the PHP-FPM processes behind it.

RHEL, AlmaLinux, Rocky Linux and third-party repositories

Check the vendor, operating system release and PHP package stream, then consult that vendor's errata for both CVEs. A fix listed for RHEL does not automatically establish the status of another distribution. Red Hat rates CVE-2026-109618 as Important and explains why exploitation is harder in its standard FPM deployments; those systems still need updating. [7]

# These commands list packages and advisories; they do not install updates
rpm -qa 'php*'
dnf updateinfo info --cves CVE-2026-109618,CVE-2026-109619

Once your vendor has provided a fixed package, update the relevant components and restart the FPM or Apache service that uses them. Changing repositories or PHP streams just to obtain a higher version number can introduce compatibility problems; check the package's security status first.

Docker and Kubernetes

Choose a base image containing a fixed PHP release or a patched distribution package, rebuild the application image and test it. Use --pull to fetch a fresh base image when building: Docker's --no-cache option alone does not do this. [11]

Deploy the new image and check its digest on every replica. Pulling an image without replacing the running containers leaves the old processes in place. Likewise, restarting a pod with the same old image digest does not apply a fix. Check scheduled jobs, queue workers, standby deployments and autoscaling settings so they cannot bring the vulnerable image back into service.

Windows with IIS and FastCGI

Check which php-cgi.exe each IIS handler uses. Install a patched build with the correct architecture, thread-safety variant (TS/NTS) and compatible extensions, following PHP's IIS installation guidance. [12]

Installing the new build in a separate directory makes the change easier to control. Update the handler path, replace the old FastCGI processes through the appropriate recycle or restart, and confirm the version through a web request. Updating a PHP directory on the command-line PATH does not update an IIS handler pointing elsewhere.

Hosting panels and shared hosting

With CyberPanel/OpenLiteSpeed, Plesk or cPanel, check the PHP handler assigned to each domain. The panel may manage its own PHP packages, separate from the operating system's installation. Use the vendor's update procedure and check that it covers both vulnerabilities.

As of October 22, Plesk lists fixed PHP 8.2–8.5 packages for Linux and Windows. Its own panel engine, sw-engine, is fixed in Plesk Obsidian 18.0.81 Update 4 and 18.0.80 Update 11. For Plesk's Linux packages of PHP 7.4, 8.0 and 8.1, the build date also matters: the patched builds from October 21 retain their previous version numbers. [10]

On shared hosting, ask the provider to confirm the full PHP package version, that both fixes are installed, and that the affected processes have been restarted. A menu entry labelled “PHP 8.3” does not show whether the fixes are installed. With FrankenPHP, check the embedded PHP version in the replacement binary or container image.

Illustration of software updates across a server, containers and a workstation — Illustration generated with AI.

What if an update is not available yet?

Restrict public access to the vulnerable application while you arrange the update. Apply that restriction at a proxy or another suitable access control in front of the application. WAF rules may reduce exposure, but they cannot confirm that all ways of exploiting the flaws have been blocked.

The PHP advisories describe settings that interrupt specific attack paths. These include enforcing memory_limit=-1 at the administrative level for certain out-of-memory cases, disabling session.upload_progress.enabled, and, on PHP 8.5, disabling fatal_error_backtraces. None provides complete protection. Removing PHP's memory limit can also allow excessive memory use to disrupt the service, so it requires suitable container or cgroup limits and worker restarts. Treat these as temporary, carefully assessed measures while preparing the update. [2] [3]

Check the result, then look for signs of compromise

After updating, record the full package version or image digest and the vendor advisory covering both CVEs. Confirm that the web service uses the patched version after its processes restart. Test logins, file uploads, sessions, APIs and background jobs, then watch error rates, memory use and response times.

If the updated version causes a compatibility problem, keep the affected service restricted while you find a compatible patched build. Returning public traffic to a vulnerable version restores the original exposure.

The Canadian Cyber Centre recommends checking for unusual processes, files, accounts and outbound connections associated with PHP or web server services. [9] Compare web server and PHP logs with the activity recorded by your endpoint monitoring tools. An out-of-memory error or an HTTP 500 response alone does not prove an attack. If you find evidence of compromise, preserve it, isolate the affected system and investigate. Installing a patch will not remove a backdoor or other changes an attacker has already made.

For future incidents, keep an inventory of PHP installations and their owners, subscribe to security release notices, and rehearse the update and recovery process. Separate sites into appropriate user accounts and process pools, limit write permissions and outbound access, and retain logs away from the web server. These measures make urgent updates easier to manage and help contain damage if a site is compromised.

Need help updating PHP?

Tell us about your website and hosting setup. We will get in touch to discuss how we can help.

.article-contact .article-contact-form{display:none}You can email us directly at info@720explorer.space. Enable JavaScript to use the form.