On 21 October 2026 the PHP project shipped emergency security releases for two critical flaws that security researchers have nicknamed PHP2Shell. Tracked as CVE-2026-109618 and CVE-2026-109619, they let an attacker who knows nothing about your site send crafted web requests that can end in remote code execution on the server. No login, no plugin bug and no user click is needed. If a server runs PHP and answers web requests, it is in scope.

That covers WordPress, WooCommerce, Laravel, CodeIgniter, Magento, Drupal, custom PHP apps and almost every shared hosting account in the world. In this guide we explain what happened in plain language, which PHP version you need, and exactly how to patch on cPanel/WHM, aaPanel, FastPanel, Plesk and plain SSH, plus how to use Cloudflare as a temporary shield and how to do all of it without taking your site down.

PHP2Shell in 60 Seconds

What: Two memory-safety bugs inside the PHP interpreter itself, not in WordPress or any plugin.
Severity: Critical, CVSS v4.0 score 9.2 for both.
Who is affected: Every PHP setup that serves web traffic, including PHP-FPM, Apache mod_php, php-cgi, LiteSpeed (lsphp) and FrankenPHP. Wiz Research reports that every PHP version back to 5.4 is affected by at least one of the bugs.
Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026.
No official fix: PHP 8.1, 8.0, 7.4 and older. You need a vendor backport (CloudLinux, Ubuntu Pro, Freexian and others) or an upgrade.
Is it being attacked? watchTowr says it has seen exploitation in the wild through its honeypots, Cloudflare and hosting partners reported early attack attempts, while Rapid7 reported attempts but no confirmed breaches yet. Treat it as actively targeted.
The only real fix: Install the patched PHP build and restart every PHP worker. Updating WordPress, themes or plugins does not fix this.

What Happened: The PHP2Shell Timeline

The bugs were found by researchers at Calif and reported privately to the PHP security team, with public disclosure planned for 22 October. On 20 October 2026 details leaked on social media. The PHP team responded by moving the release forward and announcing an emergency release for the next day, and watchTowr publicly confirmed the bugs were real.

Cloudflare says it had been building protections since early October and switched on WAF rules at 03:02 UTC on 21 October, hours before the fix went public. The PHP project then published its advisory and the four patched releases on 21 October. Linux distributions and long-term support vendors had received the patches in advance, but package availability was uneven on day one. The popular Remi repository for RHEL-family servers, for example, did not have builds on release day, and cPanel and CloudLinux packages were still being built when the first patch guides went out.

By 22 October several proof-of-concept exploits were public. Rapid7 noted that each one only worked against a specific mix of operating system, PHP version and web server, but warned that a more portable exploit could appear at any time. As of 22 October, CISA had not yet added either CVE to its Known Exploited Vulnerabilities catalog.

How the Two Vulnerabilities Work (Plain English)

You do not need to understand memory corruption to fix this, but knowing the basics helps you judge the risk.

CVE-2026-109618: Out-of-Memory Corruption

When PHP starts handling a request, it builds internal data structures for things like form fields and uploaded files. If PHP runs out of memory part way through, it can abandon the request and leave that data half built. The cleanup code later trusts the half-built data, and an attacker can shape that into memory corruption. A specially crafted multipart request (the kind used for file uploads) can trigger it even when the request stays inside your configured size limits.

On Apache mod_php, the cleanup runs even when request startup fails, so the attack can succeed before your application code runs at all. That is why the PHP team rates mod_php as the highest-risk setup.

CVE-2026-109619: Use-After-Free Across Requests

PHP workers handle many requests one after another. This bug leaves a piece of internal state pointing at memory that was already freed at the end of an earlier request. The next request on the same worker can then use that stale data. Fatal errors and timeouts can interrupt cleanup and make this easier. The advisory confirms working code execution against mod_php through the fatal error backtrace feature in PHP 8.5, and through the session upload progress path on both mod_php and PHP-FPM.

Which PHP Version Should You Use?

Pick the newest patch release of a supported branch your application works with:

PHP 8.4.27 (recommended for most sites): Mature, fast and supported with security fixes until the end of 2028. WordPress, Laravel 11 and 12 and most modern frameworks run well on it.
PHP 8.3.36: Safe choice if your code or plugins are not yet tested on 8.4. Security support runs to the end of 2027.
PHP 8.5.12: The newest branch. Use it if your stack already supports it. Remember to also check the fatal_error_backtraces setting mentioned below.
PHP 8.2.35: Patched, but 8.2 security support ends on 31 December 2026. Patch now and plan your move to 8.3 or 8.4.
PHP 8.1 and older: No official fix. If your panel or OS vendor offers a backported build (for example CloudLinux alt-php or Ubuntu Pro), install it today. Otherwise upgrading to 8.3 or 8.4 is the safe path.

