PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Check and Patch PHP in cPanel

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.

Which versions are fixed

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 - but not the patch level, and the patch level is the whole question here. Two quick ways to see 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. 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)'

CloudLinux (alt-php)

yum update 'alt-php*'
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.

LiteSpeed

On cPanel, LiteSpeed runs sites through lsphp built from the same ea-php or alt-php packages, so the updates above cover it. Restart LiteSpeed afterwards so no old lsphp process keeps running, and update LiteSpeed itself too - its WebAdmin console carries its own PHP binary:

/usr/local/lsws/bin/lswsctrl restart

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 = 0 in the server's php.ini or FPM pool, then restart the workers. This closes the path the public exploit for CVE-2026-109619 uses.
• For CVE-2026-109618: memory_limit = -1 set with php_admin_value so applications can't override it (temporary - it removes the per-request memory cap), and a low post_max_size - 8M if the site takes no uploads, 32M if it does - with upload_max_filesize below it.
• On PHP 8.5, fatal_error_backtraces = 0.
• If the server runs Imunify360: CloudLinux says its rules block the upload-progress path behind CVE-2026-109619, but 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 after 21 October, spend ten minutes checking:

• PHP files modified in the last week: find ~/public_html -name '*.php' -mtime -7. Your own updates will show up; anything you don't recognise is worth a look.
• Any .php file inside wp-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.