Patch PHP Now: Fix the Critical PHP RCE on Your Hosting

If your website runs on PHP, update it to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor's patched package) as soon as you can. Those releases, published by the PHP project on 21 October 2026, fix two critical bugs, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on your server without logging in. The PHP team is blunt about it: "There are no complete mitigations, updating is the only safe choice."

Here is the part that surprised me. php.net says the risk is highest for Apache with mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any of your application code runs. Careful app code does not help.

By the end, you will know your real PHP version, whether it is patched, how to update it in cPanel, Plesk or on your own server, and which stop-gaps help if your host is not ready yet.

What the PHP2Shell bugs actually are

PHP is the language behind WordPress, Joomla, Drupal and many shops and custom apps. Every time a visitor loads a page, a PHP worker (a background process that handles one request at a time) builds the page and then cleans up after itself.

Both bugs live in that clean-up and reuse cycle. According to php.net, CVE-2026-109618 happens when out-of-memory handling interrupts PHP while internal request data is only half set up, and clean-up then treats that broken data as valid. CVE-2026-109619 happens when state that belongs to one request survives after its memory was freed, and a later request on the same worker uses that stale state.

Think of a hotel room. Housekeeping is supposed to reset everything between guests. These bugs are like a skipped reset, so the next guest finds the previous guest's key card still working. An attacker can be that next guest.

Both bugs are rated CVSS v4.0 9.2, which is in the critical range. The Singapore Cyber Security Agency (CSA) calls them "PHP2Shell" in alert AL-2026-151 and, in its version updated on 22 October 2026, says "There have been reports of widespread exploitation attempts targeting these vulnerabilities." Canada's Cyber Centre alert AL26-026 says a proof of concept is reported to be available, "with no active exploitation being identified at this time, but that can change quickly." The sources differ, so patch.

Why this matters: php.net says the risk covers "all PHP installations serving web requests," and names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. If a web server runs PHP, it is in scope.

Before you start

Give yourself 15 to 60 minutes, depending on whether you are on shared hosting or managing your own server. Check that you have these:

• Your hosting control panel login (cPanel or Plesk), or SSH access with sudo rights if you run your own VPS or dedicated server.
• Your WordPress admin login, if the site is WordPress.
• A fresh offsite backup of files and database (see back up your website in cPanel with an offsite copy), plus a provider snapshot on a VPS.
• A list of every site and app on the server, including old ones you forgot about. CSA advises checking whether PHP is installed on web servers even where your main sites do not use it, because third-party apps may rely on it.
• A quiet time window, since restarting PHP and the web server briefly interrupts requests.

Risk level: a patch release within the same PHP branch (for example 8.3.35 to 8.3.36) is low risk. Jumping from an old branch such as 8.1 to 8.3 is a bigger change, and that is where the backup really matters.

Patch on shared hosting: check, ask, switch

On shared hosting your host updates the PHP packages and you choose which version each site uses. Your job is to confirm what you run and that the fix has shipped.

Step 1: Find the PHP version your site actually runs

Each of these shows the version the web server uses, which can differ from the command-line version.

• WordPress: go to Tools > Site Health > Info > Server. The WordPress team points to this exact screen in its 21 October post about this release. Many hosts also show the version in the control panel.
• cPanel: open MultiPHP Manager. The list shows each non-parked domain with the PHP version it uses, and an Inherited label if it follows the server default.
• Plesk: go to Websites & Domains > PHP settings. Click View the phpinfo() page to see the full current settings, including server-level ones.

If none of those are available, you can use a tiny test file. This script prints the PHP version, the server API (the way PHP is connected to the web server) and the three settings that matter for the stop-gaps.

<?php
header('Content-Type: text/plain');
echo 'PHP version: ' . phpversion() . "\n";
echo 'Server API: ' . php_sapi_name() . "\n";
echo 'memory_limit: ' . ini_get('memory_limit') . "\n";
echo 'post_max_size: ' . ini_get('post_max_size') . "\n";
echo 'session.upload_progress.enabled: ' . var_export(ini_get('session.upload_progress.enabled'), true) . "\n";

