Two critical PHP flaws, patched today: what WordPress and server operators must do now

On 20 October a post on Hacker News claimed that two remote code execution flaws in PHP, rated CVSS 10, would be disclosed on 22 October. The post was removed, but screenshots spread, a researcher on X named the reserved identifiers CVE-2026-109618 and CVE-2026-109619, and the security firm watchTowr confirmed publicly that the flaws are real, that it did not discover them, and that it had reproduced one of them. That evening the PHP security team published an advance notice on php.net: a security release for Wednesday 21 October at 14:00 UTC, addressing two critical vulnerabilities, both rated CVSS v4.0 9.2. The release came out on time, with a security advisory on php.net and a GitHub advisory for each flaw.

PHP’s advisory describes the two flaws in a few sentences each. CVE-2026-109618, which PHP calls remote code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while its internal request data is only partly initialised, and request cleanup then treats the invalid data as valid. CVE-2026-109619, remote code execution via stale global state: internal state that belongs to one request can survive after its memory has been freed, and a later request handled by the same worker can use that stale state before normal initialisation resets it. Both are reachable by an unauthenticated request, both give code execution as the web server’s user, and PHP’s advisory rates the risk highest for Apache with mod_php, where a demonstrated exploit triggers the attack before any application code runs.

What makes this different from the plugin and Core flaws these briefings usually cover is where it sits. The flaw is in PHP, the interpreter that runs WordPress, so it is reachable on any site that executes PHP regardless of which plugins are installed, how well they are maintained, or whether WordPress itself is current. You cannot fix it from within the application. The fix is a new PHP package, installed by whoever operates the server, followed by a restart of the PHP processes. The version range remains the lasting problem: PHP has fixed the four branches it supports, has published minimal source backports for 7.4, 8.0 and 8.1 given the severity, and says distributions and long-term-support vendors received the patches in advance. Mallory’s Shodan count on 20 October found about 1.5 million internet-facing hosts that announce a PHP version, and 59 percent of them announce a branch that gets no upstream release.

Figure 1 · Status after PHP’s release of 21 October

A flaw in the interpreter: nothing inside WordPress closes it.

Question	Status after the release	What to do
Severity	Two unauthenticated RCEs in PHP core, CVSS v4.0 9.2	Treat as an emergency; update today
Patch	PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, 21 October 14:00 UTC	Install the package, then restart PHP-FPM or Apache
Who is at risk	Every PHP serving web requests; mod_php highest, FPM included	Update per site, not per server; check what each site selects
PHP 8.1 and older	No release; source backports for 7.4, 8.0, 8.1; vendors had patches early	Move to a supported branch or confirm a vendor backport
Exploitation	None reported in the wild; PHP validated an exploit on mod_php	Expect scanning of unpatched servers within hours
Mitigations	Partial, per PHP: upload progress off, memory_limit -1, low post_max_size	Only while the update is hours away; not a fix

Two details in the GitHub advisories matter for choosing what to do first. For CVE-2026-109618, PHP says Apache with mod_php is affected by default because it runs request shutdown even after a failed startup, while PHP-FPM exits the child process on startup failure and is less exposed; no complete PHP-FPM exploit had been demonstrated for this flaw, FrankenPHP is likely susceptible, and LiteSpeed’s LSAPI is likely susceptible but unvalidated. For CVE-2026-109619, the session upload-progress path was validated on both mod_php and PHP-FPM, and a second path through fatal error backtraces was confirmed on PHP 8.5 with mod_php. A WordPress server on PHP-FPM is therefore not out of scope; it is in scope for the second flaw and probably for the first.

WordPress officially recommends PHP 7.4 or newer and still runs on 7.2.24. That generosity is now a liability. A great many WordPress sites, especially older ones on shared hosting, run PHP 7.4, 8.0 or 8.1 because that is what the panel selected years ago and nothing broke. None of those branches will receive a fix from PHP. Mallory’s branch counts from Shodan on 20 October show the shape of it: 106,834 hosts announce PHP 8.1, 78,955 announce 8.0, 68,895 announce 7.4, 184,302 announce 7.2 and 187,154 still announce 5.6. These are banners, not confirmed vulnerable systems, and they exclude the roughly 740,000 hosts that hide their version, so the real number is higher.

