PHP2Shell (CVE-2026-109618): How to Check and Patch Your Server

PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0 and fixed on 21 October 2026. They can let an attacker run code on a server without logging in, and they affect any PHP setup that serves web requests (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed). The fix is to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and then restart every PHP worker. Settings changes can reduce the risk, but the PHP project is clear that only the update is a complete solution.

This guide is written for whoever has to actually do the patching: the developer, the "IT ka diba?" person at a small company, or the student who manages the org website. It goes through checking, patching on the common setups, confirming it worked, and what to do if you can't patch today.

What is PHP2Shell?

PHP2Shell is a pair of memory bugs in the PHP runtime, the part that runs before your WordPress, Laravel or custom code even starts. Because the bug is in PHP and not in a plugin, every site on a vulnerable PHP version is exposed, however well its own code is written.

According to the official PHP advisory:

• CVE-2026-109618 (RCE via OOM corruption): when PHP runs out of memory at the wrong moment, request data can be left half set up, and cleanup then treats that broken data as valid.
• CVE-2026-109619 (RCE via stale global state): some internal state from one request can survive after its memory is freed, and a later request handled by the same worker can use it.

PHP says the risk is highest for Apache with mod_php, where it has a demonstrated exploit in which one unauthenticated request triggers the attack before any application code runs. Amazon Threat Intelligence reported that its honeypots recorded an exploitation attempt on 17 October 2026, four days before public disclosure, and Cloudflare has published WAF rules for known exploit patterns. Read the official advisory on php.net for the source.

Is my server affected?

If your server runs PHP below the fixed version for its branch and serves web traffic, assume yes. The fixed versions are:

• PHP 8.5: 8.5.12 or later
• PHP 8.4: 8.4.27 or later
• PHP 8.3: 8.3.36 or later
• PHP 8.2: 8.2.35 or later
• PHP 8.1 and older: no official fix release. These are end of life. Upgrade, or get a backport from your Linux vendor or LTS provider.

Here's the catch beginners miss: the PHP your terminal runs is not always the PHP your website runs. Check the one that serves pages.

Check the command-line version:

php -v

Check the PHP-FPM version (change 8.3 to your branch):

php-fpm8.3 -v

On WordPress, go to Tools, Site Health, Info, Server and read the PHP version there. On cPanel, open MultiPHP Manager and look at the version set for each domain. On Docker, check the FROM line of your Dockerfile, like FROM php:8.3-apache.

If you're on shared hosting with no SSH, your host patches PHP for you, but you still choose which branch each site uses. Make sure none of your sites is set to 8.1 or older.

How do you patch PHP2Shell?

Pick the setup that matches yours. Back up first if you can, and do it in a quiet hour, because restarting PHP drops requests for a moment.

Ubuntu or Debian

Step 1: update the package list and upgrade PHP packages.

sudo apt update
sudo apt upgrade

Step 2: confirm the package actually contains the fix. Distros often backport security fixes without changing the version number to the upstream one, so look for the CVE in the changelog (change the package name to yours):

apt changelog php8.3-fpm | grep -i 'CVE-2026-10961'

Step 3: if nothing shows up yet, check your distro's security tracker (ubuntu.com/security or security-tracker.debian.org) for CVE-2026-109618 and CVE-2026-109619 to see if a fixed package has been published.

RHEL, AlmaLinux or Rocky Linux

Step 1: upgrade the PHP packages.

sudo dnf upgrade 'php*'

Step 2: check the changelog for the CVE.

rpm -q --changelog php-fpm | grep -i 'CVE-2026-10961'

If you install PHP from a third-party repo such as Remi, check that repo's announcements before trusting it. Help Net Security reported that the Remi repo would not have updates on release day.

Docker

The official php images on Docker Hub have the fixed tags (8.5.12, 8.4.27, 8.3.36 and 8.2.35). Pin the exact version in your Dockerfile so you know what you're running:

