The October 2026 PHP security release: what Australian website owners need to do now

Quick answer: 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 that can allow an attacker to run code on your server without logging in. PHP’s own advice is blunt: “All PHP users are strongly encouraged to update immediately.” If a managed host runs your website, ask them to confirm they’ve patched. If you run your own server, update now. Static sites with no PHP are not affected. This is a “sort it this week” job, not a “sort it this quarter” one.

Most of the web runs on PHP — it powers WordPress, WooCommerce, Laravel apps and a large share of business websites. So when the people who maintain PHP release an emergency fix and tell everyone to update straight away, it’s worth five minutes of your attention even if you’re not technical.

Here’s what happened, who it affects, and the short checklist to work through.

What was released

On 20 October 2026 the PHP project gave advance notice of a security release, then on 21 October shipped the fixes: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. (Because the release landed at 14:00 UTC, in Australian time that was the early hours of Thursday 22 October.)

The release fixes two critical vulnerabilities, both rated 9.2 out of 10 on the CVSS v4.0 severity scale:

• CVE-2026-109618 — an out-of-memory condition can interrupt PHP while it’s only partly finished setting up a request, after which cleanup can treat invalid data as if it were valid.
• CVE-2026-109619 — data belonging to one request can survive after its memory has been freed, and a later request handled by the same worker process may then use it.

You don’t need to follow the mechanics. The part that matters is what they allow: unauthenticated remote code execution. In plain English, that means an attacker who can reach your website — with no password and no account — may be able to make your server run their code. That’s about as serious as a web vulnerability gets, which is why both carry a 9.2 rating and why PHP is telling everyone to update rather than wait.

Who is affected

According to the advisories, every PHP version below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected. PHP’s release notes say the risk covers “all PHP installations serving web requests” — including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed — and that the risk is highest for mod_php, where an unauthenticated request can trigger the problem before any of your own application code even runs.

A few practical translations:

• If your site runs on WordPress, WooCommerce, a Laravel app, or almost any other PHP-based platform, it uses PHP, and it’s in scope until it’s on a patched version.
• If you’re on PHP 8.1 or older, there is no fix coming from the PHP project itself — those versions have reached end of life. That’s a bigger conversation, and we’ve set it out separately in our guide to supported PHP versions.
• If your website is a static site (for example, one built with a static-output framework like Astro), there is no PHP running on the server to attack, so this particular release doesn’t apply to it. That’s a genuine architectural difference, not a reason to rebuild in a panic.

The four-step checklist

Work through these in order. For most business owners, steps 1 and 2 are the whole job — your host does the rest.

1. Find out which PHP version your site runs

If it’s a WordPress site, log in and go to Tools → Site Health → Info → Server — the PHP version is listed there. (We’ve written a short, non-technical walkthrough of how to check your PHP version if you’d like the detail.) For a custom or Laravel app, ask whoever built or maintains it.

2. Ask your host — and ask the right question

This is the step that matters most, because on most hosting your provider controls the PHP version, not you.

• Managed / fully-managed hosting (many WordPress-specialist hosts): the host usually patches for you. Ask them to confirm in writing that their servers are now running a patched PHP build (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or later for your branch). “We’re aware of it” is not the same as “we’ve patched it.”

  As one example of a host responding, SiteGround published a notice on 21 October saying it had rolled out server-level mitigation across its servers and that customers needed to take no action. If your host is a managed provider, ask whether they’ve done something similar and, ideally, whether they’re now on a patched PHP version.

• cPanel / shared hosting where you choose the version: you can usually switch PHP versions yourself in the hosting panel. Confirm a patched version is available and select it — but read step 3 first, because switching versions can surface compatibility issues.

• Your own server or VPS: nobody patches this unless you do. Update PHP from your Linux distribution’s packages now. PHP notes that Linux distributions and long-term-support vendors received the patches in advance, so an updated package should already be available — check your vendor.

3. Update — and test what customers actually use

Moving to a patched release within the same PHP branch (say 8.3.35 to 8.3.36) is normally a routine, low-risk update. Moving across branches (say 8.1 to 8.3) can break older plugins, themes or code, so treat that as a small project rather than a toggle: back up first, test on a staging copy, and check the things that earn you money — checkout, enquiry forms, logins — before and after. If an update throws the dreaded “There has been a critical error on this website”, we’ve written up how to recover.

4. Confirm it actually worked

After the dust settles, re-check the PHP version (step 1) to confirm you’re genuinely on a patched build, and that the site still behaves. “The host said they’d handle it” is worth verifying.

“Can’t I just change a setting instead of updating?”

Short answer: no. PHP’s release notes list a handful of interim settings that “reduce exposure to specific attack paths but do not make an installation safe,” and the project is unambiguous: “There are no complete mitigations, updating is the only safe choice.” Stop-gap settings are for buying a few hours while you arrange the real fix — not a destination. If someone tells you a config tweak means you don’t need to update, treat that with caution.

If you’re not sure where your site stands

Plenty of business owners genuinely don’t know what their website runs on, who’s responsible for patching it, or whether “the host handles it” is actually true. That’s normal, and it’s exactly the kind of thing worth nailing down before something goes wrong rather than after.

If you’d like a hand working out what your site runs, whether it’s patched, and who should be keeping it that way, get in touch and we’ll take a look. We work across WordPress, WooCommerce and custom PHP applications, and we’re happy to tell you plainly if there’s nothing to worry about.

Common questions

Is my website affected by the October 2026 PHP vulnerabilities? If it runs on PHP — which includes almost all WordPress, WooCommerce and Laravel sites — and it isn’t yet on PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later), then yes, it’s affected until it’s updated. Purely static sites with no PHP runtime are not affected by this release.

What does “remote code execution” actually mean? It means an attacker who can reach your website over the internet may be able to make your server run code of their choosing, without needing a password or an account. That can lead to defacement, data theft, spam, or the server being used to attack others. It’s the reason these two issues are rated 9.2 out of 10.

My host says they’ve “mitigated” it. Is that enough? Mitigation at the server level can reduce your exposure, and some hosts moved quickly to do exactly that. But PHP’s own position is that only an update is a complete solution. Ask your host to confirm they are running a patched PHP version, not only that they’ve applied a temporary rule.

I’m on PHP 8.1 (or older). What do I do? PHP 8.1 and earlier no longer receive security fixes from the PHP project. Your Linux distribution may backport a fix, but the real answer is to plan a move to a supported version — see our guide to supported PHP versions for 2026 and, if you’re on 8.2, what the 31 December 2026 end-of-life date means.

Do I need to rebuild my WordPress site because of this? No. This is a patch-and-move-on situation, not a rebuild trigger. There are good reasons some businesses eventually move off WordPress, and good reasons many stay on it — but a security release you can fix by updating isn’t one of them.