Shared hosting multiplies this. One host in those counts is one server, and a cPanel or Plesk server commonly runs hundreds of sites, each pinned to a PHP version its owner chose in the panel. Mallory’s provider table puts Hostinger at 142,401 PHP hosts, Hetzner at 51,354, DigitalOcean at 47,105 and OVH at 36,848. On such a server the operator can update the ea-php or alt-php packages for the supported branches, but every site still selecting 7.4 or 8.1 stays exposed until it is moved to a branch that has the fix.

PHP’s advisory settles which ways of running PHP are in scope: all of them that serve web requests, which it lists as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates mod_php the highest risk, because the demonstrated exploit for the out-of-memory flaw works with default input and memory limits and a normal prefork configuration, and because mod_php runs request shutdown even after a failed startup where PHP-FPM would simply exit the worker. A typical cPanel server runs mod_php or LSAPI; a typical Nginx server runs PHP-FPM, which PHP describes as less exposed to the first flaw but confirmed vulnerable to the second through session upload progress. The command-line interpreter does not receive web requests, but it is the same binary and is updated by the same package.

1. 01

   Inventory every PHP version and how it serves requests

   On each server, record the interpreter version and which processes handle web requests:

   shell

   $ php -v
   $ ps -eo comm= | sort | uniq -c | grep -E 'php-fpm|php-cgi|httpd|apache2|litespeed|frankenphp'
   $ dpkg -l 'php*' 2>/dev/null | grep '^ii' || rpm -qa 'php*'

   The first command shows the command-line interpreter, which can differ from what the web server uses; the second shows which server processes handle web requests, and whether it is mod_php, the case PHP rates highest; the third lists the distribution’s PHP packages.

2. 02

   On cPanel and CloudLinux, list the packages and the per-site selection

   The installed branches and what each site actually runs:

   shell

   $ rpm -qa 'ea-php*' 'alt-php*' | grep -E '^(ea|alt)-php[0-9]+-[0-9]' | sort
   $ /usr/local/cpanel/bin/rebuild_phpconf --current

   The second command prints the system default and every per-domain PHP version; anything on ea-php74, ea-php80 or ea-php81 is a site that the supported-branch packages will not fix. Plesk users can read the same from the PHP settings of each domain.

3. 03

   Debian and Ubuntu, distribution packages

   Apply the distribution’s security update as soon as it is published:

   shell

   $ apt update
   $ apt list --upgradable 2>/dev/null | grep -i php
   $ apt upgrade

   A distribution package keeps its branch number and adds the fix, so Ubuntu 24.04 will still report 8.3.x and Debian 12 will still report 8.2.x; the package changelog or the distribution advisory is what confirms the fix. Ubuntu 22.04 ships PHP 8.1 and is in standard support until April 2027, and PHP’s statement that LTS vendors received the patches in advance makes a Canonical backport likely; confirm it on the Ubuntu CVE pages before treating 8.1 there as fixed. Third-party repositories such as the Sury packages follow their own schedule.

4. 04

   cPanel and WHM

   Watch the EasyApache 4 change log, then update the PHP packages and check what each site uses:

   shell

   $ yum update 'ea-php*'
   $ /usr/local/cpanel/bin/rebuild_phpconf --current

   Then move every site still on ea-php74, ea-php80 or ea-php81 to a fixed branch in MultiPHP Manager, and test it, unless cPanel publishes rebuilt packages for those branches. On a CloudLinux server, do the same for the alt-php packages when CloudLinux announces them, and check its note for HardenedPHP coverage of the older branches.

5. 05

   PHP 7.4, 8.0 and 8.1 built from source

   PHP has published minimal source backports of both fixes in the php-src repository, on the branches PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619. They are for people who build PHP themselves or have no LTS vendor; they are not releases, carry no other fixes, and do not change the fact that those branches are end of life. If you run one of them from a vendor package, wait for the vendor; if from your own build, rebuild from the branch and restart.

