How to Check Your PHP Version in WordPress and Update It After the October 2026 Security Release

Short answer: to check your PHP version in WordPress, open Tools > Site Health > Info > Server in your dashboard, or look in your hosting control panel. Then compare it with the versions that fix the critical flaws announced by the PHP project on 2026-10-21: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you are on PHP 8.1 or older, you are on a branch that no longer gets official releases and need to plan a migration. On shared hosting, your host builds the PHP package, so your job is to pick a supported branch and ask the host a precise question.

Why this check matters this week

On 2026-10-20 the PHP project announced an upcoming critical security release. On 2026-10-21 it published a security advisory titled "Critical remote code execution vulnerabilities, update now". The advisory covers two issues, CVE-2026-109618 (remote code execution through out-of-memory corruption) and CVE-2026-109619 (remote code execution through stale global state). The PHP project says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix them and that all PHP users are strongly encouraged to update.

This is a flaw in PHP itself, not in WordPress. Updating WordPress, themes and plugins does not patch PHP, although you should keep them current anyway. A web application firewall may reduce exposure but is not a fix. The real fix is a patched PHP build running on your server.

Some outlets have reported on early attack attempts and given the issue a nickname. That coverage is third-party and changes quickly, so check current status rather than relying on a snapshot. This article stays practical: find your version, interpret it, update it safely.

Step 1: Find your PHP version

Use at least two of the methods below. They can disagree, and that disagreement is useful information.

Method A: WordPress Site Health (easiest)

The WordPress.org documentation says the Site Health screen is in your dashboard under Tools > Site Health, with two tabs: Status and Info. The Info tab has a Server section that lists server details, including PHP settings.

1. Log in to your WordPress dashboard as an administrator.
2. Go to Tools, then Site Health.
3. Open the Info tab and expand the Server section.
4. Read the PHP version line. It looks like 8.3.35 (Supports 64bit values).

The Status tab may also show a notice that your site is running an outdated version of PHP. If you see it, take it seriously. Its absence does not mean you are on a patched release, though, because it only checks for old branches, not for the latest security fix.

Method B: Your hosting control panel

Control panels show the PHP version assigned to each site. Menu names change between panel versions, so treat the wording below as a guide and use your panel's search box if something has moved.

• Hostinger hPanel: according to Hostinger's support documentation, go to Websites, click Dashboard next to your site, and open the PHP Configuration page. The current version is selected there, and the PHP Info page in the same dashboard confirms the active version. Hostinger notes that the choice applies to the whole hosting plan, with some exceptions such as sites made with its AI Builder.
• cPanel: the cPanel documentation says to open MultiPHP Manager. It lists your domains with the PHP version each uses, and shows an "Inherited" label if a domain follows the system default.
• Plesk: look for a PHP settings option on the domain's page. Exact labels vary by Plesk version and host configuration, so check your host's own guide if you cannot find it.

Method C: SSH with php -v

If you have SSH access, run this command:

php -v

The first line shows the version, for example PHP 8.3.35 (cli). One caution: this reports the command-line PHP, which is not always the same as the PHP that serves your website. On servers with several PHP versions installed, the website may run a different one. Use this as a cross-check, not as the final answer.

If you are not comfortable on the command line, skip this method. Methods A and B are enough for most site owners.

Method D: A temporary phpinfo file (not recommended)

You will see guides telling you to upload a file containing phpinfo() and open it in the browser. We do not recommend it. That page prints a lot of server detail: file paths, loaded modules, configuration values and sometimes environment data. Attackers use exactly this kind of information to plan their next step. If you ever create such a file, delete it immediately, never leave it on a public site, and never share a screenshot of the full page. Site Health and your control panel give you the version without that exposure.

Step 2: Read the result against the fixed versions

Compare your version with the release that fixes the issues on your branch, as listed by php.net on 2026-10-21.

Your branch	Fixed in	What it means
PHP 8.5.x	8.5.12	Below 8.5.12 needs the patched build.
PHP 8.4.x	8.4.27	Below 8.4.27 needs the patched build.
PHP 8.3.x	8.3.36	Below 8.3.36 needs the patched build.
PHP 8.2.x	8.2.35	Below 8.2.35 needs the patched build, and the branch reaches end of life on 2026-12-31.
PHP 8.1 and older	No official release	Migrate to a supported branch.

For context, the previous security release on 2026-09-24 shipped 8.5.11, 8.4.26, 8.3.35 and 8.2.34. If your version ends in those numbers, you are exactly one release behind on the current issue.

php.net does not publish an explicit affected range in the advisory. It says all PHP installations serving web requests are at risk, so do not try to argue that your setup is exempt. Treat any version below the fixed one on your branch as needing the update.

The backport caveat: the version string may stay old

Here is the part that confuses many people. Linux distributions and hosting vendors sometimes apply a security fix to the PHP package they ship without changing the upstream version number. Your site could show 8.3.35 and still contain the fix, or it could show 8.3.36 from a vendor build you have not verified. The number alone is not proof either way.

So the correct reading is:

• If your version is at or above the fixed number for your branch, the fix for this issue should be included, but confirm that with your host.
• If it is below, do not assume you are exposed or safe. Check your host's security bulletin or ask them directly (template further down).
• If the host states that it backported the fix, ask them to say which package build contains it.

Step 3: Update PHP safely

On shared hosting you cannot install PHP packages yourself. The host builds them. What you control is which PHP branch your site uses. Moving from an unsupported branch to a supported one is usually your task, and getting the patched build is the host's.

Before you change anything