Save it as version-check-7f3a.php in your site's web root, open https://example.com/version-check-7f3a.php, read the output, and then delete the file right away. You should see something like PHP version: 8.3.36 and a Server API value such as fpm-fcgi, apache2handler or litespeed.

Never leave this file online, because it tells strangers what you run.

Step 2: Check whether that version is fixed

Compare your version against the fixed releases from php.net:

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35
• PHP 8.1 and older: no longer updated by the PHP project

A lower number usually means unpatched, with one big exception.

Some Linux distributions keep the old base number and add the fix to it. Ubuntu does this. Its security notice USN-8948-1 (21 October 2026) fixes both CVEs in Ubuntu 24.04 with package version 8.3.6-0ubuntu0.24.04.13. The upstream part is still 8.3.6, so a patched server can look old. On those systems, check the package version, as shown in the server section below.

On cPanel servers, PHP comes from EasyApache 4 packages. cPanel's EasyApache 4 change log shows release 25.91, dated 21 October 2026, updating ea-php82 to 8.2.35, ea-php83 to 8.3.36, ea-php84 to 8.4.27 and ea-php85 to 8.5.12 for these two CVEs. Release 25.92, the same day, rebuilt ea-php74-meta, ea-php80-meta and ea-php81-meta so their change logs list the backport.

So if your cPanel host still shows 8.3.35, ask whether the update is scheduled.

Step 3: Ask your host the right question

Ask something they can confirm in one line: "Have you installed the 21 October 2026 PHP security updates for CVE-2026-109618 and CVE-2026-109619 on the server my account is on, and have PHP workers been restarted?"

Plesk users: at the time of writing (23 October 2026), the only official Plesk word I could find was an early staff reply on the Plesk forum, posted before the release, saying that "Once the vendor releases fixed versions, they will be included in Plesk PHP packages and delivered to Plesk servers," with no exact date given. Check your host or panel notice for the current status.

The WordPress team says "No WordPress update is required or planned for these issues." Only the PHP update fixes this.

Step 4: Move off PHP 8.1 or older

If your site runs PHP 8.1, 8.0, 7.4 or older, the PHP project no longer ships fixes for it. Some vendors backport (copy the fix into the old version), and cPanel's change log mentions this for its 7.4, 8.0 and 8.1 packages. Still, the safer move is to switch to a supported branch.

Before you switch, take the backup from the checklist. Then, in cPanel:

1. Open MultiPHP Manager.
2. Select the checkbox next to the domain you want to change.
3. Choose a version from the PHP Version menu. Versions your host recommends show a Recommended label.
4. Click Apply. If PHP-FPM is enabled, the FPM version updates to match.

In Plesk, go to Websites & Domains > PHP settings and select the desired PHP version from the menu.

Afterwards, load your home page, log in to the admin area and test one form. If anything breaks, see the troubleshooting section.

PHP 8.2 still gets fixes today, but php.net says it "reaches end of life on 31 December 2026 and will receive no further security fixes after that date." If you are on 8.2, see my guide on PHP 8.2 end of life and how to switch PHP version and plan the move now.

Patch your own server or VPS

If you have root access, the update is on you. Take a provider snapshot or an offsite backup first, then update packages, restart every PHP worker and verify.

Step 1 on cPanel and WHM: run the EasyApache 4 update

cPanel's EasyApache 4 documentation says you can update installed packages by selecting Run System Update in the EasyApache 4 interface, through a cron job, or manually with your package manager. In WHM, open the EasyApache 4 interface and run the system update.

When it finishes, the versions in MultiPHP Manager should show 8.2.35, 8.3.36, 8.4.27 or 8.5.12 for the matching branches.

Step 1 on Ubuntu: install the security update

Ubuntu's notice says "In general, a standard system update will make all the necessary changes." These two commands refresh the package list and then install available updates.

sudo apt update
sudo apt upgrade

Then check the installed PHP package version. Replace php8.3 with your branch, for example php8.1 or php8.5.

dpkg -l | grep php8.3

