The October 2026 PHP Vulnerability: What It Means for Your WordPress Site
Two flaws in PHP, both rated 9.2 out of 10, let an attacker run code on a web server without logging in. The fix shipped on 21 October 2026. A fully updated WordPress site stayed exposed until the server underneath it was patched.
That’s the whole story. The details follow, in plain words.
What happened
| 20 Oct 2026 | Details leaked a day before the planned disclosure |
| 21 Oct 2026 | PHP released emergency fixes: 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| CVE numbers | CVE-2026-109618, CVE-2026-109619 |
| Severity | 9.2 out of 10, both |
| Login needed to attack | No |
| WordPress update needed | None. There is no WordPress fix for this, because the flaw isn’t in WordPress |
Cloudflare started blocking exploit attempts in the early hours of 21 October, before the flaws were public, and switched its firewall rules on for every plan, the free one included. Palo Alto Networks counted more than 22 million internet-facing PHP servers that were potentially exposed.
What the flaw does
PHP is the engine that builds every page of a WordPress site. These flaws sit in the engine. Not in WordPress, not in a plugin, not in your theme.
“Remote code execution” means an attacker’s code runs on your server with the web server’s permissions. From there they can read the database, plant a hidden backdoor, send spam from your domain or redirect your visitors somewhere else.
PHP rates the risk highest on servers running Apache with mod_php, where the attack can fire before WordPress even loads. That’s why a security plugin inside WordPress doesn’t help. The attack arrives before the plugin runs.
Why updating WordPress did nothing
A WordPress site is a stack of layers. Each layer has a different owner and a different update day.
| Layer | Who updates it |
|---|---|
| Your content | You |
| Theme and plugins | You, or whoever maintains the site |
| WordPress core | You, or auto-update |
| PHP | The hosting company |
| Server | The hosting company |
The flaw was in the fourth row. On shared hosting you can’t touch that row. You wait for the host. At least one hosting company took its managed WordPress platform offline as a precaution until the patch was installed.
Who is still exposed
- Sites on a host that hasn’t installed the fix yet
- Sites on PHP 8.1 or older. PHP released no official fix for these, only minimal source-code patches for 7.4, 8.0 and 8.1, meant for people who compile PHP themselves
- Sites stuck on an old PHP because one old plugin or theme breaks on a newer version
Check your own version in 30 seconds: WordPress admin, then Tools → Site Health → Info → Server.
| PHP branch | Safe from |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 and older | No official fix. Upgrade or restrict access |
You may see one temporary setting recommended,
session.upload_progress.enabled = 0. It closes one of the two attack
paths, not both. It’s a stop-gap, not a fix.
The second critical hole in five weeks
In September, WordPress core had its own critical flaw: CVE-2026-87902, also rated 9.2. It affected every version from 4.7.0 through 7.1.1, was fixed in 7.1.2, and was being actively exploited within days. Separate bug, separate fix.
Two critical holes in two different layers, five weeks apart. That isn’t bad luck. It’s what a stack with five owners looks like.
The real problem: you rent someone else’s stack
WordPress runs about 40% of all websites. One exploit works on millions of sites at once, which is why attackers move within hours of a leak. They don’t need to know your business. They scan, and your site answers.
Popularity is the price. You get a cheap, familiar platform. You also get the biggest target on the internet, and a patch schedule you don’t control.
What a bespoke build changes, and what it doesn’t
| WordPress site | BAD build | |
|---|---|---|
| What runs on each visit | PHP rebuilds the page | Websites: static files, nothing runs. Platforms: TypeScript on Node |
| Extra code | Plugins from many different authors | A short list of libraries, chosen per project |
| The same exploit works on | Millions of sites | Your site only, unless it uses the same library |
| Who patches | The host, the plugin authors and you | One team that wrote the code |
| Can you see the full list of parts | Rarely | Yes, it’s in the repository |
The limits, stated plainly:
- A custom site is still software. It needs updates.
- Node, its frameworks and npm packages have critical flaws too.
- BAD builds run on Cloudflare and Railway. Both are outside providers, and both have had outages.
What changes is the size of the list and who owns it. Fewer parts, one team that knows every one of them, and no PHP layer inherited from a host.
What it costs
A cheap WordPress site is cheaper on day one. After that, the question is who pays for upkeep: updates, monitoring, fixing what breaks.
Add it up over 36 months.
| Formula | Example | |
|---|---|---|
| WordPress | Build + (monthly upkeep × 36) | €800 + (€40 × 36) = €2,240 |
| BAD Full Website + Basic Care | €1,490 + (€49 × 36) | €3,254 |
| Gap | €1,014, about €28 a month |
The WordPress numbers are an example. Put your own quote into the formula, and ask for the monthly upkeep figure in writing.
If nobody pays for upkeep, the WordPress column drops to the build price, and nobody patches anything. That was the situation for a lot of sites this week.
The gap buys fewer layers, one team accountable for all of them, and no mass-scanned platform under your site. One cleanup after a hack, plus a few days offline in booking season, can eat €1,014 fast. Every BAD price is on the services page, and what a website costs in Croatia breaks them down.
Questions to ask your developer
- Which PHP version does my site run on, and who updates it? Good answer: a version number at or above the table above, and a name.
- Was my site patched against CVE-2026-109618 and CVE-2026-109619? When? Good answer: a date. Bad answer: “WordPress is up to date.”
- How many plugins are installed, and when was each last updated? Good answer: a list.
- What happens when a plugin’s author stops maintaining it? Good answer: a replacement plan, not silence.
- Where are backups stored, how old is the newest, and how long does a restore take? Good answer: not on the same server as the site, with a number of hours.
- How will I find out if the site is hacked? Good answer: monitoring, and a named person who gets the alert.
- What does a cleanup cost, and who pays? Good answer: a price, or a clause in the contract.
- If I leave, do I get the code, the database and the domain in my name? Good answer: yes, in writing.
If the answers are vague, that’s an answer too.
Want a second opinion on what your site runs on? The 15-minute call is free.