6. 06

   Restart the processes, or the fix is not running

   A package update replaces files on disk; the PHP-FPM workers that are already running keep the old code until they are restarted. With mod_php, Apache must restart. For example:

   shell

   $ systemctl restart php8.3-fpm
   $ systemctl restart apache2

   Use the unit names your server has; a cPanel server restarts through WHM or the restart scripts. Rebuild and redeploy any container image that includes PHP; restarting the same container changes nothing.

7. 07

   Verify from the web side, not the command line

   Confirm the version that serves requests: in WordPress at Tools, Site Health, Info, Server, or through a temporary phpinfo page that you delete afterwards. On a multi-version server, check one site per branch. On a distribution package, compare the package version against the advisory rather than the PHP version string. Then remove any interim php.ini changes you no longer need.

8. 08

   Keep watching for a week

   The patch is public and exploitation attempts against servers that have not updated are the expected next step. A server patched by 15:00 UTC is in a good position; a site moved from 8.1 to 8.3 on Friday was exposed for three days. For anything that stayed exposed, review the child processes of the PHP workers, new files in web roots, new cron entries and new administrators as in the indicators section.

1. 01

   Against CVE-2026-109619: disable session upload progress and restart every worker

   This blocks the confirmed session paths but, in PHP’s words, not other variants. In php.ini or a conf.d drop-in, or in every PHP-FPM pool:

   php.ini, or a PHP-FPM pool file

   ; php.ini or conf.d drop-in
   session.upload_progress.enabled = 0
   
   ; PHP-FPM pool, /etc/php/*/fpm/pool.d/ or /opt/alt/php*/etc/php-fpm.d/
   php_admin_flag[session.upload_progress.enabled] = off

   Then restart PHP-FPM or Apache, not merely reload, and confirm what the web SAPI sees with a phpinfo page you delete afterwards, or from WordPress at Tools, Site Health, Info, Server. The command-line interpreter reads its own php.ini and will not tell you. WordPress does not use session upload progress, so this costs nothing on a WordPress site.

2. 02

   On PHP 8.5 only: disable fatal error backtraces

   The second confirmed path for CVE-2026-109619 goes through the fatal error backtrace feature introduced in 8.5. PHP says to set it off and restart every worker; it blocks that path only:

   php.ini, PHP 8.5

   fatal_error_backtraces = 0

   Or php_admin_flag[fatal_error_backtraces] = off in the pool. 8.4 and older do not have the setting.

3. 03

   Against CVE-2026-109618: remove the controllable memory limit, and bound request size instead

   PHP’s mitigation is to set memory_limit to -1 in a way applications cannot override, and to check that no pool, directory or application setting puts a finite limit back; this removes the memory-limit failure an attacker can trigger on purpose, though an underlying allocation failure can still reach the vulnerable path. Then cap the request size so a worker cannot be driven out of memory from outside:

   PHP-FPM pool, or Apache <Directory> for mod_php

   php_admin_value[memory_limit] = -1
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 16M

   PHP suggests post_max_size of 8M where the application does not need uploads and 32M where it does, with upload_max_filesize below it; WordPress needs uploads, and a theme or plugin update through the dashboard needs post_max_size at least as large as the ZIP file. Note what WordPress loses with memory_limit unlimited: a runaway request can take the worker’s memory until the operating system intervenes, which is why PHP pairs this with a container or cgroup limit as the availability boundary, preferably one that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, because PHP says those can cause exactly the allocation failure that reaches the vulnerable path.

4. 04

   Enforce the request limits at the web server or proxy as well

   PHP asks for limits on decoded request size, input field count, multipart part count, header count and nesting depth, and says they must also cover requests without a usable Content-Length. In Nginx that is client_max_body_size and large_client_header_buffers; in Apache, LimitRequestBody, LimitRequestFields and LimitRequestFieldSize; the GitHub advisory additionally suggests lowering max_input_nesting_level and bounding max_input_vars and max_file_uploads in PHP itself. Set them to what your largest legitimate upload needs, not to zero.

