How to Upgrade PHP to Patch PHP2Shell (cPanel, Plesk, VPS & WordPress)

By Glenn Lyvers · Updated October 24, 2026 · 7 min read

Patching PHP2Shell means getting your site onto a PHP build that contains the October 21, 2026 fix and making sure that build is the one actually running. How you do that depends on where your site lives. This guide walks through each common setup, in order from easiest to hardest, and covers the part that catches people out: not breaking the site while you do it.

First, choose the smallest safe jump

The lowest-risk upgrade is a patch release on the branch you already run. Going from 8.2.30 to 8.2.35, or from 8.3.20 to 8.3.36, fixes PHP2Shell without changing how PHP behaves, so your site and plugins keep working.

Jumping branches, for example from 7.4 to 8.3, is a bigger change. PHP 8 removed and changed functions that older themes and plugins rely on, and a site that has not been touched in years can show a white screen or a “critical error” afterward. If you are on 7.4, 8.0 or 8.1, you still need to move, because those branches have no official fix, but do it with a backup and a test plan.

Back up before you touch anything

Take a full backup of files and database, and download it off the server. If your host offers one-click backups, use them, but keep your own copy. If you suspect the site may already be compromised, keep that backup separate and do not restore it blindly later. My guide on whether restoring a backup fixes a hack explains why.

Shared hosting and cPanel

On most shared hosting you cannot install PHP yourself; you choose from the builds your host provides. Open MultiPHP Manager (or Select PHP Version on CloudLinux hosts), select your domain, and pick the newest branch your site supports. Then contact your host and ask them to confirm, in writing, that the build includes the fix for CVE-2026-109618 and CVE-2026-109619. If your host cannot confirm a patched build, that is a strong signal to move hosts.

After switching, check MultiPHP INI Editor or PHP Options. Settings such as memory_limit and upload_max_filesize are often per-version and reset to defaults on a new branch.

Plesk

Open Tools & Settings → Updates and install the latest PHP components, then go to the domain’s PHP Settings and select the patched version. Plesk restarts PHP-FPM for the domain when you save, but confirm the new version with a phpinfo check afterward.

VPS and dedicated servers

On Ubuntu or Debian, update through the package manager: sudo apt update && sudo apt upgrade, which pulls your distribution’s backported fix. If you use a third-party PHP repository, check that it has published the fixed release; at least one popular repository lagged on disclosure day, and security reporters advised switching to distribution packages or building from source until it caught up. On Red Hat-family systems, use dnf update 'php*', and on cPanel/WHM servers update EasyApache 4 PHP packages through WHM or yum update 'ea-php*'.

Then restart every PHP process: systemctl restart php8.3-fpm (match your version), systemctl restart apache2 or httpd for mod_php, or lswsctrl restart for LiteSpeed. A server with several PHP versions needs every one of them updated and restarted, not just the default.

Test the site properly

Do not stop at “the homepage loads.” Log in to the admin, submit your contact form, run a test checkout if you sell anything, and check the error log for new warnings. In WordPress, Site Health will flag plugins that misbehave. If something breaks after a branch jump, the usual fix is updating the offending plugin or theme, not rolling PHP back. Rolling back to an unpatched build reopens the hole.

Verify, then check for intruders

Confirm the version from the web side using the methods in how to check your PHP version. Then remember that the exploit attempts started on October 17, before most people had any chance to patch. Upgrading closes the door but does not evict anyone who already came in. Spend twenty minutes on the checks in signs your site was compromised through PHP2Shell.

If you would rather not do any of this yourself, my emergency PHP2Shell upgrade covers every step above for a flat $195, and same-day service is still likely even with the current rush.

Common questions

How do I upgrade PHP in cPanel?

Open MultiPHP Manager, or Select PHP Version on CloudLinux hosts, choose your domain and select the newest supported version. Then ask your host to confirm that the build includes the fix for CVE-2026-109618 and CVE-2026-109619.

Will upgrading PHP break my WordPress site?

A patch release on the same branch, such as 8.2.30 to 8.2.35, almost never breaks anything. Jumping branches, such as 7.4 to 8.3, can break old plugins and themes, so take a backup and test the admin, forms and checkout afterward.

Do I have to restart PHP after upgrading?

Yes. Restart PHP-FPM, Apache or LiteSpeed. Running PHP workers keep the old vulnerable code in memory until they restart, so a patch that is installed but not loaded protects nothing.

Should I roll back PHP if my site breaks?

Not to an unpatched build. Fix the plugin or theme that breaks, usually by updating it, or move to a patched release on an older branch that your site supports. Rolling back to a vulnerable build reopens PHP2Shell.

What if my host has no patched PHP version?

Ask them in writing when a patched build will be available. If they cannot give a clear answer, put the site behind Cloudflare for its WAF rules as a stopgap and plan a move to a host that patches promptly.