How to Update PHP in WordPress: October 2026 Security Fixes

If you manage a WordPress site, the October 2026 PHP security alert needs a hosting-level check. Updating WordPress, your theme or a security plugin does not update the PHP runtime that executes your site.

Following Wordfence’s alert, we checked the PHP project’s release notices and technical advisories. The practical job is to identify the runtime serving your website, get a patched build deployed, and verify the journeys your customers depend on.

Advisory checked: 21 October 2026. This guide covers CVE-2026-109618 and CVE-2026-109619. The versions below are the fixes announced for this incident, not a permanent list of the newest PHP releases. Recheck the linked advisories when using this guide later.

Which PHP versions fix the October 2026 vulnerabilities?

The PHP security announcement identifies four patched releases. Use the fixed release for your supported branch, or a newer release in that branch containing the fixes.

A vendor may backport a security fix while retaining an older-looking version number. If your host uses that approach, request its package revision and security notice confirming coverage of both CVEs. A control panel showing only “PHP 8.3” cannot establish whether the patch is installed.

According to PHP’s support schedule, upstream security support for PHP 8.2 ends on 31 December 2026. PHP 8.1 and older are outside upstream support. If you depend on an older branch, ask your vendor about its specific security coverage and arrange a supported migration. An old installation continuing to work is not evidence that it receives fixes.

What do these PHP vulnerabilities mean for WordPress?

Both advisories carry a critical CVSS v4.0 rating of 9.2. Successful exploitation can allow someone who has not logged in to execute code with the web worker’s privileges. This does not mean that every WordPress site has been compromised, or that an attacker automatically gains root access.

• CVE-2026-109618 concerns invalid request memory left behind when PHP handles an out-of-memory interruption.
• CVE-2026-109619 concerns request-owned state that can remain reachable when a worker processes a later request.

The PHP project warns about installations serving web requests across different server configurations. Do not assume that PHP-FPM, LiteSpeed or a managed hosting plan makes the update unnecessary. The exact attack conditions vary, and a host should assess its own build and configuration.

For the out-of-memory issue, the researchers demonstrated an attack against Apache mod_php that can run before application code starts. That is an important limit on what a WordPress-level security plugin can do. A firewall can remain part of your protection, but it is not a substitute for installing the runtime fixes.

How to check your PHP version in WordPress

1. Sign in to the WordPress dashboard for the site you are checking.
2. Open Tools > Site Health.
3. Select the Info tab and expand Server.
4. Record the full PHP version and the time checked. Keep the result with the domain name.

If you cannot access this information, ask the administrator or host for it. Avoid publishing a public phpinfo() page: it can expose configuration details that visitors do not need.

Check production and staging separately. A staging environment may use a different PHP branch. For an agency managing several sites, keep one row per domain rather than assuming that a hosting-account setting covers every installation.

Why php -v may show a different version

The terminal’s PHP executable and the runtime serving browser requests can differ. php -v tells you about that command-line executable; it does not, by itself, prove which version serves WordPress. Hostinger’s Composer troubleshooting documentation explains this distinction for its hosting environment.

Use Site Health to check the web runtime. If scheduled jobs or maintenance commands call another PHP binary, have the administrator check those too. When versions disagree, resolve the domain, handler and executable involved rather than choosing whichever result looks newer.

How to update PHP on managed or shared hosting

Your host usually controls installation of PHP security packages. A branch selector can let you move between 8.3 and 8.4, while the host controls which patch build sits behind each choice. Start by asking whether the current branch has already been patched.

For Hostinger, the documented route is Websites > the site’s Dashboard > PHP Configuration. Its PHP configuration guide says a plan-level selection can apply to other sites on that hosting plan. Review the scope before changing it. A patch request for one shop should not accidentally become an untested branch change for several client sites.

Other hosts use different controls. Follow your provider’s documentation and do not copy a server command intended for a different operating system or package repository.

A message you can send to your hosting provider