FROM php:8.3.36-apache

Then rebuild and pull the fresh base image:

docker compose build --pull
docker compose up -d

cPanel, Plesk or shared hosting

Hosting panels update PHP through their own system (EasyApache on cPanel, the PHP updates screen on Plesk). If you manage the server, run the panel's updates. If you're on shared hosting, message support and ask: "Have you applied the PHP 21 October 2026 security release for CVE-2026-109618 and CVE-2026-109619 on my server?" A good host will answer with the versions.

How do you confirm the patch worked?

Updating the files isn't enough. CVE-2026-109619 lives in state kept by running workers, so old workers can keep running the old code until they're restarted.

1. Restart PHP-FPM and your web server (commands below, use the names on your system).
2. Check the version again with php-fpm8.3 -v, and on WordPress, recheck Site Health.
3. For Docker, run docker compose exec <service> php -v to see the version inside the container.
4. Write down what you patched, when, and the version before and after. If your boss or client asks, you have a clear answer, and that habit is exactly what IT teams look for.

The restart commands for a typical Ubuntu server with PHP 8.3 and Apache:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

What if you can't patch today?

Sometimes you can't: a legacy app breaks on newer PHP, or a client has to approve downtime. The PHP project lists settings that reduce exposure to specific attack paths while you schedule the update. Put them in php.ini, an FPM pool or the server config, not in ini_set() or a .user.ini, and restart every worker after:

• session.upload_progress.enabled=0
• A low post_max_size: 8M if the site doesn't take uploads, 32M if it does, with upload_max_filesize below it
• memory_limit=-1, set where applications can't override it (such as php_admin_value in the FPM pool)
• On PHP 8.5, fatal_error_backtraces=0
• Request limits at the web server or proxy (request size, number of fields, headers, multipart parts)

Read the full list on the advisory before changing production. If your site is behind Cloudflare, its WAF rules for this are available on every plan. The UK's NCSC has advised considering taking systems offline if they can't be fixed right away. For a site that handles payments or personal data, that's worth a real conversation with whoever owns it.

Should you check if you were already hacked?

If your server was exposed, yes, especially since exploit attempts were seen before the patch came out. Patching closes the door, but it doesn't remove anyone who already got in. After patching, do a quick check for planted files, odd admin users and unexpected changes. Our guide to spotting and removing a PHP web shell has the exact commands and a first-hour checklist.

Why this matters if you're aiming for an IT job

Patching a critical CVE calmly is real IT work. In IT support, sysadmin and SOC roles, someone has to read the advisory, find which servers are affected, schedule the update, confirm it, and write it up. Interviewers like asking "walk me through how you'd handle a critical vulnerability announcement," and the steps above make a strong answer.

The usual way in is through IT support or helpdesk first, then security if you like it (here's how that path works). The Career Shifter Track is built around that first job: choosing the role, a resume a coach marks up line by line, a portfolio project, and two mock interviews where you practice answers like this before a real panel. You can try the free preview lessons first, or start with the free IT Job Starter Kit.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical memory bugs in the PHP runtime fixed on 21 October 2026. They can allow remote code execution without logging in on PHP setups that serve web requests.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older don't get an official fix release, so upgrade to a supported branch or get a backport from your Linux distribution or LTS vendor.

Is my WordPress site affected by PHP2Shell?

If it runs on a PHP version below the fixed one for its branch, yes, because the bug is in PHP, not in WordPress or a plugin. Check the PHP version under Tools, Site Health, Info, Server, then update PHP or ask your host.

Do I need to restart after updating PHP?

Yes. Restart PHP-FPM and your web server after updating so no worker keeps running the old code. One of the two bugs involves state kept by running workers, so a restart is part of the fix.

Can I fix PHP2Shell by changing php.ini?

Not fully. The PHP project lists settings that reduce exposure to specific attack paths, but says only updating PHP is a complete solution. Use the settings as a stopgap while you schedule the update.