How to update your PHP version in cPanel (2026)

What cPanel actually changes (and what it doesn’t)

If your WordPress site is on shared hosting, cPanel is almost certainly where you change the PHP version — through a tool called Select PHP Version or MultiPHP Manager. It takes about thirty seconds, and most of the time it just works. But there is one thing it is important to understand before you touch it, because in October 2026 it caught a lot of people out.

cPanel does not install PHP. Your host does. What the dropdown in cPanel does is pick which of the PHP builds your host has already installed should run your domain. On a typical cPanel/EasyApache server those builds are named ea-php74, ea-php80, ea-php81, ea-php82, ea-php83, ea-php84 and ea-php85. Changing the dropdown swaps your site from one to another. It does not download anything new.

That distinction is the whole story behind the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), two critical bugs in the PHP runtime itself that let an attacker run code on the server without logging in. They were fixed in specific PHP builds on 21 October 2026. If your host has installed the patched ea-php packages, picking a version in cPanel moves you onto a safe one. If your host has not updated those packages yet, then every option in the dropdown is still vulnerable — because you are only choosing between old builds.

Where you change it

Select PHP Version / MultiPHP Manager

Safe choice for WordPress

PHP 8.3 or 8.4

Patched cPanel builds

ea-php82–85 · 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12

Also patched (backports)

ea-php74 · ea-php80 · ea-php81

So this guide does two jobs: it walks you through changing the version safely, and it makes sure you ask your host the one question that actually determines whether you are protected. For the full background on the vulnerability itself, read PHP2Shell and WordPress; for the wider picture, our WordPress security guide puts it in context.

Check your current version first

Before you change anything, write down what you have now — both so you know whether you even need to move, and so you have a version to roll back to. The most reliable place is inside WordPress, because it reports the PHP that actually answers your visitors’ requests.

1. Log in to wp-admin and open Tools › Site Health.
2. Click the Info tab, then expand Server.
3. Read the PHP version row (for example 8.1.29). PHP SAPI tells you how PHP runs — on cPanel it is usually fpm-fcgi (PHP-FPM) or cgi-fcgi.

Compare that number with the patched releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below the fixed version on its branch, or anything on PHP 8.1, 8.0 or 7.4, needs attention. Remember the version-number trap, though: a host that backports fixes may keep the old number, so a low number does not always mean “unpatched” — and a number at or above the fixed release is only safe if the build genuinely includes the fix. The only way to be certain is to ask your host, which is the final step below.

Select PHP Version vs MultiPHP Manager

cPanel has two tools that do the same job, and which one you see depends on your host’s setup. Both live under the Software section of cPanel.

Switch your version safely

The switch itself is a dropdown and a button. The care goes into making sure nothing on your site depends on something a newer PHP removed. If you are jumping several versions — say from 7.4 straight to 8.3 — treat it as a real change and test. If you are nudging 8.2 to 8.3, it is usually uneventful.

1. 1

   Step 1: Back up files and the database first

   Use cPanel’s Backup Wizard or JetBackup if your host provides it, and download a copy off the server. Your host’s automatic backup is fine too, as long as you know how to restore it.
2. 2

   Step 2: Update WordPress, plugins and theme

   Most PHP-compatibility fixes ship as ordinary plugin updates, so install everything pending before you switch. Replace any plugin that hasn’t been updated in two years — those are the usual cause of fatal errors on new PHP.
3. 3

   Step 3: Test on staging if you have it

   Many cPanel hosts include WordPress Toolkit, which clones a site to a staging copy in a click. Switch the clone’s PHP version, click through your pages, and only then touch the live site.
4. 4

   Step 4: Switch the live domain to 8.3 or 8.4

   In MultiPHP Manager or Select PHP Version, set the domain to ea-php83 or ea-php84 and apply. The change usually takes effect within a minute.
5. 5

   Step 5: Test, then watch the error log

   Re-open Tools › Site Health › Info › Server to confirm the new version, then test the homepage, a post, a contact form, login and wp-admin. Turn on logging in wp-config.php for a day to catch anything quiet.