Please confirm whether the PHP runtime serving [your domain] is patched for CVE-2026-109618 and CVE-2026-109619. Please provide the full runtime version, package revision or backport advisory, and confirm that the affected web workers have been restarted or replaced as required. Does this also cover staging and any other PHP runtimes used by this site? If action is still pending, what is the deployment time and recommended interim handling?

Keep the reply. “PHP is up to date” is less useful than a specific version or a vendor advisory that names both vulnerabilities.

How to update PHP without overlooking a broken workflow

Move promptly, but give the change a short, written acceptance check. WordPress’s PHP update guidance recommends preparation, backups and checking theme and plugin compatibility. For this incident, separate a security patch within your current branch from a broader branch migration where the host offers that choice.

1. Record the starting point. Note the web PHP version, active theme, essential plugins and relevant extensions. Agree who can make the hosting change and who will verify it.
2. Confirm recovery access. Check that a recent database and file backup exists, that you can access it if WordPress stops loading, and that the host can help restore service. Record the backup time.
3. Check a representative staging copy where available. Use the intended patched runtime and required extensions. Keep test payments and emails away from real customers. A passing homepage alone is insufficient.
4. Deploy the patched build. On managed hosting, follow the host’s process. On a self-managed server, the administrator should use the appropriate trusted vendor packages and handle every affected worker pool. Do not mistake a downloaded package for a running update.
5. Verify production. Recheck the web PHP version or vendor patch confirmation, run the agreed journeys, and review the error log for new failures. Record actual results instead of marking everything passed by default.

If staging preparation would delay an urgent patch, ask the host to help plan a prompt deployment with recovery available. Do not leave a known vulnerable runtime in place indefinitely while waiting for a perfect testing environment.

What should you test after the PHP update?

Choose the rows that match your site. Run meaningful tests in an appropriate test environment, then make safe production checks. Do not repeatedly charge a real card to see whether checkout works.

If a shop fails a check, our WooCommerce checkout diagnostic guide helps separate payment, request and email problems. For paid learning access, use the LearnDash purchase-access trace.

Download the PHP update verification worksheet

Download the free CSV worksheet for a per-site record of runtime evidence, host confirmation, backups and acceptance tests. Open it in Excel, Google Sheets or another spreadsheet application. It is a blank working resource with suggested checks, not a report that WooCrafters has tested your site.

What if WordPress breaks after changing PHP?

Record the failing URL, action, time and first relevant error. Ask the host or developer to identify whether the change exposed incompatible code, removed a required extension or introduced a configuration problem. Do not start by disabling every plugin on a live store.

If you need emergency recovery, agree a temporary route with the host and a deadline for returning to a patched environment. Avoid restoring an old database over new orders or learner activity without reconciliation. Restoring site files also does not necessarily change the server’s PHP package.

An update closes the vulnerabilities addressed by that update; it does not remove a backdoor already installed. If you see unexpected administrators, modified files or unexplained redirects, preserve logs and seek incident-response help alongside patching.

Common questions about this PHP security update

Will a WordPress automatic update fix these vulnerabilities?

No. These are PHP runtime vulnerabilities. WordPress core, plugin and theme updates remain important, but your host or server administrator must also deploy the PHP fixes.

Can I just change PHP settings or install a firewall?

The technical advisories describe measures that reduce particular attack paths, but neither offers a complete configuration-only solution. Have your administrator follow the current advisories if a patch is temporarily unavailable. Do not treat an arbitrary memory-limit change or a quiet error log as proof of protection.

Do I need to move straight to PHP 8.5?

No. The announced fixes cover four supported branches. A patched, compatible current branch can address this incident without combining it with a larger migration. Check the branch’s remaining support period and plan the next migration separately.

Does a lower version number always mean the host is unpatched?

No. A distribution or hosting vendor may backport fixes. Ask for its security notice and installed package revision. Without that evidence, do not infer patch status from an abbreviated dashboard label.

Keep the record after this alert leaves the news cycle. Add runtime checks and recovery planning to your WordPress maintenance routine, so the next security release has a clear owner and a repeatable verification process.