The PHP security team will ship an emergency release today, Wednesday, October 21, 2026, at 14:00 UTC (10:00 AM Eastern), fixing two critical vulnerabilities that are both rated 9.2 under CVSS v4.0. PHP has not yet said which versions are affected or where the bugs live, but researchers describe them as remote code execution flaws in the PHP core. For system administrators, that means an afternoon of inventory, package updates and service restarts on every server that runs PHP.

The key facts about the critical PHP vulnerabilities in 20 seconds

PHP releases fixes for two CVSS 9.2 flaws today at 14:00 UTC.
Affected and fixed versions will be published with the release.
The fix is in the interpreter, so every server and container needs updating.
Temporary mitigations reduce exposure but are not validated against these bugs.

The advance notice came on October 20, hours after details leaked ahead of the embargo through a now-deleted Hacker News post. The identifiers circulating, CVE-2026-109618 and CVE-2026-109619, come from that leak; PHP has not cited them. As BleepingComputer reported, watchTowr CEO Benjamin Harris said the flaws are real and are “understood to affect PHP versions 5, 6, 7, and 8”, although PHP has not confirmed the scope. watchTowr believes it has reproduced CVE-2026-109618 and said it had not observed exploitation in the wild. A Spanish-language summary of what is confirmed and what is not is available on opensecurity.es.

Inventory: where PHP runs and which version

The first job is knowing what needs updating. PHP tends to live in more places than the asset inventory shows: web servers, hosting panels, containers, CI images, internal tools and exposed development machines. On Debian, Ubuntu and Red Hat family systems, these commands give a first picture:

# CLI interpreter version
php -v

# Installed packages (Debian/Ubuntu)
dpkg -l 'php*' | grep ^ii

# Installed packages (RHEL, Rocky, Alma, Fedora)
rpm -qa 'php*'

# Running PHP-FPM services
systemctl list-units --type=service | grep -i phpCode language: PHP (php)

Do not rely on php -v alone. Several versions can coexist on the same host, for example with Ondřej Surý’s repositories on Debian and Ubuntu or Remi’s on RHEL, and the CLI version is not necessarily the one PHP-FPM or mod_php is running. Containers need to be checked one by one:

docker ps --format '{{.Names}} {{.Image}}'
docker exec CONTAINER_NAME php -vCode language: JavaScript (javascript)

Update as soon as packages land

Once PHP publishes the new releases, timing depends on where your packages come from. Upstream builds and repositories such as Surý or Remi usually follow the official release closely. If you rely on distribution packages, watch their security advisories (Debian Security, Ubuntu Security Notices, Red Hat), because long-term support distributions often backport fixes to the version they ship even when that branch is no longer supported upstream. That matters for servers running PHP 8.1 or older from an LTS distribution, since upstream only provides security fixes for the 8.2, 8.3, 8.4 and 8.5 branches.

# Debian/Ubuntu
apt update
apt install --only-upgrade 'php8.3*'
systemctl restart php8.3-fpm

# RHEL and derivatives
dnf upgrade 'php*'
systemctl restart php-fpm

# With mod_php, restart Apache
systemctl restart apache2   # or httpdCode language: PHP (php)

Without a restart, PHP-FPM or Apache workers keep running the old binary in memory, so the update has no effect. Containers must be rebuilt on the patched base image and redeployed; updating inside a running container does not count. Custom PHP builds need recompiling. Systems on unsupported branches with no distribution backports, such as hand-installed PHP 7.x or old images, will not get an official fix, and the only real way out is migrating to PHP 8.2 or later.

How to mitigate the risk until you can patch

None of the following replaces the update, and with no official technical details yet, none has been validated against these specific bugs. The goal is to shrink the attack surface and limit damage during the hours when a server cannot be patched. Test each change in staging first.

1. Disable session upload progress

GMO Flatt Security believes the flaw is linked to PHP’s session upload progress feature, which is enabled by default, and suggests disabling it. The company says it cannot guarantee this stops the attack, and other researchers believe one of the two flaws sits in multipart form parsing, which this setting would not cover. It can be applied globally or per PHP-FPM pool:

; php.ini (CLI, FPM or Apache, depending on the SAPI)
session.upload_progress.enabled = 0

; PHP-FPM pool, e.g. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

After reloading, check the effective value in the SAPI that actually serves requests, not just the CLI, for example with a protected temporary phpinfo() page or php-fpm8.3 -i. Few applications depend on the feature, although some upload progress bars may stop working.

2. Restrict multipart requests to where they are needed

If the bugs are in upload and multipart handling, as researchers suggest, limiting where those requests are accepted reduces exposure. In many applications only a handful of paths need to receive files. For applications that never handle uploads, file_uploads = Off in their pool is worth considering, bearing in mind it is not confirmed to avoid the flaw. In nginx, a simple approach is to check at server level, so the rule also applies to requests for .php files:

# Inside the server block: reject multipart except under /uploads/
set $block_multipart 0;
if ($http_content_type ~* "multipart/form-data") {
    set $block_multipart 1;
}
if ($uri ~ "^/uploads/") {
    set $block_multipart 0;
}
if ($block_multipart) {
    return 403;
}Code language: PHP (php)