A quick way to check what you run:

php -v
# Check what the web server actually uses, not just the CLI:
echo '<?php echo PHP_VERSION;' > /var/www/html/v.php && curl -s https://yourdomain.com/v.php; rm /var/www/html/v.php

The CLI php and the PHP that serves your site are often different builds, especially on panels with multiple PHP versions. Always check every installed PHP version, not only the default one.

Before You Patch: The No-Downtime Checklist

Patching PHP is normally a minor update inside the same branch (for example 8.3.30 to 8.3.36), so code compatibility problems are rare. Most downtime comes from rushed restarts and broken configs. Do this first:

Take a backup or snapshot. A VPS snapshot from your cloud provider is fastest. On cPanel, a full account backup works too.
List every PHP version installed, including old ones assigned to forgotten subdomains or staging sites.
Pick a low-traffic window, but do not wait days. This is an emergency patch.
Prefer a graceful reload for PHP-FPM. systemctl reload on PHP-FPM gracefully replaces workers, so in-flight requests finish while new workers load the patched binary.
Mod_php needs a full Apache restart, not a graceful one, because the PHP code lives inside the Apache processes. That restart usually takes one or two seconds.
Test configs before any restart with nginx -t, apachectl configtest or php-fpm8.3 -t so a typo never takes the site down.
Do not forget long-running PHP processes such as Laravel queue workers, Supervisor jobs and cron daemons. They keep the old code in memory until restarted.

How to Patch PHP on cPanel / WHM (EasyApache 4)

cPanel servers use ea-php packages (ea-php82, ea-php83, ea-php84, ea-php85). The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 respectively.

From the WHM Panel

Log in to WHM as root.
Go to Server Configuration > Update Preferences and make sure automatic updates are enabled, so nightly upcp keeps EasyApache packages patched.
Go to Software > EasyApache 4. If updated PHP packages are available, WHM shows them. Review and provision the update.
Go to Software > MultiPHP Manager to see which domains use which PHP version. MultiPHP Manager only assigns versions; it does not update packages, so every installed ea-php version must be updated.
Under Restart Services, restart PHP-FPM and HTTP Server (Apache).

From SSH on a cPanel Server

# Refresh package metadata and update all EasyApache PHP and Apache packages
sudo dnf clean all          # use "yum" on CentOS 7 / CloudLinux 7
sudo dnf update 'ea-php*' 'ea-apache24*'

# Restart services the cPanel way
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd

# Verify every installed PHP version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p: $($p -v | head -1)"; done

If the update command says there is nothing to install, the rebuilt packages may not have reached the mirrors yet. Check the EasyApache 4 changelog in WHM, apply the temporary mitigations below, and run the update again later.

CloudLinux and PHP Selector (alt-php)

If your server runs CloudLinux, customers who pick a version in PHP Selector use alt-php builds, which are separate from ea-php. CloudLinux historically backports fixes to end-of-life versions as well. Update both sets:

sudo dnf update 'alt-php*'
/opt/alt/php83/usr/bin/php -v

LiteSpeed Servers

If you use LiteSpeed or OpenLiteSpeed with lsphp, update the lsphpXY packages for your OS and then stop the old PHP processes so they respawn on the new binary:

sudo pkill lsphp

How to Patch PHP on aaPanel

aaPanel installs PHP into /www/server/php/ with one folder per version (for example /www/server/php/83) and usually compiles each version itself.

From the aaPanel Dashboard

Log in to aaPanel and open App Store, then filter by Installed.
Find each installed PHP-8.x entry. When aaPanel publishes a newer minor version, an update option appears for that entry. Click it and let the compile finish. This can take several minutes on small VPS plans.
Open the PHP settings of that version and click Restart (or Reload) so new workers start.
Repeat for every installed PHP version, including old ones like 7.4 that might still be used by a forgotten site.
Under Website, check which PHP version each site uses and move sites off unsupported versions.

If aaPanel has not published the patched minor version yet, apply the temporary mitigations in this guide and put the site behind Cloudflare until it does.

From SSH on an aaPanel Server

# See installed versions
ls /www/server/php

