Guide PHP2Shell (CVE-2026-109618 & CVE-2026-109619): What It Is and How to Fix It

**JAY** · (This post was last modified: 10-22-2026, 03:43 PM by JAY.)

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what it is and how to fix it

On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities, nicknamed PHP2Shell. Together they can let an attacker run code on a server running PHP, without logging in. Attacks were seen before the patches came out, so if you run any PHP website, update today.

This article explains the problem in plain language, which versions are fixed, and how to check and patch your server. We also have step-by-step guides for each hosting control panel (links at the bottom).

The short version

What: two memory bugs in PHP itself (not in WordPress or your app) that can lead to remote code execution and memory leaks.
Who: almost every PHP version that serves websites: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed (lsphp) and FrankenPHP.
Severity: CVSS v4.0 score 9.2 (critical) for both.
Being exploited? Yes. Amazon saw attempts from 17 October, and Cloudflare and others report ongoing attacks.
Fix: update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor's patched package), then restart PHP.

What are the two vulnerabilities?
CVE-2026-109618 (out-of-memory corruption). If PHP runs out of memory at the wrong moment while setting up a request, it can leave internal data half-built. The clean-up code then treats that broken data as valid, which an attacker can abuse.

CVE-2026-109619 (stale global state). PHP can keep a pointer to request data after that memory is freed. A later request handled by the same PHP worker can then use the freed memory (a "use-after-free"). Researchers showed this can lead to code execution, and also to leaking the worker's memory, which may contain passwords, session tokens and API keys.

Both bugs are in the PHP engine, so it doesn't matter which app you run. The PHP security team rated both 9.2 (critical). Apache with mod_php needs the most urgent attention, because an attack there can trigger before any of your application code even runs.

Fixed versions

PHP 8.5: 8.5.12
PHP 8.4: 8.4.27
PHP 8.3: 8.3.36
PHP 8.2: 8.2.35
PHP 7.4, 8.0, 8.1: no official release. Get a patched package from your Linux distribution or vendor, or upgrade to a supported PHP version.
PHP 7.3 and older: end of life, no fix. Upgrade.

Important: Ubuntu, Debian and Red Hat often patch PHP without changing the version number (for example Ubuntu 22.04's

Code:

8.1.2-1ubuntu2.28

). On those systems, check the full package version or changelog, not just

Code:

php -v

.

Step 1: Find every PHP on your server
Many servers have more than one PHP. A control panel may have one PHP per version, plus the system PHP, plus a separate PHP for LiteSpeed. Each one needs patching. It's easy to patch the panel's PHP and miss a second one, such as LiteSpeed's own PHP (lsphp).

Useful checks:

Code:

php -v
ls /www/server/php/ 2>/dev/null        # aaPanel
ls -d /usr/local/lsws/lsphp* 2>/dev/null  # LiteSpeed / OpenLiteSpeed / CyberPanel
ls /etc/php/ 2>/dev/null                 # Debian/Ubuntu packages
ls -d /opt/cpanel/ea-php* /opt/plesk/php/* 2>/dev/null
ps aux | grep -E "php-fpm|lsphp|httpd" | grep -v grep | head

Step 2: Update PHP
Use your control panel or package manager. The exact steps differ per panel, so follow the guide for yours (links below). In general:

Code:

# Debian / Ubuntu
apt update && apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php8.3*'

# AlmaLinux / Rocky / RHEL
dnf upgrade 'php*'

Step 3: Restart PHP
The update only protects you once the running PHP processes restart. This step is often forgotten.

Code:

systemctl restart php8.3-fpm     # Debian/Ubuntu, one per version
systemctl restart php-fpm        # RHEL family
systemctl restart apache2        # Apache with mod_php
pkill lsphp                      # LiteSpeed starts new workers automatically

Step 4: Check that it worked
Check the version the web server uses, not just the command line. Create a file in your website folder:

Code:

<?php echo PHP_VERSION;

Open it in your browser, check the number, then delete the file straight away.

This command lists processes still running old, replaced PHP files. Empty output means everything restarted:

Code:

grep -lE ' /(usr|lib|opt|www).*$deleted$$' /proc/[0-9]*/maps 2>/dev/null

On Debian/Ubuntu,

Code:

needrestart -b -r l

does the same check.

Can't update yet? Temporary protection
These settings reduce the risk until you can update. They are not a full fix. Set them in the server's

Code:

php.ini

or PHP-FPM pool (not with

Code:

ini_set()

or

Code:

.user.ini

, which come too late), then restart PHP:

Code:

; blocks the CVE-2026-109619 path
session.upload_progress.enabled = 0
; PHP 8.5 only
fatal_error_backtraces = 0

For CVE-2026-109618 the PHP team suggests

Code:

memory_limit = -1

set by the administrator. Be careful: this removes PHP's memory cap, so one heavy request can use a lot of RAM. Combine it with a container or cgroup memory limit, and update as soon as you can. If your site runs behind Cloudflare, its WAF has rules for known attack patterns, including on the free plan, but only for traffic that goes through Cloudflare.

Were you already attacked?
Attacks started on 17 October, before the fix existed. After patching, spend ten minutes checking:

New or changed PHP files in your websites since 17 October:

Code:
find /var/www /www/wwwroot /home -name "*.php" -newermt 2026-10-17 -type f 2>/dev/null | head -50
Look for files you didn't create, especially in upload folders.
Cron jobs you don't recognise:
Code:
crontab -l
for root and each site user.
Unknown processes or high CPU (crypto miners are common):
Code:
top
,
Code:
ps aux --sort=-%cpu | head
.
Outgoing connections to strange IPs:
Code:
ss -tnp
.

Because the bug can leak memory, consider changing secrets stored in PHP apps (database passwords, API keys, app keys) if anything looks wrong.

Step-by-step guides for each control panel

Frequently asked questions
Is WordPress affected?
Yes. Any app running on a vulnerable PHP is exposed, because the bug is in PHP itself. Updating WordPress does not fix it; updating PHP does.

Does Nginx with PHP-FPM protect me?
No. PHP-FPM is affected too. mod_php is the highest risk, but every web-facing PHP should be updated.

I updated, but php -v still shows the old number.
Your distribution may back-port the fix without changing the version (check the package changelog), or

Code:

php -v

is showing a different PHP from the one your websites use. Check through the browser as in Step 4.

Should I trust exploit code from GitHub?
No. Unverified "proof of concept" code for these bugs is circulating and may contain malware. Don't run it on your servers.

Questions about your setup? Ask in Server security and hardening or in the security support forum for your panel. Include your panel, OS and the output of

Code:

php -v

.

Sources (checked 22 October 2026): Tenable FAQ · Qualys: find, mitigate and patch PHP2Shell · Help Net Security · BleepingComputer

Possibly Related Threads…matched by title
Guide Linux VPS Security Hardening Checklist for 2026 DEV	Replies:0Views:221	10-07-2026, 05:53 PMDEV