Blog
The critical PHP fix of October 2026: what it means for your WordPress site
On 21 October 2026, the PHP project released an urgent security update for the language that runs every WordPress site. It fixes two critical flaws that could let an attacker run code on a web server without logging in. If you own or manage a WordPress site, here’s what happened, how to check whether your site is protected, and what to do if it isn’t.
The short answer
- The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your site runs one of these or newer, it’s patched.
- Check your site’s PHP version in WordPress under Tools › Site Health › Info › Server.
- On shared or managed hosting, your host applies the fix, not you. If your version isn’t patched yet, ask them when it will be.
- If your site runs PHP 8.1 or older, no official fix is coming. Plan an upgrade to a supported version now.
What happened
PHP’s security team gave a day’s notice on 20 October, then published the fixes on 21 October. The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 out of 10 for severity. PHP’s advisory says they can allow unauthenticated remote code execution: an attacker with no account on your site could make the server run their own code.
In simple terms, one flaw is triggered when PHP runs out of memory part-way through reading an incoming request, often through file upload handling. The other involves data from one request being left behind and wrongly reused by the next request on the same server process.
Some security companies reported early attack attempts around the release, while others had seen no confirmed attacks. Either way, details are now public, so it’s safest to treat this as urgent.
Why this matters for WordPress sites
PHP sits underneath WordPress. Every page view, form submission and admin action runs through it. That means a flaw in PHP itself sits below WordPress, your theme, your plugins and any security plugin you use.
PHP’s advisory says every setup that serves web pages is affected, including PHP-FPM, Apache with mod_php, LiteSpeed and php-cgi. The risk is highest on Apache with mod_php, where PHP demonstrated an attack that works before any website code runs. On those servers, nothing in WordPress can stand in the way. The fix has to happen at the server level.
Is your site affected?
Find your site’s PHP version, then look it up here.
| Your PHP version | Fixed in | What to do |
|---|---|---|
| 8.5 | 8.5.12 | Make sure you’re on 8.5.12 or newer |
| 8.4 | 8.4.27 | Make sure you’re on 8.4.27 or newer |
| 8.3 | 8.3.36 | Make sure you’re on 8.3.36 or newer |
| 8.2 | 8.2.35 | Update to 8.2.35, and plan a move to 8.3 or newer: 8.2 stops getting security fixes on 31 December 2026 |
| 8.1 or older | No official release | Upgrade to a supported version (see below) |
How to check your PHP version
- Log in to WordPress and go to Tools › Site Health.
- Open the Info tab and expand Server.
- The PHP version line shows the version your site is actually running.
You can also see it in your hosting control panel, usually under a “PHP version” or “PHP selector” setting. If you manage the server yourself, check the version the website uses rather than running php -v on the command line: the two can be different builds.
What to do
On shared or managed hosting (most WordPress sites): PHP is installed and updated by your host, and you can’t install the fix yourself. Some hosting platforms had patched packages ready within minutes of the release, but each host decides when to roll them out. If your control panel offers a patched version, select it. If it doesn’t, open a support ticket and ask when they’ll apply PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. These are small point releases within the same version, so they shouldn’t break your site.
On your own server or VPS: install the updated PHP packages from your operating system or package source, then fully restart PHP so every worker process loads the fix: restart PHP-FPM, or fully stop and start Apache if it runs PHP through mod_php (a graceful restart isn’t enough). Note that Linux distributions such as Ubuntu and Debian often include security fixes without changing the version number, so check the package changelog or security notice rather than the version alone.
If you can’t update straight away: PHP lists interim settings that reduce some risk, such as turning off session.upload_progress.enabled and lowering post_max_size. They only work when set in php.ini or the server configuration (not in a .user.ini file or a plugin), and they need a full PHP restart. PHP is clear that they don’t make a server safe. Treat them as a stopgap for a day or two, and ask your developer or host before changing server settings.
If your site runs PHP 8.1 or older
PHP 8.1 and earlier no longer get updates from the PHP project, so there’s no official patched release to install. The PHP team published source code fixes for 7.4, 8.0 and 8.1, but those are for people who build PHP themselves; they aren’t something a normal hosting control panel offers. Some Linux vendors provide their own patched packages, so it’s worth asking your host. The real fix is moving to a supported version.
WordPress still runs on older PHP versions, which is why many sites never get moved. WordPress itself recommends PHP 8.3 or newer. Before switching, I’d suggest:
- Take a full backup of files and database.
- Test the site on a staging copy with PHP 8.3 or 8.4, checking the theme, plugins, forms, checkout and any custom code.
- Fix or replace anything that breaks, then switch the live site and check it again.
Most sites on recent plugins move without trouble. Older custom themes and abandoned plugins are where problems usually show up.
If I already look after your site
If your site is on one of my maintenance or hosting plans, you don’t need to do anything. I’m checking every site I look after, and I’ll contact you directly if yours needs a PHP update or upgrade.
How I can help
If this all sounds like more than you want to deal with, here are three ways I can take it off your hands:
- Free PHP security check. I check your site’s PHP version, whether the fix is applied, and whether an upgrade is needed. You get a plain-English answer within one business day.
- PHP upgrade for older sites. For sites on PHP 8.1 or older, I test your site on a staging copy with a supported version, fix what breaks, and switch the live site over. You get a fixed quote before any work starts, with no hidden fees.
- Ongoing care, so you never have to think about this again. My website maintenance and care plans cover updates, backups, security and alerts like this one, handled for you.
Also this week: the UpdraftCentral breach