# Check each version
for v in /www/server/php/*/bin/php; do echo "$v: $($v -v | head -1)"; done

# Graceful reload of a PHP-FPM version after updating (example: 8.3)
/etc/init.d/php-fpm-83 reload

How to Patch PHP on FastPanel

FastPanel installs PHP versions as applications, with binaries under /opt/phpXY/ (for example /opt/php74/bin/php).

From the FastPanel Dashboard

Go to Settings > Applications and review installed PHP versions. Install the updated version when FastPanel makes it available.
For each site, open the site card, go to Settings > PHP settings, and confirm the PHP version and mode (FastCGI, PHP-FPM or CGI).
Move any site still on PHP 7.x or 8.0/8.1 to 8.3 or 8.4 after testing.

From SSH on a FastPanel Server

FastPanel runs on Debian and Ubuntu, so its PHP packages update through apt:

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgrade        # or install only the PHP packages listed above

# Verify each version
for v in /opt/php*/bin/php; do echo "$v: $($v -v | head -1)"; done

Then restart PHP from the panel or with systemctl (run systemctl list-units | grep -i php to find the exact service names).

How to Patch PHP on Plesk

Plesk has its own PHP builds (plesk-php83 and similar) alongside any OS-provided PHP.

Panel: go to Tools & Settings > Updates > Add/Remove Components and update the PHP versions.
SSH:

plesk bin php_handler --list
plesk installer --select-release-current --upgrade-installed-components
systemctl restart plesk-php83-fpm
plesk bin php_handler --reread

How to Patch PHP Manually Over SSH (No Panel)

Ubuntu and Debian

Ubuntu 24.04 shipped a fixed php8.3 package on release day, and Debian 13 shipped a fixed php8.4. Many servers use the Ondřej Surý repository (ppa:ondrej/php or packages.sury.org) for newer versions, which published builds dated 20261021.

sudo apt update
apt list --upgradable 2>/dev/null | grep php

# Upgrade only PHP packages for your version (example: 8.3)
sudo apt install --only-upgrade 'php8.3*'

# Test, then reload gracefully (PHP-FPM + Nginx)
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

# Apache with mod_php needs a full restart
sudo apachectl configtest && sudo systemctl restart apache2

# Confirm the fix is in the changelog
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

On Ubuntu 20.04 and 18.04 the fix is only available through Ubuntu Pro (sudo pro fix CVE-2026-109618). Debian 11 has no free fix, so upgrading the OS or PHP branch is the realistic option.

AlmaLinux, Rocky Linux and RHEL

dnf module list --enabled php
sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'
sudo systemctl reload php-fpm

If nothing updates, the vendor errata may still be pending. Keep checking with dnf check-update 'php*'. On RHEL 8, the default PHP 7.2 stream is retired and receives no fixes, so move to a supported stream after testing.

Docker

Running containers do not update themselves. Pull and recreate:

docker compose pull
docker compose up -d --force-recreate
docker exec <container> php -v

Pin full patch tags such as php:8.3.36-fpm-alpine in production so you always know what you run.

Make Sure No Old PHP Is Still Running

After a restart, check that no process still uses deleted (old) libraries:

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
# Debian/Ubuntu shortcut:
sudo needrestart -b -r l

Temporary Mitigations If You Cannot Patch Today

These reduce exposure while you wait for packages. The PHP team is clear that no configuration change fully fixes PHP2Shell, so treat these as a bridge, not a solution. Set them at the server level (php.ini, PHP-FPM pool config or Apache config). Settings in .user.ini or ini_set() apply too late to help.

; Blocks the session upload progress exploitation path
session.upload_progress.enabled = 0

; PHP 8.5 only: blocks the fatal error backtrace path
fatal_error_backtraces = 0

; Keep request bodies small if you don't need big uploads
post_max_size = 8M
upload_max_filesize = 6M

Then restart every PHP worker. Advanced users can also follow Rapid7's advice to set memory_limit = -1 at the pool level so out-of-memory failures cannot trigger CVE-2026-109618, but only with care, because removing the memory limit lets a single bad script use all server RAM. Do not rely on container memory limits or RLIMIT_AS, and do not assume you are safe because your error logs are quiet.

If a site is high-value and you cannot patch quickly, Patchstack recommends putting it into maintenance mode until you can.

Use Cloudflare as a Temporary Shield

Cloudflare deployed WAF rules against known PHP2Shell exploit patterns for all plans, including Free. On 22 October they were renamed "PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619)". Cloudflare also uses a new response-inspection rule that looks at what your server sends back.

