CVE-2026-109618 and -109619: A Response Plan for PHP Servers

October 21, 2026#CVE-2026-109618

Sandor Farkas

Founder & Lead Developer

Expert in software development and legacy code optimization

Most of the vulnerabilities we discuss with clients live in a plugin, a library, or a piece of custom code. CVE-2026-109618 and CVE-2026-109619 are different. They sit in the PHP interpreter itself, the layer your entire application runs on. The PHP project shipped fixed versions this week, and CERT-EU, the security team of the EU institutions, followed on October 21, 2026 with Security Advisory 2026-018. Its recommendation leaves no room for interpretation: patch immediately.

Both flaws are rated 9.2 out of 10. An attacker needs no user account, no password, and no weakness in your code. A single crafted HTTP request can be enough to run their own code on your server. Public proof-of-concept code demonstrating the exploit is already circulating.

This post is not a background piece but a working plan. It is ordered by what should happen in the first few hours, over the course of the day, and in the weeks that follow.

The short version: why your own code doesn't protect you here

When a request reaches a PHP server, a lot happens before the first line of your application runs. PHP parses headers, form fields, and file uploads, allocates memory, and sets up the environment. Both bugs live in exactly that phase. A login form, a Symfony firewall rule, or a WordPress security plugin never gets a chance to intervene.

CVE-2026-109618 concerns the per-request memory limit. If a request hits that limit at an unlucky moment, for example halfway through parsing an upload, PHP aborts and then cleans up data structures that were only partly built. In doing so it can free memory that still holds attacker-controlled data.

CVE-2026-109619 concerns long-lived worker processes. PHP-FPM and similar setups handle many requests one after another in the same process. After certain severe errors, such as a fatal error, references to memory that has already been freed are left behind. The next request in the same process can reach them before PHP resets its state.

The outcome is the same in both cases: in the worst case, the attacker takes over the PHP process and inherits its permissions. That means access to database credentials in your configuration, to uploaded files, to customer data, and often a foothold into the internal network.

Widespread exploitation had not been confirmed at the time of disclosure. CERT-EU considers it likely, though, and experience with comparable flaws shows that automated scans for vulnerable servers start within a few days.

The first few hours: find every place PHP is running

The real work rarely starts with the update. It starts with the question of where the update needs to go. At most companies we work with, the honest answer is longer than expected. Besides the obvious website, there is often a shop on a different server, an internal tool a former employee built, a staging environment that is still publicly reachable, and devices that quietly run PHP under the hood.

Work through these categories:

Your own servers and VMs running a website, shop, customer portal, or API
Container environments where PHP is part of a Docker image
Shared or managed hosting, where the provider controls the PHP version
Staging, test, and legacy systems nobody actively uses but that are still reachable
Appliances and network devices whose admin interface is built on PHP

For that last group, the Dutch National Cyber Security Centre (NCSC-NL) has started an overview of potentially affected products. It is explicitly incomplete, but it is a useful starting point for checking vendor lists.

There is a trap when checking the version. php -v on the command line shows the CLI version, and that is not necessarily the one your web server uses. Many servers have several PHP versions installed side by side. It is more reliable to ask the running service directly:

# Version of the installed FPM binary (name varies by distribution)
php-fpm8.3 -v

# Which PHP packages are actually installed?
dpkg -l | grep -E '^ii\s+php'      # Debian/Ubuntu
rpm -qa | grep -i php              # RHEL/Alma/Rocky

# In Docker: version inside the running container
docker exec <container> php -v

On shared hosting, the active version is usually shown in the provider's customer panel. If you cannot check it yourself, now is the right moment for a short message to your developer or agency. How quickly and precisely they answer says a lot about how well your system is looked after. For more on who is actually responsible for updates like this, see our post Security Updates for Business Software: Who Is Responsible When No Developer Is Left?

Then prioritize. At the top are systems that are directly reachable from the internet and accept file uploads or forms. According to the PHP team, the risk is highest for Apache with mod_php, because a complete attack chain has already been demonstrated there. But every common setup is affected: PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed.

Over the course of the day: update to a patched version

An update is the only measure that actually closes both holes. These versions contain the fixes:

Your version	Update to at least	Support status
PHP 8.5.x	8.5.12	active support
PHP 8.4.x	8.4.27	active support
PHP 8.3.x	8.3.36	security fixes only
PHP 8.2.x	8.2.35	until December 31, 2026
PHP 8.1 and older	no regular release available	end of life (see below)

What the update looks like depends on your environment.

Linux distribution packages. This is usually the fastest route. According to the PHP team, the major distributions received the fixes in advance, so updated packages should already be available or follow shortly. One exception is the popular Remi repository (rpms.remirepo.net), which had no updates on the day of release. In that case, the PHP team recommends switching to distribution packages or building PHP yourself.

Docker and containers. A container does not update itself. Pull the new base image, rebuild your application image, and deploy it. While you are at it, check whether your Dockerfile pins a specific patch tag such as php:8.3.30-fpm. If it does, a rebuild alone changes nothing, and the tag has to be bumped. The same applies to FrankenPHP. If you run it, our article on FrankenPHP in production covers image strategy in more detail.

Shared and managed hosting. Here the update is the provider's job. Ask actively instead of waiting, and get the date and version confirmed in writing. That confirmation is also useful evidence later, when customers, insurers, or auditors ask.

