PHP Emergency Patch: Why Server Updates and Monitoring Matter This Week

Updated Oct 23, 2026

Since this post went up on October 20, the PHP team has released its fixes and published the details. Here is where things stand.

The fixed versions are out. On October 21, PHP released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which fix the two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it considers the risk highest for mod_php. The changes are listed in PHP's ChangeLog for 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP lists some temporary measures for people who can't update right away, but says only an update is a complete solution.

Linux packages. PHP says Linux distributions and LTS vendors received the patches in advance, so check with your vendor or host for updated packages.

Older versions (7.4, 8.0 and 8.1). PHP 8.1 and older no longer receive regular updates from the PHP project. Because of the severity, though, the PHP security team provided minimal source backports for PHP 7.4, PHP 8.0 and PHP 8.1 to help people who build PHP from source or don't have an LTS vendor. Some distributions and LTS vendors also provide backported fixes. That buys time, but the longer-term answer is still moving to a supported version.

A separate, informational advisory (October 23). PHP also published an informational advisory about session upload progress, tracked as CVE-2026-115560, which it describes as "an unlikely RCE vector." It can only occur under an unusual combination of configuration and application code: an application sets session.serialize_handler to php_binary or php_serialize in its configuration, then switches it to php at runtime with ini_set() before calling session_start(), and session upload progress is still enabled. Applications that never change the serialize handler at runtime can keep the feature enabled.

PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. That same setting was already listed on October 21 as a mitigation for CVE-2026-109619 in GHSA-6wmf-4rv5-p3rp. Per PHP's October 21 advisory, set it in php.ini, an FPM pool or server configuration that applies before request parsing (not ini_set() or FPM .user.ini), then restart every PHP worker. If you applied it on October 21, PHP says to keep it in place and no further action is needed. PHP is handling this one in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

In short: make sure your server is running one of the October 21 versions (or your vendor's patched package), and if you haven't set session.upload_progress.enabled=0, ask whether it makes sense for your setup until PHP's next regular release.

If your website runs on PHP, this week's news is worth five minutes of your time. No panic needed. Just a plan.

What happened

On Tuesday, October 20, the PHP security team told administrators to get ready for emergency security updates. The fixes were scheduled for Wednesday, October 21, at 14:00 UTC (10:00 AM Eastern), and PHP released them that day. They address two critical vulnerabilities, each rated 9.2 under CVSS v4.0.

According to BleepingComputer, information about the flaws reportedly leaked before the planned disclosure. Researchers at watchTowr told BleepingComputer the two bugs, tracked as CVE-2026-109618 and CVE-2026-109619, are remote code execution flaws believed to affect PHP versions 5, 6, 7 and 8. watchTowr rates both a CVSS 10.0. The PHP team had also said it might release earlier if details went public or if exploitation showed up in the wild.

As of October 20, watchTowr said it hadn't seen these flaws exploited in the wild. On October 21, the PHP team published its security advisory with technical details, who is at risk and the fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Who's affected

PHP sits under a huge slice of the web. If your site runs on any of these, PHP is doing the work behind the scenes:

• WordPress
• Drupal
• Joomla
• Magento
• Custom PHP apps, client portals and older in-house tools

PHP's advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. If you run PHP, this one is on your list.

Why server updates matter

Most people think about website updates as plugins and themes. Those matter. But underneath your site is the server: the operating system, the web server and PHP itself. When PHP ships a fix, someone has to actually install it on the server where your site lives. A patch that's been released but not applied doesn't protect anybody.

Here's the part that catches people. PHP normally only fixes branches it still supports. Right now, per php.net, that's PHP 8.2, 8.3, 8.4 and 8.5. Anything older, like 7.4, 8.0 or 8.1, is end of life and no longer receives regular updates from the PHP project. Because of the severity, the PHP security team did provide minimal source backports for 7.4, 8.0 and 8.1 for people who build from source or don't have an LTS vendor, and some distributions and LTS vendors offer their own backported fixes. That's a stopgap, not a support plan. And PHP 8.2 only has security support through December 31, 2026, so it's on the clock too.

I've been fixing hacked sites and running servers since the early 1990s, and the pattern hasn't changed much. The sites that turn into cleanup jobs usually aren't the ones that got hit by something brand new. They're the ones that were running something old that nobody was watching.

Why monitoring matters

Patching closes the door. Monitoring tells you if someone's been trying the handle.

Once details on a flaw like this go public, as they now have, people start scanning for servers that haven't been patched. That's normal and it's predictable. Active monitoring on your web servers is how you catch it: unusual requests in the logs, unexpected processes, new files showing up where they shouldn't, or a sudden spike in errors. If something is being attempted or exploited, you want to know today, not when a customer calls about a strange redirect.

Updates and monitoring work as a pair. One without the other leaves a gap.

What to do this week

1. Check your PHP version. Your hosting control panel usually shows it. In WordPress, go to Tools, then Site Health, then Info, then Server.
2. Patch now. The updates were released on Wednesday, October 21. Take a backup, then move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package.
3. Confirm your host is patching. If you're on shared or managed hosting, ask your host directly whether and when they're applying the PHP update. Get the answer in writing if you can.
4. Check the session upload progress setting. PHP suggests session.upload_progress.enabled=0 until its next regular bugfix release. Set it in php.ini or the FPM pool configuration, not with ini_set() or .user.ini, and restart every PHP worker. If you already set it on October 21, keep it.
5. Plan your way off end-of-life PHP. If you're on anything older than 8.2, the regular releases don't cover you. Ask your distribution or LTS vendor about backported fixes (PHP also published minimal source backports for 7.4, 8.0 and 8.1), and plan the upgrade. Moving up a version can break old plugins or custom code, so test it on staging first. Don't flip it on a live store and hope.
6. Watch your logs and monitoring. Keep an eye out for unusual activity over the next few weeks, especially now that technical details are public.

If you can't update right away, PHP's advisory lists measures that reduce exposure to specific attack paths, though PHP says only an update is a complete solution. For the general approach to hardening while you wait on a patch, see my companion post.

Related post: Before the Patch: A Practical Hardening Checklist When a Fix Isn't Out Yet

Watch: PHP Before The Fix

How DTS can help

This is the kind of work our server maintenance and care plans are built for: applying updates on a schedule you can point to, watching the servers, and having a plan for the day an emergency patch drops. Our WordPress Care Plans are published at $149, $249 and $399 a month, and every tier includes updates, daily backups and uptime monitoring. If you'd rather have someone own this for you, take a look at our WordPress maintenance page or give us a call.

And if you think your site has already been compromised, start with our WordPress incident response hub. Please don't wipe anything yet.

Sources: BleepingComputer, October 20, 2026; PHP security advisory, October 21, 2026; PHP informational advisory, October 23, 2026