5. 05

   Blocking multipart requests at the front: now a listed workaround, still a trade-off

   PHP’s GitHub advisory for CVE-2026-109618 lists blocking multipart requests at the front end as a workaround for applications that do not use them. WordPress uses them for every media upload, every plugin and theme ZIP and most contact forms, so a blanket rule breaks the site. If you use one, scope it to paths that never accept uploads, test it, and remove it once patched. The same goes for the Apache rewrite rule Syhunt published before the release.

6. 06

   Remove per-request settings that emit diagnostics, and fix fatal errors attackers can reach

   PHP’s last two mitigations for CVE-2026-109619 are housekeeping with a security purpose: remove invalid or deprecated INI settings applied per request that produce a diagnostic before initialisation, because hiding the diagnostic with error_reporting, display_errors or the @ operator does not help; and fix fatal errors and execution timeouts an attacker can trigger, including failures in callbacks, upload or import processing and cleanup. On a WordPress server that means reviewing .htaccess and .user.ini files for stale php_value lines and clearing the fatal errors in the PHP error log that a visitor can cause on demand.

7. 07

   What the earlier advice got right and wrong

   Before the release, researchers suggested disabling session upload progress and enabling session.use_strict_mode. The first is now PHP’s own mitigation; the second does not appear in PHP’s advisory, does no harm, and should not be counted as protection. The advisory for CVE-2026-109619 also mentions, where performance allows, setting pm.max_requests to 1 in PHP-FPM so that no worker handles a second request with stale state; on a busy WordPress site that respawns a worker per request, which is expensive, and it is the kind of measure to use for an hour, not a week.

8. 08

   Prepare to see exploitation

   A memory-corruption exploit in PHP ends with PHP spawning something it should not. List the child processes of the PHP workers now, so you know what normal looks like on each server:

   shell

   $ for p in $(pgrep -x php-fpm); do ps -o pid=,user=,comm= --ppid "$p"; done | grep -vE 'php-fpm|^$'

   On a WordPress server this should return nothing, or only processes you can name. Huntress’s guidance is to alert when php-fpm, php-cgi, httpd or apache2 launches sh, bash, curl, wget, python, perl or nc. A host with endpoint detection has this already; a host without can log it with a process watcher, which records but prevents nothing.

9. 09

   Tell your clients and your provider

   Agencies: tell site owners that a server-level PHP update is being applied and that a short restart is part of it. Shared-hosting customers: ask the provider which branches they have updated, when, and what they intend for sites on 7.4 or 8.1. A scheduled update is not a deployed one; ask for confirmation afterwards, and check Site Health yourself.

Now that PHP has published the details, Huntress intends to release Sigma and YARA rules through its public threat-intel repository, and web application firewall vendors will ship signatures. Neither covers the first hours after the release, which is why the process-level watch matters more than usual here.

Most WordPress security work happens inside WordPress: update the plugins, verify the checksums, review the administrators, harden the configuration. All of it still matters and none of it touches this. The interpreter is below the application, it is operated by a different person on most hosting arrangements, and it is updated on a different schedule. Site owners who have never thought about which PHP their host runs are about to find out that the answer determines whether they are protected today, next week, or never.

The end-of-life problem is the lasting one. PHP’s support policy is published and predictable: 8.1 reached its end on 31 December 2025, 8.2 reaches its own on 31 December 2026, and a branch that has reached its end gets nothing, however severe the flaw. This time PHP bent the rule as far as it goes, with source backports for 7.4, 8.0 and 8.1 and early access for vendors, and still those are patches for people who build PHP, not releases for people who install it. Hosting panels have made it painless to leave a site on an old branch indefinitely, and a large part of the WordPress estate has done so. A critical runtime flaw that reaches back through every branch is the moment that decision comes due. Moving sites to a supported branch is work, and it occasionally breaks a theme or an old plugin; leaving them where they are is now an accepted compromise, with the emphasis on compromise.

