How to Update PHP in WordPress: Check Your Version and Apply Security Updates

To update PHP in WordPress, first check which PHP version your site runs (Tools → Site Health → Info → Server). Back up the site, test the new version on a staging copy, and then switch the version in your hosting control panel or ask your host to do it. WordPress itself does not update PHP. PHP is part of the server, so the change happens at your host, not in the WordPress dashboard.

After the PHP2Shell vulnerabilities of October 2026, two different jobs matter. You need to run a supported PHP branch (8.2 or newer), and that branch needs to be a patched build that includes the October 21 security fixes. This guide covers both, with the checks that prevent a broken site.

Key points

• Updating WordPress, themes or plugins never changes the PHP version or patches PHP.
• Check your version in Site Health. The command-line php -v can report a different PHP than the one serving your site.
• WordPress recommends PHP 8.3 or newer. PHP 7.4, 8.0 and 8.1 no longer get security fixes from the PHP project.
• Switching branches is a compatibility change. Back up and test on staging first, because old plugins and themes are what usually break.
• On shared and managed hosting, the host installs patched builds. Ask it directly about CVE-2026-109618 and CVE-2026-109619.
• Updating PHP does not update WordPress either. Keep WordPress current too: the separate wp2shell flaw was fixed in WordPress 6.9.5 and 7.0.2.

Step 1: Check your PHP version

Use the method that reads the PHP actually serving your website.

Write down the version and the date. If your host uses distribution packages (common on VPS and dedicated servers), the version number may not tell you whether security fixes are included. Step 5 covers that.

Step 2: Decide which version to move to

For most WordPress sites, 8.3 or 8.4 is the practical target. It meets WordPress's recommendation and leaves room before the next forced move. If you are on 8.2, plan the next step now, because its security support ends at the end of 2026. If you are on 7.4 or 8.1, treat the move as a project: those branches are out of upstream support, and themes or plugins written for them are the most likely to fail on 8.3.

Step 3: Back up the site

Take a full backup of the files and the database before you change anything, and confirm that you can restore it. A backup you have never restored is a hope, not a plan. Many hosts include one-click backups. If yours does not, export the database and download the wp-content folder at minimum.

Step 4: Test on a staging copy

Create a staging copy of the site (most managed WordPress hosts offer this), switch the staging copy to the new PHP version, and then test:

• The home page, a blog post, and your most important landing pages.
• Every form, including the contact form, newsletter signup and checkout if you sell online.
• The WordPress admin: editing a post, uploading an image, saving settings.
• Any page that uses a page builder, a slider or a custom plugin.

Turn on debug logging on staging (WP_DEBUG_LOG) and read the log after testing. Deprecation notices are warnings; fatal errors are blockers. Update or replace any plugin or theme that produces them before you touch the live site. A plugin that has not been updated in years is a security risk in its own right, PHP2Shell or not.

Step 5: Switch the live site and confirm the patch

Where you make the change depends on your hosting.

• cPanel: look for MultiPHP Manager (or Select PHP Version on CloudLinux servers), choose the domain and the version, and apply.
• Plesk: open the domain in Websites & Domains, go to PHP settings, choose the version, and save.
• Hostinger (hPanel): open the website, then Advanced → PHP Configuration.
• SiteGround: Site Tools → Devs → PHP Manager.
• Managed WordPress hosts: most offer a PHP version selector in the site's dashboard. If you cannot find one, ask support to make the change.
• VPS or dedicated server: install the patched package or upstream release for your chosen branch, point the web server or PHP-FPM pool at it, and restart every PHP worker so none keeps running the old binary. If the site runs in containers, rebuild the image on a patched base and redeploy. The patched packages for Debian, Ubuntu, Red Hat and AlmaLinux are listed in our PHP2Shell guide, in its section for server administrators.

Then confirm two things. First, Site Health shows the new version. That matters because Site Health reads the PHP that serves web requests, while php -v on the command line can show a different, already-updated binary. Second, the build includes the October 2026 security fixes. On hosts that track upstream releases, the version should be at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12. On distribution packages, check the vendor's notice or package changelog for CVE-2026-109618 and CVE-2026-109619, because backported fixes often keep the old version number. On shared hosting, ask:

