On 21 October 2026 the PHP project shipped emergency releases for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 - the pair security researchers now call PHP2Shell. Both are rated 9.2 out of 10, neither needs a login, and attacks were reported from the day the fix came out. The bug is in PHP itself, not in your site: updating WordPress, a plugin or a theme does nothing for it. Here's what is affected, how to check the PHP your site really runs in cPanel, and what to do if it isn't patched.
What PHP2Shell is
Two separate bugs in how PHP sets up and tears down a request:
- CVE-2026-109618 - "RCE via OOM corruption". If PHP runs out of memory at the wrong moment while preparing a request, internal data is left half-built, and the cleanup code afterwards treats it as valid.
- CVE-2026-109619 - "RCE via stale global state". Data belonging to one request can survive after its memory has been freed, and the next request handled by the same PHP worker can use it.
Both can end in an attacker running their own code on the server. The PHP team puts the risk on "all PHP installations serving web requests": PHP-FPM, Apache mod_php, php-cgi, LiteSpeed and FrankenPHP. Apache mod_php is the most urgent, because a working exploit there fires before your application's code even runs. Researchers also showed unauthenticated reads of PHP worker memory, which can expose database passwords and API keys.
On 26 October 2026 CISA added both CVEs to its Known Exploited Vulnerabilities catalog, with 29 October as the due date for US federal civilian agencies.
Which versions are fixed
| PHP branch | Fixed in | Note |
|---|---|---|
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | End of life on 31 December 2026 |
| 8.1, 8.0, 7.4 | No official release | Minimal source backports from the PHP security team, and patched builds from hosts and distributions that usually keep the old version number |
| 7.3 and older | No fix from PHP or cPanel | Some vendors (CloudLinux, Ubuntu Pro, TuxCare ELS) ship backports; otherwise upgrade to a supported branch |
Step 1: Check the PHP your site actually runs
In cPanel, Software → MultiPHP Manager shows the branch each domain uses, such as PHP 8.3. The exact patch level is the whole question here, and two quick ways show it:
-
A temporary phpinfo page. Create a file with a random name in the site's folder containing
<?php phpinfo();, open it in the browser and read the version at the top, then delete the file. - The response header, if your server sends it:
curl -sI https://example.com/ | grep -i x-powered-by
x-powered-by: PHP/8.4.27
Don't go by php -v over SSH: on cPanel the command-line PHP is often a different version from the one serving the website.
On 8.2 to 8.5, compare the number with the table: anything lower is unpatched, unless your host or Linux distribution backported the fix without changing the number - some do, so check their security advisory before assuming the worst. On 8.1, 8.0 or 7.4 the number can't tell you anything - a fixed 8.1 build still says 8.1.34 - so only your host can confirm it, and the lasting fix is moving to a supported branch.
Step 2: On shared or reseller hosting, patching is your host's job
You can't update PHP on a shared server; the host updates the packages for everyone. What you can do:
- Ask directly: "Have the PHP builds on my server been updated for CVE-2026-109618 and CVE-2026-109619, including the 7.4, 8.0 and 8.1 builds?"
- Move off 8.1 or older. Switching the domain to 8.3 or 8.4 in MultiPHP Manager puts you on a branch that gets official fixes. Test first - see changing your PHP version in cPanel without breaking your site.
The stopgap settings below don't help much from a cPanel account either: PHP's advisory says they must be set in the server's configuration, not through ini_set() or a .user.ini file, which is where account-level PHP settings usually end up.
Step 3: On your own VPS or dedicated server
cPanel with EasyApache 4 (ea-php)
dnf update 'ea-php*' # yum on older systems
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
Run the plain update, not a security-only one: these packages shipped before their advisory metadata, so --security updates can skip them. To confirm a build has the fix, its changelog should name both CVEs:
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
Also update cPanel & WHM itself, which runs its own PHP for the cPanel interfaces and Roundcube webmail. Builds 138.0.18, 136.0.50 and 134.0.66 or later ship PHP 8.4.27 there, and 110.0.153 backports the fix to PHP 8.1.34.
CloudLinux (alt-php)
dnf clean all && dnf upgrade 'alt-php*' # CloudLinux 8, 9 and 10
yum clean all && yum update 'alt-php*' # CloudLinux 7
rpm -q --changelog alt-php81-common | grep -E 'CVE-2026-(109618|109619)'
This is the way to check the 7.4, 8.0 and 8.1 builds, whose version numbers don't change. If you added the TuxCare ELS alt-php repository (php-els), keep it enabled. If you disabled it, enable it again. On CloudLinux 10 it is the only source of alt-php versions other than 5.2. Fixed alt-php for CloudLinux 6 is not confirmed yet.
LiteSpeed
On cPanel, LiteSpeed runs sites through lsphp built from the same ea-php or alt-php packages, so the updates above cover it. Restarting LiteSpeed does not restart lsphp: since LiteSpeed 5.3, PHP runs in detached mode. Restart the lsphp processes yourself, either all at once or one by one as each is next used:
pkill lsphp # all at once
touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt # or one by one
Update LiteSpeed itself too - its WebAdmin console carries its own PHP binary. LiteSpeed's changelog lists the fix in 6.3.7 build 5 (22 October) and later, and in 6.4 RC2 build 3. To update to the latest 6.3.7 build:
/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7
Whatever the setup, restart every PHP worker after updating. A patched package on disk does nothing for an FPM pool or lsphp process still running the old binary.
If you can't patch today
PHP's advisory lists measures that reduce exposure. In its words they "do not make an installation safe" - they buy time until the update:
-
session.upload_progress.enabled = 0in the server's php.ini or FPM pool, then restart the workers. This closes the path the public exploit for CVE-2026-109619 uses. PHP now also suggests keeping it at 0 after you update, until its next regular release, because of a further, unlikely RCE path (CVE-2026-115560). - For CVE-2026-109618:
memory_limit = -1set withphp_admin_valueso applications can't override it (temporary - it removes the per-request memory cap), and a lowpost_max_size- 8M if the site takes no uploads, 32M if it does - withupload_max_filesizebelow it. - On PHP 8.5,
fatal_error_backtraces = 0. - If the server runs Imunify360 with its WAF enabled: CloudLinux says rulesets 8.83 to 8.88 block the known exploit requests and the public exploit tool, so check that 8.88 or later has arrived. On LiteSpeed, blocking starts with 8.84. A request made to look like a normal upload from the site's own pages may not match, and nothing blocks the out-of-memory path of CVE-2026-109618 yet. The update is still the fix.
Was the site hit before it was patched?
If a site ran unpatched PHP on or after 17 October - the day of the earliest exploit attempt Amazon reported, four days before the fix - spend ten minutes checking:
- PHP files modified since 17 October:
find ~/public_html -name '*.php' -newermt 2026-10-17. Your own updates will show up; anything you don't recognise is worth a look. - Any
.phpfile insidewp-content/uploads. There should be none. - New administrator accounts in WordPress, and unfamiliar entries under cPanel → Cron Jobs.
Because worker memory could leak, change the database password, admin passwords and any API keys the site holds once PHP is patched. If you do find something, follow cleaning up a hacked WordPress site.
Sources: PHP security advisory, 21 October 2026; GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; CloudLinux package status and Imunify360 protection.
FAQ
What is PHP2Shell?
PHP2Shell is the name researchers gave two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both can let an unauthenticated attacker run code on a server through PHP-FPM, Apache mod_php, php-cgi, LiteSpeed or FrankenPHP.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1, 8.0 and 7.4 get no official release: the PHP security team published minimal source backports, and hosts and distributions ship patched builds that usually keep the old version number. PHP 7.3 and older get no fix from PHP or cPanel. Some vendors, such as CloudLinux, Ubuntu Pro and TuxCare ELS, ship backports; otherwise, upgrade.
Do I need to update WordPress for PHP2Shell?
No. The vulnerabilities are in PHP itself, so WordPress core, plugins and themes are not where the fix goes. The server's PHP has to be updated, which on shared hosting your host does.
My site runs PHP 8.1 or 7.4. Is it protected?
Only if your host installed a backported build, and the version number won't show it: a fixed 8.1 build still reports 8.1.34. Ask your host, and plan to move the site to PHP 8.3 or 8.4, which receive official fixes.
Does turning off session.upload_progress fix PHP2Shell?
No. Setting session.upload_progress.enabled to 0 server-wide closes the path the public exploit for CVE-2026-109619 uses, but it does nothing for CVE-2026-109618. PHP's advisory says only the update is a complete fix. PHP now also suggests keeping it at 0 after you update, until its next regular release, because of a further, unlikely RCE path (CVE-2026-115560).
Originally published on the Getwebup blog.
This article was created with the help of AI.
Top comments (0)