Compare the version column with the fixed versions from USN-8948-1:

• Ubuntu 26.10: 8.5.9-0ubuntu2.1
• Ubuntu 26.04 LTS: 8.5.4-0ubuntu1.5
• Ubuntu 24.04 LTS: 8.3.6-0ubuntu0.24.04.13
• Ubuntu 22.04 LTS: 8.1.2-1ubuntu2.28

The fixed binary packages listed for each release include the -fpm, -cli, -cgi and libapache2-mod-php packages, so every package from that list that you have installed should show the fixed version or later.

If you use a third-party PHP repository or a control panel's own PHP builds, check that vendor's notice instead.

Step 2: Restart every PHP worker

This step is easy to forget. Updated files on disk do nothing until running PHP processes are replaced. php.net's stop-gap advice also says to "restart every worker" after config changes, for the same reason.

On Ubuntu with Apache, this command restarts Apache, which reloads mod_php.

sudo systemctl restart apache2.service

If you run PHP-FPM, restart its service too; the service name varies, so check your host or panel notice. If you are not sure which services run PHP, a planned reboot in a quiet window restarts everything in one go.

Stop-gaps if you cannot patch today

If your host has not shipped the update, php.net lists settings that "reduce exposure to specific attack paths but do not make an installation safe." Treat them as a seatbelt, not a fix.

Made-up example: Priya runs three client sites on a VPS, and her vendor's patched package is not out yet. She applies the settings below, restarts PHP-FPM, confirms them with the test file, and installs the real update when it lands.

One important rule first. php.net says these settings must be applied where apps cannot override them: in php.ini, an FPM pool or server configuration. It says not to rely on ini_set() or FPM .user.ini for the upload progress setting. On shared hosting, that means these belong to your host, not to you.

What each setting does

• memory_limit=-1: removes PHP's own memory limit. php.net lists it among its stop-gaps for CVE-2026-109618, which involves out-of-memory handling, and notes a real allocation failure can still reach the bug.
• post_max_size: caps the size of a form submission. php.net suggests 8M for apps that do not need file uploads and 32M if they do, with upload_max_filesize kept below post_max_size.
• session.upload_progress.enabled=0: turns off upload progress tracking, which blocks the confirmed session paths for CVE-2026-109619.
• fatal_error_backtraces=0: PHP 8.5 only. Blocks the confirmed fatal backtrace path.

Why this matters: with no memory limit, one runaway script can eat the whole server. php.net recommends a container or cgroup limit (an operating system cap on a group of processes) as a safety boundary. It also warns: do not use RLIMIT_AS or RLIMIT_DATA instead, because those can cause the vulnerable allocation failure.

Option A: in the main PHP config file

These lines set all four values in the main php.ini file. Leave out the last line if you are not on PHP 8.5, and use 32M and a lower upload_max_filesize such as 30M if your site takes uploads.

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0

Option B: in a PHP-FPM pool

The PHP manual says settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set(), which is exactly what you want here. Add these lines to the pool configuration file for each site, then restart PHP-FPM.

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[fatal_error_backtraces] = off

Check that no other pool, directory or application setting puts a finite memory_limit back.

Option C: Apache with the PHP module