"Is the PHP build serving my site patched for CVE-2026-109618 and CVE-2026-109619?"

Keep the answer with the date. Our explainer on what PHP2Shell is and who is affected has the background.

Step 6: Check the live site afterwards

1. Repeat the staging tests on the live site.
2. Submit a test form and confirm the message arrives.
3. Check that your pages still return status 200 and that the sitemap still loads.
4. Watch the error log for a day.
5. If the site was exposed while unpatched, look for unknown admin users, recently changed files in the web root and unexpected scheduled tasks. For PHP2Shell, start from October 17, 2026, when AWS first saw exploitation attempts, not from the patch date.
6. If the server ran unpatched PHP on the internet, change the database password in wp-config.php, regenerate the WordPress salts and rotate any API keys stored on the server. The PHP2Shell flaws can leak server memory.

If something breaks

Switch the PHP version back in the same control panel. That usually restores the site within a minute. Then find the failing plugin or theme in the error log, and update, replace or remove it before you try again. Do not stay on an unsupported branch as a long-term fix. Rolling back buys time to fix the incompatibility.

A short WordPress security checklist to finish

• PHP on a supported branch, with a patched build confirmed by your host or package changelog.
• WordPress core, themes and plugins updated, and unused plugins and themes deleted, not just deactivated.
• Admin accounts reviewed: remove old users, require strong unique passwords and two-factor sign-in.
• Backups running on a schedule, stored away from the server, and tested by restoring one.
• A named person responsible for the next security update, and a way for the host to reach them.

The last item is the one most sites lack. If nobody owns these updates on your site, it may be time to choose a setup with less to maintain. Our guide to WordPress alternatives compares the options by who maintains what.

Frequently asked questions

Can I update PHP from the WordPress dashboard?

No. WordPress can show you the version and may display a "PHP update recommended" notice, but the change happens in your hosting account or on the server.

Will updating PHP break my site?

It can if a plugin or theme uses code that newer PHP versions no longer accept. That is why you test on staging first. Well-maintained plugins usually support current PHP branches.

What PHP version does WordPress need?

WordPress recommends PHP 8.3 or newer. WordPress 7.0 raised the minimum supported version to 7.4, but 7.4 no longer receives security fixes from the PHP project, so the minimum is not a safe target.

Do I also need to update WordPress?

Yes, separately. PHP and WordPress have their own security releases. The 2026 wp2shell vulnerability was in WordPress core, is on CISA's list of known exploited vulnerabilities, and was fixed in WordPress 6.9.5 and 7.0.2, so check Dashboard → Updates as well as your PHP version.

My host says PHP 8.3, but not 8.3.36. Am I patched?

Ask. Hosts that build PHP from distribution packages may include the fixes without changing the version number. Get the answer in writing, naming both CVE IDs.

Continue with the next task

• The vulnerability behind this guide: PHP2Shell explained
• Decide whether to keep maintaining WordPress: WordPress alternatives for business websites
• Plan a platform move safely: Website redesign SEO checklist

About this article. Written on October 22, 2026, and updated the same day with distribution package versions and post-patch checks. Control-panel names and menus vary by host and change over time, so follow your host's documentation where it differs. Drafted by an AI agent from the sources below, then checked against them and approved for publication by Vincent Chen. The illustrations are original diagrams made for this article.

Sources

Accessed October 22, 2026.

• WordPress.org: Requirements
• Make WordPress Core: Dropping support for PHP 7.2 and 7.3
• Hostinger: How to update PHP in WordPress
• WordPress Developer Resources: Debugging in WordPress
• PHP: Supported versions
• PHP: PHP security releases announcement, October 21, 2026
• Datadog Security Labs: PHP2Shell: detection, analysis and remediation
• AWS Security Blog: PHP2Shell exploitation prior to public disclosure
• Debian: security tracker for CVE-2026-109618; Ubuntu: USN-8948-1; Red Hat: RHSA-2026:87070
• WordPress: WordPress 7.0.2 release