This is an aggressive measure that can break forms, admin panels or plugins, so it must be tailored to each application. On WordPress, for instance, media uploads go through /wp-admin/async-upload.php and other admin paths, which would need to stay open, ideally only for trusted IP addresses.

3. Filter the upload progress field at the WAF

The upload progress feature is triggered when a multipart request includes a field named after session.upload_progress.name, which defaults to PHP_SESSION_UPLOAD_PROGRESS. If you run ModSecurity or another self-managed WAF, you can block requests containing it. This is not an official rule and would not cover the possible second flaw:

SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS" "id:1026101,phase:2,deny,status:403,log,msg:'PHP upload progress field blocked'"Code language: CSS (css)

4. Limit what an attacker can do

If someone does get code execution, the damage depends on the privileges of the process. Make sure each site has its own PHP-FPM pool running as an unprivileged user, that open_basedir restricts file system access and that the PHP user cannot write outside the directories it needs. Disabling functions such as exec, shell_exec, system, passthru, proc_open and popen via disable_functions makes typical web shells harder to use, although memory corruption bugs may bypass it. Blocking outbound connections from the PHP-FPM user at the firewall, except those the application needs, also makes it harder to pull tools or exfiltrate data.

5. Isolate, monitor and have a rollback plan

CERT-EU, the cybersecurity service for EU institutions, recommends considering isolating internet-facing PHP applications from public networks if patching is not immediately possible, for example by restricting access via VPN or IP allowlists. To spot a possible compromise, watch for new PHP files in upload and cache directories, unexpected child processes under PHP-FPM and unusual outbound connections:

# PHP files created or modified in the last hour
find /var/www -name '*.php' -mmin -60 -ls

# Processes running as the PHP-FPM user
ps -u www-data -fCode language: PHP (php)

Keep access and PHP-FPM logs, ideally shipped off the server, in case an investigation is needed later. Before updating, take a backup or a VM snapshot so you can roll back if the new release breaks something. It is another reminder that, as we wrote earlier this year, no ecosystem is safe.

6. If your sites sit behind Cloudflare

On October 21, 2026, Cloudflare pushed an emergency update to its Cloudflare Managed Ruleset, the managed rules for its web application firewall (WAF), adding four new rules named “Generic Rules – Anomalous Execution” (1 through 4) to detect anomalous request patterns. Rules 1 and 3 block by default; rules 2 and 4 only log. Cloudflare does not tie these rules to the PHP vulnerabilities or explain what they detect, so there is no confirmation they cover this case, but they add another layer while you patch:

Make sure the Cloudflare Managed Ruleset is deployed on each zone: go to Security > Settings, filter by “Web application exploits” and turn on “Cloudflare managed ruleset”. It is only available on Pro, Business and Enterprise plans; the Free plan gets the Free Managed Ruleset, which the release note does not mention.
Review the four rules under Security rules, on the managed ruleset rule, using “Browse rules”, and consider switching the two log-only rules to block once security events show no false positives.
Watch security events to see whether these rules fire against your PHP applications.
Lock down the origin so the server firewall only accepts HTTP and HTTPS from Cloudflare’s published IP ranges, because the WAF never sees requests that hit the server IP directly.

This works alongside the custom ModSecurity rule from step 3. Neither replaces the PHP update.

As of this morning, neither PHP nor the companies analyzing the case had reported real-world attacks. Researchers expect exploitation attempts shortly after the release, once the patched code can be compared with the old one, so the first hours after 14:00 UTC are the ones that matter most.

Frequently asked questions

When is the PHP security release?

Today, October 21, 2026, at 14:00 UTC (10:00 AM Eastern). PHP may release earlier if details become public or active exploitation is detected.

Which PHP versions are affected?

PHP has not said yet and will publish affected and fixed versions with the release. watchTowr told BleepingComputer it understands PHP 5, 6, 7 and 8 to be affected, but this is not officially confirmed.

Is updating the PHP packages enough?

You also need to restart PHP-FPM or Apache, because running workers keep using the old binary. Containers must be rebuilt and redeployed.

How can I mitigate the PHP flaws before patching?

Disable session.upload_progress, restrict multipart requests to the paths that need them, filter the PHP_SESSION_UPLOAD_PROGRESS field at the WAF or rely on the Cloudflare emergency WAF rules, reduce PHP-FPM privileges and isolate exposed applications. None of these replaces the update.

Sources:

TL;DR (AI Generated)

PHP has not yet said which versions are affected or where the bugs live, but researchers describe them as remote code execution flaws in the PHP core.

As BleepingComputer reported, watchTowr CEO Benjamin Harris said the flaws are real and are "understood to affect PHP versions 5, 6, 7, and 8", although PHP has not confirmed the scope. watchTowr believes it has reproduced CVE-2026-109618 and said it had not observed exploitation in the wild.

Make sure each site has its own PHP-FPM pool running as an unprivileged user, that restricts file system access and that the PHP user cannot write outside the directories it needs.

Basic summary