The October 2026 PHP security release: what to check on your WordPress site today

On October 21, 2026, the PHP project shipped an emergency security release for two critical flaws, CVE-2026-109618 and CVE-2026-109619. The PHP project's own advisory says they can allow unauthenticated remote code execution, which means an attacker who has never logged in can run their own code on your server. Both are rated 9.2 out of 10 on the CVSS v4.0 scale.

If you run a WordPress site, this matters to you, but probably not the way the headlines suggest. The bug is in PHP, the language your server uses to run WordPress. It is not in WordPress itself, and no plugin or WordPress update fixes it. Whether your site is exposed depends on one thing: has whoever runs your server installed the fixed version of PHP yet? Here is how to find out, in about fifteen minutes, without touching any code.

What is affected and what fixes it

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to the PHP security advisory for CVE-2026-109619 on GitHub, every version before those is affected. The advisory says the researchers confirmed code execution against the two most common ways PHP is wired into a web server (mod_php and PHP-FPM). The PHP project rates the risk highest for mod_php, where it says a single request can trigger the attack before any WordPress code runs.

The bigger problem is older PHP. The PHP supported versions page shows that only 8.2 and newer still get security fixes from the project; 8.1 and everything before it are end of life. For this release the PHP team published minimal patches for 7.4, 8.0 and 8.1 that hosts and Linux distributions can build from, but nobody will hand those to you automatically. If your site runs on 8.1 or older, assume you are exposed until your host tells you otherwise in writing.

Step 1: find your PHP version

Log in to WordPress and go to Tools, then Site Health, then the Info tab. Expand the Server section. WordPress's Site Health documentation describes it: this section lists your server setup, including the PHP version. Write down the full number, all three parts (8.3.36, not just 8.3).

Read the number this way:

• 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher within the same branch: you have the fix. Move on to Step 4 only if you want the longer view.
• 8.2 to 8.5, but a lower last number: you are on a supported branch that has not been updated yet. Go to Step 2 today.
• 8.1 or older: go to Step 2 today, and plan Step 4 this month.

One caveat. Some hosts and Linux distributions patch the code without changing the version number, so an older number does not always mean you are unpatched. That is why the next step is asking, not guessing.

Step 2: ask your host, in writing

Most small-business sites sit on shared or managed hosting, where the host owns PHP and you cannot update it yourself. Even within one company the answer differs by plan. On October 21, GoDaddy said it had patched every PHP version on its Managed Hosting for WordPress, while its regular Web Hosting servers were waiting on patched packages from a vendor and had interim protections in place. VPS customers manage their own PHP and were told to update it themselves.

So open a support ticket and ask three questions. You can paste this:

1. Is the PHP running my site patched for CVE-2026-109618 and CVE-2026-109619? If yes, on what date?
2. If not, when will it be, and what protections are in place until then?
3. My site shows PHP [your version]. Is that version still receiving security fixes from you, and if not, can you move me to 8.3 or newer?

A good host answers all three in a day. If the reply is vague or you hear nothing, treat that as an answer about the host, not just about this bug.

Step 3: if you run the server yourself

If you are on a VPS or your own server, nobody is coming to do this for you. Update PHP to the fixed release through your package manager or control panel (cPanel users can do it in WHM), then restart every PHP worker and the web server so the old code is no longer in memory. Check staging copies and old test sites too; an exposed staging server is still a server.

If you cannot update today, the PHP project lists interim settings in its advisory. The simplest one for most WordPress sites is turning off upload progress tracking (session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart). The advisory is blunt that these settings "do not make an installation safe." They buy hours, not weeks.

While you are in there, look at your logs. Patchstack, a WordPress security company, lists warning signs: unusual file-upload requests followed by memory-limit errors or HTTP 500s, malformed PHPSESSID cookies, and PHP workers restarting for no clear reason. Patchstack reported attack attempts on release day, and its later updates described mostly probing rather than confirmed break-ins, so a clean log today is common. Details of the flaws leaked the day before the release, which is why waiting a week is the wrong plan.

Step 4: if you are on PHP 8.1 or older

Getting off an end-of-life version is a bigger job than a patch, and it is the one that keeps you out of the next headline too. Ask your host to move the site to PHP 8.3 or 8.4 on a staging copy first. Then click through every page and form on staging, because old themes and plugins are the usual reason a site was left on old PHP in the first place. If something breaks, update or replace that plugin before you switch the live site.

If the upgrade turns up a pile of abandoned plugins and a theme nobody has touched in years, that tells you something worth knowing about how the site is being looked after.

The longer question: who patches your site?

Every website runs on software that will have a serious bug someday. That includes the sites we build. We build on Next.js and run them on Node.js, with no PHP and no plugins, so this particular release does not touch them. But Node.js has its own security releases, and pretending otherwise would be the kind of claim you should not trust from anyone.

The difference that matters is ownership. On a typical small-business WordPress site, the runtime belongs to the host, the plugins belong to a dozen different authors, and the owner finds out about a problem from a news story. On the sites we run, we patch the runtime and dependencies ourselves as part of the monthly service, and the client does not have to ask. That is the question to ask any web provider: when the next one of these lands, who does the work, and how fast do you hear about it?

WordPress is still the right choice for plenty of businesses, especially ones with a team that publishes daily in its editor or relies on a plugin with no good replacement. If that is you, keep it, and put a host and a maintenance plan behind it that answer those three questions in a day.

If you are not sure where your site stands, send us its address. We will tell you what we can see from the outside, such as your host and whether your server publicly reports an old PHP version, at no charge. We only look at what any visitor can see and never test your site for the flaw itself.

Sources

• Security advisory: Critical remote code execution vulnerabilities, update now, The PHP Group (October 21, 2026)
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618), PHP security advisory on GitHub
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), PHP security advisory on GitHub
• Supported versions, The PHP Group
• Site Health screen, WordPress.org documentation
• Important PHP security update: what website owners need to do, GoDaddy
• Major security alert: PHP vulnerable to critical RCE, attacks ongoing, Patchstack (October 21, 2026)