What to ask your host after the October 2026 PHP security release

By CompatNav · Published · Last reviewed · 2 min read

Short answer

Ask your host five things: 1. Has PHP been updated to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or a package with the fixes for CVE-2026-109618 and CVE-2026-109619)? 2. If not, when? 3. If my site runs PHP 8.1 or older, do you apply a backport, and which supported version can I move to? 4. Have you applied the interim settings from php.net’s advisory, including session.upload_progress.enabled=0? 5. Will the update change my PHP series, or only the patch? Then compare their answer with what Site Health shows.

Before you write: look it up

Open Tools → Site Health → Info → Server and note the PHP version and PHP SAPI (how). If the version is already 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, you’re patched for these flaws; no message needed.

The message

To your host: the October 2026 PHP security release (copy and adapt)
Hello,

On 21 October 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (https://www.php.net/archive/2026.php).

My site [address] currently shows PHP [version from Site Health].

1. Has PHP on my server been updated to a version with these fixes? If your package keeps an older version number, can you confirm it includes them?
2. If not yet, when will it be done?
3. If my site runs PHP 8.1 or older: do you apply a backport, and which supported PHP version can I switch to?
4. Have you applied the interim settings from php.net’s advisory, including session.upload_progress.enabled=0?
5. Will the update change my PHP version series (for example 8.1 to 8.3), or only the patch number?

Thank you.

How to judge the answers

AnswerWhat it meansYour next step
Updated to 8.x.y, at or above the patched versionDoneConfirm in Site Health
Our package includes the fixes, with an older numberBackportKeep the written confirmation
Scheduled for [date]Not yetCheck again on that date
8.1 and older are not updatedNo fix for your versionUpgrade safely
We’ll move you to 8.3A series changeCheck your plugins first

php.net’s own guidance for old versions: “Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.” (php.net)

While you wait

The interim settings are for the host, not for WordPress: PHP2Shell mitigations explained. The overall picture: PHP2Shell: what to do now.

Key takeaways

  • Ask for the exact patched version, or confirmation that their package contains the fixes.
  • Ask for a date if it isn’t done; the fixes were released on 21 October 2026.
  • On 8.1 or older: ask about backports, and plan the move to a supported version.
  • Ask whether the series will change; that decides whether you check plugins first.
  • Verify the answer yourself in Site Health afterwards.

Frequently asked questions

My host says the update is done, but Site Health shows an older number.

Some Linux distributions backport fixes into packages without changing the upstream number. Ask the host to confirm, in writing, that their package includes the fixes for both CVEs.

My host doesn’t answer or won’t update. What then?

Treat it as a reason to move: a host that doesn’t apply critical PHP security fixes leaves every site on the server exposed.

Do I need to send this if I’m on managed WordPress hosting?

It’s still worth confirming: open Site Health and check the number. If it’s patched, no message is needed.

Check your own site before you upgrade

CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.

Get CompatNav on wordpress.org How it works

Sources

About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.