For operators, the leak changed the clock, not the task. A coordinated release gives everyone the same starting gun; a leaked one gave attackers a head start on understanding where to look, and the patch itself now shows them the rest. Sansec’s expectation of mass attacks within minutes of the release is a reasonable reading of how the last PHP flaw of this kind, CVE-2024-4577 in June 2024, went: Akamai saw exploitation of its honeypots within a day. The servers that matter are the ones updated in the first hours and the ones on branches that cannot be updated at all. Know which of yours is which today.

1. 01

   Inventory PHP per site, not per server

   On every server, record the interpreter version, the web SAPI and the per-site PHP selection:

   shell

   $ php -v
   $ ps -eo comm= | sort | uniq -c | grep -E 'php-fpm|php-cgi|httpd|apache2|litespeed|frankenphp'
   $ /usr/local/cpanel/bin/rebuild_phpconf --current

   Sort the results into 8.2 or newer, which has a release, and 8.1 or older, which has a backport at best. Note which servers run mod_php, the case PHP rates highest. Include containers, appliances and anything a vendor bundled.

2. 02

   Update the supported branches and restart PHP

   To 8.5.12, 8.4.27, 8.3.36 or 8.2.35: distribution packages through apt, dnf or yum as the distribution publishes them; ea-php and alt-php packages through the panel’s package manager when cPanel and CloudLinux publish them; container images by rebuild and redeploy; source builds from php.net. Then restart PHP-FPM or Apache, because running workers keep the old code until they do.

3. 03

   Move or patch every site on 8.1 or older

   In MultiPHP Manager, Plesk or the host’s panel, switch every site still on 7.4, 8.0 or 8.1 to a fixed branch and test it. Where a vendor has shipped a backported package for the old branch, or you build PHP yourself from PHP’s backport branches, that is the alternative. Sites that can do neither go behind access control or offline. This is the step that actually protects most WordPress sites on shared servers.

4. 04

   Verify what is serving requests

   Check the PHP version in Site Health, Info, Server on one site per branch, or through a temporary phpinfo page you then delete. On distribution packages compare the package version against the advisory, because the PHP version string will not change. Confirm the processes restarted.

5. 05

   Apply PHP’s mitigations only where the update is hours away

   Disable session upload progress, and on 8.5 fatal error backtraces, in php.ini or every pool; set memory_limit to -1 with php_admin_value and bound post_max_size and the request shape at the web server; restart the workers; verify from the web side. PHP says these reduce exposure to specific paths and do not make the installation safe.

6. 06

   Baseline PHP’s child processes and arrange to be told when they change

   Run the child-process check above on each server and keep the output. Alert on PHP workers spawning shells, interpreters or download tools, through endpoint detection where you have it and a process watcher where you do not.

7. 07

   Look behind the door on anything that stayed exposed

   For any server that was reachable on a vulnerable version after exploit code became public, work through the indicators table: child processes, new PHP files, administrators, cron entries, SSH keys, outbound connections, and bursts of memory-exhausted or fatal errors in the PHP log. Then roll back the interim php.ini changes and keep the baseline running for a week.

8. 08

   Plan the next one now

   PHP 8.2 reaches end of life on 31 December 2026. Every site that moved from 8.1 to 8.2 today moves again within ten weeks; move it to 8.3 or 8.4 instead and skip the second round.

This alert was first compiled on the morning of 21 October 2026, before PHP’s scheduled release, and revised the same day once PHP published its security advisory, the four releases and the two GitHub advisories. The vendor statements are now PHP’s advisory and the GitHub advisories for each CVE; the description of the flaws, the fixed versions, the at-risk SAPIs, the mitigations and the backports are taken from them. Everything attributed to researchers and reporting before the release is labelled as such and kept for the record. Exposure figures are quoted as Mallory reported them from Shodan banners and were not re-measured. The German report on Golem.de that prompted the first version is listed for completeness; its body sits behind a consent wall and the facts above were taken from the primary sources. This page will be revised again if PHP amends its advisory or exploitation is confirmed, and the modified date at the top will change.