Since mod_php carries the highest risk, do this one carefully. These directives go in the Apache configuration (for example inside the site's VirtualHost block), not in .htaccess. The PHP manual says php_admin_value cannot be used in .htaccess and cannot be overridden by .htaccess or ini_set().

php_admin_value memory_limit -1
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
php_admin_flag session.upload_progress.enabled off

Restart Apache afterwards.

php.net also lists two developer tasks: remove invalid or deprecated per-request settings that print warnings early, and fix fatal errors and timeouts an attacker can trigger. Hiding warnings with error_reporting, display_errors or @ does not help.

The 23 October follow-up advisory

On 23 October 2026, php.net added an informational advisory about a third, unlikely bug, CVE-2026-115560. It only applies if an app sets session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime with ini_set() before calling session_start(), with upload progress still enabled.

php.net suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. If you already applied it for CVE-2026-109619, keep it in place and you are covered. At the time of writing (23 October 2026), the full advisory is promised with the next release, so check php.net again before you remove the setting.

How to check it worked

Run these checks after patching or after applying stop-gaps:

1. Load your test file again. PHP version should show a fixed release, or your distribution's fixed package should show in dpkg -l.
2. If you applied stop-gaps, the same file should show memory_limit: -1, post_max_size: 8M (or 32M) and session.upload_progress.enabled: '0' or ''. Both of those last two values mean off.
3. On cPanel, MultiPHP Manager should list the patched version next to every domain, including any set to inherit.
4. On WordPress, Tools > Site Health > Info > Server should show the patched version.
5. Run through the site as a visitor: home page, a contact form, login, checkout if you sell online.
6. Delete the test file and confirm https://example.com/version-check-7f3a.php now returns a 404.

You can check that last one from a terminal. This command fetches only the response headers, and you should see a 404 status on the first line.

curl -I https://example.com/version-check-7f3a.php

Troubleshooting

The browser and SSH show different PHP versions

Symptom: the browser says 8.3.36 but SSH says 8.1.x, or the other way round. Cause: the command line and the web server can use different PHP builds and different php.ini files. Fix: trust the browser result for website safety, but update both, since cron jobs may use the command-line PHP.

The version still looks old after updating on Ubuntu

Symptom: the version reads 8.3.6 even after sudo apt upgrade. Cause: Ubuntu backports fixes and keeps the base number. Fix: check dpkg -l | grep php8.3 against the fixed package versions listed above. If those match, you are patched.

cPanel shows "Inherited" and you cannot tell what version that is

Symptom: a domain shows the Inherited label. Cause: the domain follows the system default, which only the server administrator can set. Fix: ask your host what the default is, or pick a specific patched version in MultiPHP Manager.

The version you need is missing from the PHP Version menu

Symptom: 8.4 or 8.5 is not in the list. Cause: according to cPanel's docs, the version is either not installed on the server or not available to your account. Fix: ask your host to install it through WHM's EasyApache 4 interface.

Large uploads fail after the stop-gap

Symptom: media uploads or imports stop working. Cause: the lower post_max_size. Fix: use php.net's upload value of 32M, keep upload_max_filesize below it, and remove the stop-gap once you are patched.

Your memory limit change seems ignored

Symptom: the test file still shows something like 256M. Cause: a pool, directory or application setting puts a finite limit back, or PHP was not restarted. Fix: search your pool files and Apache config for memory_limit, then restart every PHP worker.

The site breaks after switching branches

Symptom: a white screen or a fatal error after moving from 8.1 to 8.3. Cause: an old plugin, theme or custom code that does not support the newer branch. Fix: switch back in MultiPHP Manager or PHP settings, restore from backup if needed, and get a developer to update the code before trying again.

When to ask the host or a developer

Ask your host if you are on shared hosting, if your panel does not offer a patched version, or if you are not sure whether workers were restarted. Ask a developer if your error log is full of deprecation warnings or if your app needs an older PHP branch to run.

Security note: patching closes the hole but does not undo earlier damage. If your server was exposed, look for files you did not create and admin accounts you do not recognise. For keeping the rest of the stack current, see safe WordPress auto-updates with a backup plan.

The one message worth forwarding

Copy this to your host, developer or IT person:

Hi, PHP released security fixes on 21 Oct 2026 for CVE-2026-109618 and CVE-2026-109619 (unauthenticated remote code execution, CVSS v4.0 9.2). Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35, or the vendor's patched package. Can you confirm (1) which PHP version and package each of our sites runs, (2) that the fixed packages are installed, and (3) that all PHP workers and the web server were restarted? If patching must wait, please apply php.net's stop-gaps at php.ini or pool level, including session.upload_progress.enabled=0, which also covers the 23 Oct advisory for CVE-2026-115560. Advisory: https://www.php.net/archive/2026.php

The takeaway: find your real PHP version, get it to a fixed release, restart every worker, and use the stop-gaps only to buy time.