1. Take a full backup of files and database, and confirm you can restore it. Store the backup away from the live server.
2. Use a staging copy if your host offers one. Many hosts and WordPress plugins can clone a site in a few clicks.
3. List your plugins and themes from Site Health > Info (the Active Plugins and Active Theme sections show versions). Update everything that has an update available, on staging first.
4. Check compatibility. Look at each plugin's page on WordPress.org for the "tested up to" and required PHP information, and note anything abandoned for a long time. Abandoned plugins are the usual cause of errors after a PHP jump.
5. Pick a quiet time and keep your host's support contact handy.

Switching the PHP branch in common panels

• Hostinger hPanel: on the PHP Configuration page, pick the version and click Update. Hostinger's documentation says it takes effect within a couple of minutes and that the list of selectable versions changes over time, so pick the newest supported branch shown. Per-folder overrides exist but are described by Hostinger as temporary, for testing.
• cPanel: in MultiPHP Manager, tick the checkbox for the domain, choose a version from the PHP Version menu, and click Apply. If a version is missing, it is not installed on that server or not available to your account. Ask the host.
• Plesk and others: use the domain's PHP settings page and follow your host's own guide.

For most sites, PHP 8.3 or 8.4 is a sensible target today. According to php.net's supported versions page, 8.3 receives security fixes until 2027-12-31, 8.4 until 2028-12-31 and 8.5 until 2029-12-31. A newer branch gives you a longer runway, but a newer branch also means more chance of an old plugin complaining, so test.

After the switch: test the basics

1. Load the home page, a post, a category page and the login page.
2. Test anything that makes money or collects data: checkout, forms, bookings, logins.
3. Open Site Health again and confirm the new PHP version in Info > Server.
4. Watch your error log for a day. Warnings about deprecated functions are common and often harmless, while fatal errors are not.
5. If something breaks, switch back to the previous branch, restore from backup if needed, and fix the incompatible plugin before trying again. Do not stay on an unsupported branch just because of one old plugin without a plan to replace it.

What if you are on PHP 8.1 or older?

The PHP project says PHP 8.1 and older receive no releases for this issue. It did publish minimal source backports for 7.4, 8.0 and 8.1 on GitHub, but those are source branches for people who compile PHP themselves, not something a typical site owner can apply. Some Linux distributions and extended-support vendors may backport fixes to their own packages, which is why your host's statement matters.

The practical path is to migrate:

1. Move to 8.3 or newer in the panel (after backup and staging tests).
2. If the panel does not offer a supported branch, ask the host to enable one or move your site to a plan that does.
3. Replace plugins and themes that cannot run on current PHP. If a site is heavily customised or old, a staged migration with a professional is often cheaper than repeated emergency fixes. Our remote repair service and Windows support pages explain how remote help works, and you can contact us to talk through your setup.

If you run your own VPS or server, update the PHP packages through your operating system's package manager and restart the PHP service or web server afterwards. Then re-check the version using the methods above. For wider guidance on protecting a business, see our cybersecurity overview.

PHP 8.2 end of life on 2026-12-31

If your site runs PHP 8.2, you have two jobs: get 8.2.35 or a vendor build that contains the fix, and plan the move to a newer branch before 2026-12-31. After that date php.net lists the branch as end of life, which means no further security releases. Migrating now, while you can test calmly, is better than rushing in December.

A separate php.net advisory dated 2026-10-23 concerns a different issue, CVE-2026-115560 in session upload progress. At the time of writing, php.net said the fix had not yet been released and suggested setting session.upload_progress.enabled=0 until the next bugfix release. This is separate from the critical release above. Check php.net for its current status.

How to ask your host a precise question

Vague questions get vague answers. Copy this message and fill in the brackets:

Hello,

My site [yourdomain.com] runs PHP [version shown in Site Health or panel] on [plan name].

PHP announced security releases on 2026-10-21 (8.5.12, 8.4.27, 8.3.36, 8.2.35) for CVE-2026-109618 and CVE-2026-109619.

1. Has the PHP build serving my site been updated with these fixes, or with a backport of them?
2. If the version number did not change, which package build contains the fix?
3. If not yet, when will it be rolled out?
4. Which PHP branches are patched and available for my plan?
5. Is there a security bulletin I can read?

Thank you.

Keep their reply. If the answer is unclear, ask for it in writing and consider whether the plan still fits your needs.

FAQ

How do I check my PHP version in WordPress?

Go to Tools > Site Health > Info in your dashboard and expand the Server section. The PHP version is listed there. You can cross-check in your hosting control panel.

Which PHP versions fix the October 2026 critical flaws?

According to php.net, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 2026-10-21.

Does updating WordPress fix this?

No. This is a flaw in PHP, not in WordPress. Keep WordPress, themes and plugins updated, but the PHP package itself must be patched by your host or server administrator.

My version number is lower than the fixed one. Am I definitely vulnerable?

Not necessarily. Some vendors backport fixes without changing the version string. Ask your host whether the build contains the fix and which package it is.

Is it safe to upload a phpinfo file to check the version?

We do not recommend it. The output exposes detailed server information. Use Site Health or your control panel instead, and delete any such file immediately if you created one.

What should I do if I am on PHP 8.1 or older?

Plan a migration to a supported branch such as 8.3, 8.4 or 8.5. Back up first, test on staging and check plugin compatibility. PHP 8.1 and older receive no official releases for this issue.

When does PHP 8.2 stop getting security fixes?

According to php.net's supported versions page, security support for PHP 8.2 ends on 2026-12-31.

Can I change the PHP version myself?

Usually yes, within the branches your host offers, through a panel such as Hostinger hPanel's PHP Configuration page or cPanel's MultiPHP Manager. Installing a patched build is the host's responsibility.