PHP Security Update: Patch the October 2026 RCE Flaws

On 21 October 2026 the PHP project shipped four security releases on the same afternoon, each with the same blunt line: there are no complete mitigations, and updating is the only safe choice. If you run a PHP website, that sentence is the whole story. This PHP security update fixes two critical vulnerabilities that the project says can allow unauthenticated remote code execution, and it applies to almost every way PHP serves web requests. Here is what changed, who is affected, and a practical plan for getting patched without breaking production.

What the October 2026 PHP security update fixes

According to the PHP security advisory on php.net, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two flaws:

• CVE-2026-109618 – remote code execution linked to out-of-memory handling. In short, PHP can be interrupted while internal request data is only partly set up.
• CVE-2026-109619 – remote code execution through stale global state, where internal data tied to a request can outlive the memory that backed it.

The pre-release notice rated both at CVSS v4.0 9.2. The advisory says every PHP installation serving web requests is affected, naming PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it singles out mod_php as the highest-risk setup.

Two other details matter for planning. First, the PHP 8.6.0 release candidate published the same day already includes both fixes. Second, on 26 October the Windows builds were refreshed (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1) to bundle a Brotli library update for a separate decompression bug; the PHP runtime versions themselves did not change.

Why "unauthenticated" is the word to notice

Most web vulnerabilities need something first: a login, a particular plugin, a misconfigured upload form. An unauthenticated remote code execution flaw in the runtime itself skips all of that. Your application code can be perfectly written and still be exposed, because the weakness sits underneath it.

Japan's Information-technology Promotion Agency (IPA) made the same point in its advance alert. It asked operators to inventory where PHP runs before the release landed, noted that some sites still run PHP versions that no longer receive support, and warned that attackers could move very quickly. At the time of its alert, IPA said it had not confirmed exploitation – but "not yet" is not a patching strategy.

Who needs to act, and how urgently

If you can answer "yes" to any of these, this applies to you:

• You host a WordPress, Laravel, Symfony or hand-built PHP site.
• You run a shop, booking system or admin panel on shared hosting with PHP.
• You ship a product or appliance that embeds PHP (IPA notes that products may include PHP without the owner realising).

The supported branches are clear. If you are on 8.2, 8.3, 8.4 or 8.5, there is an official release for you. If you are on PHP 8.1 or older, the advisory states plainly that those versions no longer receive updates from the PHP project. Source backport branches were published for 7.4, 8.0 and 8.1, but applying them means building PHP yourself – realistic for a platform team, not for most small businesses.

And a date for your diary: the advisory confirms PHP 8.2 reaches end of life on 31 December 2026. If you upgrade to 8.2.35 today, you have bought yourself about two months.

A practical patching plan

This is the order I would work through for a typical PHP and MySQL site – the kind of system behind a marketplace like AutoMarketPro or a restaurant ordering platform like The Miner's Spice.

1. Find every PHP runtime you own

Run php -v on each server, and check the version your web server actually uses (a quick phpinfo() page that you delete straight afterwards, or your hosting control panel). The CLI and the web SAPI can differ. Don't forget staging boxes, old subdomains, Docker base images and that forgotten WordPress install on a marketing microsite.

2. Decide: patch in place or upgrade a branch

• On 8.2–8.5: move to the patched point release on the same branch. Point releases are designed to be low-risk.
• On 8.2 specifically: patch now, then schedule the move to 8.3 or newer before the end of December.
• On 8.1 or older: treat this as an upgrade project, starting today. Isolate the site behind a web application firewall and restrict admin areas by IP while you work.

3. Patch, restart, verify

Install the update from your distribution, hosting panel or official image, then restart PHP-FPM or Apache so the old processes are gone. Confirm the new version number is what your web server reports, not just the command line. If you build containers, rebuild from the updated base image rather than patching a running container.

4. Only if you truly cannot patch today

The advisory lists temporary configuration changes for each CVE – for example, turning off session.upload_progress.enabled and restarting workers. Treat these as a bridge measured in hours or days. The PHP project itself says they are not complete mitigations, and a separate informational note on 23 October covered a further session upload progress issue, which is another reason to update rather than tune.

The common mistake: patching the package, not the process

The error I would watch for most is updating the PHP package and assuming you are done. Long-running PHP-FPM workers and Apache children keep the old code in memory until they restart. The fix is simple: restart the service, then check the version your web server reports via a live request, not the command line.

A close second is over-trusting managed hosting. Shared hosts usually patch for you, but many let customers pin an older PHP version per site. If you pinned 8.1 three years ago for a plugin, you are still on 8.1.

Decision checklist

• Inventory every server, container and hosting account running PHP
• Note the web-facing version, not only the CLI version
• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or newer)
• Restart PHP-FPM, Apache or your PHP process manager
• Verify the version through a live web request
• Rebuild container images from patched bases
• Plan the 8.2 to 8.3+ upgrade before 31 December 2026
• Put any 8.1-or-older sites into an upgrade project with interim isolation

Key takeaways

• Two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) can allow unauthenticated remote code execution, according to the PHP project.
• Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP 8.1 and older receive no official fix.
• Configuration workarounds are temporary; updating is the only safe choice.
• Restart PHP processes after updating, and verify the version your web server actually runs.
• PHP 8.2 reaches end of life on 31 December 2026, so plan the next upgrade now.

FAQ

Is my WordPress site affected by this PHP vulnerability?

Very likely, if it runs on an unpatched PHP version. The flaws are in PHP itself, so the CMS or plugins you use don't change the exposure. Check your host's PHP version and update to a fixed release.

Can I just change PHP settings instead of updating?

Only as a short stopgap. The PHP advisory lists interim settings but states there are no complete mitigations. Plan to update as soon as you can.

What should I do if I'm stuck on PHP 7.4 or 8.1?

Those branches no longer receive official updates. Source backports exist, but most teams are better served by upgrading to a supported branch, with temporary isolation of the site while the upgrade happens.

If you run a PHP and MySQL site and you're not sure which version it's on, or what an upgrade would break, that's exactly the kind of work I do. Take a look at my web systems and security and e-commerce services, or get in touch and we can work out a safe path to a patched, supported setup.