define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );      // writes wp-content/debug.logdefine( 'WP_DEBUG_DISPLAY', false );  // never print errors on the page

Want the long version of this — compatibility checks, common errors and a rollback plan? See how to check and update your PHP version in WordPress.

The catch: the host has to patch the server

Here is the part the dropdown can’t do for you. Picking ea-php83 only protects you against PHP2Shell if the server’s ea-php83 package has itself been updated to 8.3.36 or a backported equivalent. On a well-run host that happened automatically within a day of the 21 October release. On a slower one, you can select the “latest” version in cPanel and still be running a vulnerable build, because the package on disk is old.

cPanel shipped the fixes as EasyApache 4 package updates:

• ea-php82, ea-php83, ea-php84 and ea-php85 at 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• Backported fixes for the end-of-life branches ea-php74, ea-php80 and ea-php81, which keep their old version numbers but carry a 21 October 2026 (or later) build.

If you run the server yourself in WHM, you update and restart with a couple of commands. If you are a hosting customer, you can’t — so you ask, and you ask for specifics. “We’re aware and monitoring” or “we added firewall rules” is not the same as “the packages are patched and PHP has been restarted.” Firewall rules are a useful stopgap, but a patched runtime is the only real fix.

$ sudo dnf upgrade --refresh 'ea-php*'# CloudLinux alt-php as well, if you use Select PHP Version$ sudo dnf upgrade --refresh 'alt-php*'$ sudo /scripts/restartsrv_apache_php_fpm$ sudo /scripts/restartsrv_httpd

Copy this, fill in your domain, and send it to support:

Hello,

My site (yoursite.com) is hosted on your cPanel/shared hosting. After the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), I need to confirm the server is actually patched, not just that I can pick a PHP version in cPanel.

Could you confirm, in writing:

1. That the EasyApache ea-php packages serving my account have been updated for both CVEs (ea-php82/83/84/85 at 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, or the backported ea-php74/80/81 builds dated 21 October 2026 or later).
2. The exact PHP version and build date my domain now runs.
3. The date and time PHP-FPM / Apache was last restarted, so the patched code is actually loaded.
4. Whether any interim mitigation (WAF rules, disabled session upload-progress) was applied in the meantime.

Thank you.

There’s a ready-made version of this conversation, with follow-up questions and what a good answer looks like, in is my WordPress host patched?

On Plesk instead?

Plesk is the other common shared-hosting panel, and the shape is identical. You change the per-site version under Websites & Domains › PHP (choose the PHP handler and version there), and the server-level patching is still the host’s job. Plesk released fixed “PHP for Linux” builds: PHP 8.2–8.5 at the fixed upstream versions, and patched 7.4, 8.0 and 8.1 builds that keep the same version number with a 21 October 2026 build date. As the Plesk admin you install them from Tools & Settings › Updates; as a customer, send the same email. The version-number trap is sharper on Plesk precisely because the old branches don’t change their number when patched — check the build date, not just the version.

Stop babysitting PHP upgrades

PHP upgrades never stop. A new version lands every year, each one supported for about four, and every few years a runtime bug like PHP2Shell forces an unscheduled scramble through MultiPHP Manager. On shared hosting you’re always dependent on how fast your host patches the ea-php packages underneath you — and you only find out how fast that is during an emergency.

There’s a more structural way out: don’t run PHP at all. Presscomet keeps the WordPress admin, the block editor, your URLs, feeds and REST API, but runs on Node.js with no PHP runtime — so PHP2Shell and the whole class of PHP-runtime bugs simply don’t apply, and there’s no PHP version to track in a panel. It is not “unhackable”: it has its own software to keep updated (Node.js, its libraries and the server it runs on) and its own login to protect. And because it doesn’t execute PHP, your old PHP plugins don’t run — the common jobs (SEO, forms, SMTP, redirects, caching, custom fields) are built in instead, and WooCommerce stores aren’t supported. Read can you run WordPress without PHP? before deciding whether it fits.

If it does, the migration only reads your existing site and lists what would move over — it never changes anything on your cPanel account — so trying it costs you nothing.