Appliances and devices. You cannot update these yourself. Watch the vendor's security advisories, and until the firmware update arrives, restrict who can reach the admin interface.

One step is forgotten surprisingly often after updates: the running processes must restart. Until an FPM pool or an Apache with mod_php has been restarted, the old, vulnerable version keeps running in memory. Restart the FPM service or Apache, then check which version is actually being served, using a phpinfo() page or your monitoring data. Remove that phpinfo() page again right afterwards.

If you are still on PHP 8.1, 8.0, or 7.4

These versions no longer get regular releases. They have reached end of life. This time, the PHP security team made an exception anyway and published minimal fixes for 7.4, 8.0, and 8.1 as source code. Those are intended for operators who compile PHP themselves. In addition, some long-term-support distributions and commercial vendors ship their own backports, meaning fixes carried back into the old version after the fact.

That makes the immediate problem solvable. The underlying problem remains. The next critical flaw may come without an exception, and then you are left on a version nobody writes patches for. If this incident caught you on one of these versions, it is a good reason to stop putting off the upgrade. We wrote up the trade-off between upgrading and paying for long-term support in Upgrade Now or Pay for Extended Support?, and what an outdated PHP version costs overall in Still on PHP 8.1 or Older?

PHP 8.2 still gets a regular patch this time, but not for much longer. Its security support ends on December 31, 2026. Updating to 8.2.35 today protects you against these flaws, but the next upgrade should already be on the calendar. More on that in PHP 8.2 End of Life on December 31, 2026.

When the update has to wait: interim mitigations

Sometimes it cannot happen right away. A device is waiting on firmware, a host is not responding, a client only allows changes in an agreed maintenance window. For these cases, the PHP team has published settings that make the known attack paths harder. They do not replace the update. They shrink the attack surface until it is applied.

Against CVE-2026-109619, the session extension's upload progress tracking should be disabled, and on PHP 8.5 also the backtraces for fatal errors:

; php.ini or FPM pool, not via ini_set() or .user.ini
session.upload_progress.enabled = 0

; additionally, on PHP 8.5 only
fatal_error_backtraces = 0

These values only take effect when set at the server level, meaning in php.ini, the pool configuration, or the web server configuration. All workers have to restart afterwards. The PHP team also recommends cleaning up configuration values that trigger warnings on every request, such as deprecated or invalid directives. Merely hiding those warnings with display_errors is not enough. Likewise, errors an attacker can provoke on purpose should be fixed, for example crashes or timeouts during uploads and imports.

Against CVE-2026-109618, the advice is more unusual. Because the flaw is triggered precisely when PHP hits its own memory limit, that limit should be removed and replaced by limits enforced outside of PHP:

set memory_limit = -1 in a way the application cannot override, for example with php_admin_value in the FPM pool or the Apache configuration
cap request sizes: the PHP team suggests post_max_size = 8M without uploads and 32M with uploads, with upload_max_filesize below that in each case
set limits on request size, number of form fields, headers, and multipart parts at the web server or reverse proxy, in a way that also covers requests without a Content-Length
cap the process's memory from outside via container or cgroup limits, explicitly not via RLIMIT_AS or RLIMIT_DATA, since those can trigger the very same bug

Test these changes before rolling them out widely. Tighter upload limits will break large CSV imports or media uploads, for instance, and without an external memory cap a single process can take the whole server down.

After the patch: check whether someone already got in

If a system sat unpatched on the internet for several days, the update is not the end of the job. An attacker who succeeded before the update is still in the system after it. Look through the last few days of logs for:

an unusual number of aborted requests or memory errors in PHP and web server logs
PHP workers that crashed or restarted unexpectedly
new or recently modified PHP files in web directories and upload folders
unknown processes or outbound connections originating from the web server

The NCSC-NL repository also includes detection guidance. If you have a concrete suspicion, do not try to "clean up" the server yourself. A compromised system is generally rebuilt from scratch, and any credentials stored on it are rotated. Keep the GDPR in mind as well: if personal data was accessed, notifying the supervisory authority is usually due within 72 hours.

The coming weeks: learn from the incident

Flaws of this severity do not announce themselves. The teams that were done within a few hours today had three things in place beforehand: an up-to-date list of their systems and versions, a clear owner for updates, and a tested way to roll out a new PHP version. The teams that spent the day searching were missing at least one of them.

If you were in the second group, use this incident as the reason to put those three things in place. Our yearly end-of-life checklist helps with the inventory. The rest usually does not need a big project, just a clear owner and a few hours of work each month.

Checklist

List every system running PHP, including staging, legacy systems, and devices.
Check the version the web server actually uses, not just php -v.
Patch internet-facing systems with uploads and forms first.
Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35.
Restart FPM or Apache and verify the version being served.
For PHP 8.1 and older, apply a backport and schedule the upgrade.
Where no update is possible, apply and test the interim mitigations.
Review the last few days of logs for anything unusual.

Where we can help

If you are not sure which of your systems are affected, if your application still runs on PHP 8.1 or older, or if you want a second opinion on suspicious log entries after patching, reach out at hello@wolf-tech.io or through our contact form. We help with the inventory and the patching, and if you want, we can plan the upgrade of your legacy system with you or review the state of the application in a code and security audit.