To get the benefit:

Proxy your site through Cloudflare (orange cloud enabled on your DNS records).
Pro, Business and Enterprise: go to Security > WAF > Managed rules and confirm the Cloudflare Managed Ruleset is deployed and set to Block. Free plans get the Free Managed Ruleset automatically.
Lock your origin to Cloudflare. If attackers can reach your server by its IP address, they skip Cloudflare entirely. Allow ports 80 and 443 only from Cloudflare's published IP ranges, for example with UFW:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo ufw allow from $ip to any port 80,443 proto tcp; done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do sudo ufw allow from $ip to any port 80,443 proto tcp; done
# Only after confirming the rules above, remove any broad "allow 80/443" rules:
sudo ufw status numbered

Optional: add a custom WAF rule that blocks or challenges multipart/form-data POST requests to URLs that never need uploads.

Cloudflare itself says these rules are a second layer and that attackers are mutating payloads to get around them. Patch PHP anyway.

How to Tell If You Were Targeted

Patchstack lists these warning signs. None proves a breach, but all mean "update and investigate":

Unusual multipart requests followed by memory-limit errors or bursts of HTTP 500 responses
Abnormally large or malformed PHPSESSID cookies
PHP workers restarting with no clear reason

Quick checks over SSH:

# Recently changed PHP files in web roots (last 3 days)
find /home/*/public_html /var/www -name "*.php" -mtime -3 -ls 2>/dev/null | head -50

# Spikes of 500 errors in access logs
grep '" 500 ' /var/log/nginx/access.log | tail -50

If you find anything suspicious, treat the server as compromised. Because these bugs can expose memory, rotate secrets the server holds: database passwords, API keys, SMTP credentials and WordPress salts. Avoid unofficial "fix" plugins and copy-paste snippets from unknown sources.

After Patching: Lock It In

Confirm the version from the browser side, not just the CLI.
Turn on automatic security updates (unattended-upgrades on Ubuntu, dnf-automatic on RHEL, auto updates in WHM).
Remove PHP versions nobody uses. Every installed version is another thing to patch.
Retire mod_php where possible and move to PHP-FPM, which is faster and was the lower-risk setup here.
Subscribe to security announcements from php.net and your panel vendor.

Conclusion

PHP2Shell is one of the most serious PHP security events in years because it sits in the language itself, below every CMS and framework. The fix is simple: install PHP 8.4.27, 8.3.36, 8.5.12 or 8.2.35 (or your vendor's patched build), then restart every PHP worker. Use a graceful PHP-FPM reload and a tested config to avoid downtime, use Cloudflare's WAF and the php.ini mitigations only as a bridge, and plan to move off PHP 8.1 and older for good.

If you manage several servers or panels and want help patching safely, the Papaya Coders team can audit your PHP versions, apply the updates and harden your hosting so the next emergency is a five-minute job.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. They can let an unauthenticated attacker run code on a server that uses PHP to serve web requests.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fixes. PHP 8.1 and older have no official release, so you need a vendor backport or an upgrade.

Does updating WordPress or plugins fix PHP2Shell?

No. The bugs are in the PHP interpreter, so you must update PHP on the server. Updating WordPress, themes or plugins does not help.

Is my shared hosting account affected?

If your host runs a PHP version older than the fixed releases, yes. Most good hosts patch quickly, but check the PHP version in your control panel and ask your host if it has applied the PHP2Shell fix.

Will updating PHP take my website down?

Usually not. A patch inside the same branch, such as 8.3.x to 8.3.36, rarely breaks code. Use a graceful PHP-FPM reload, test configs first and take a snapshot so you can roll back in minutes if needed.

Does Cloudflare protect against PHP2Shell?

Cloudflare's WAF blocks known exploit patterns on all plans, including Free, but only for traffic that passes through Cloudflare. It is a temporary shield, not a fix. You still need to patch PHP.

Is there a php.ini setting that fixes PHP2Shell?

No setting fully fixes it. Disabling session.upload_progress.enabled, setting fatal_error_backtraces = 0 on PHP 8.5 and reducing post_max_size lower the risk while you wait for packages.

Which PHP version should I use in 2026?

For most sites, PHP 8.4 is the best balance of speed, compatibility and long support. PHP 8.3 is a safe fallback, and PHP 8.2 should only be a short stop because its support ends on 31 December 2026.