# CVE-2026-109619: RCE via Stale Global State

> CVE-2026-109619 explained: why internal state carried between requests becomes dangerous, which PHP versions are fixed and how to secure your servers.

Source: https://phpsos.de/en/php2shell/cve-2026-109619/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** CVE-2026-109619 is the second vulnerability behind PHP2Shell. Internal state belonging to a request can persist after memory is freed; a later request in the same worker can use it before it is reset. The consequence is code execution without logging in. Remedy: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart all workers.

## What is CVE-2026-109619?

CVE-2026-109619 (GitHub identifier GHSA-6wmf-4rv5-p3rp) is rated 9.2 on CVSS v4.0. Together with [CVE-2026-109618](https://phpsos.de/en/php2shell/cve-2026-109618/), it forms PHP2Shell. Both vulnerabilities are in PHP itself and not in an application.

The effect is the same as with the sister vulnerability: an attacker can execute code on the server remotely, without a password and without a user account. The cause, however, is a different one.

## Why stale state in the worker is dangerous

A PHP web server does not start a new process for every request. With PHP-FPM, Apache with mod_php, LiteSpeed or FrankenPHP, a worker handles many requests one after another. Between two requests, PHP resets its internal state so that nothing from request A reaches request B.

With CVE-2026-109619, this reset does not work completely. According to php.net, internal state belonging to the request can persist after the memory is freed. A later request in the same worker can use this stale state before it is reset. Put simply: something is reused that is actually no longer valid.

From an operations point of view, this is notable. Reusing workers is intended because it makes web servers fast: a worker does not have to restart for every request, load extensions and allocate memory. The vulnerability therefore hits a property that practically every production PHP installation has. php.net names no configuration that avoids the problem entirely; that is why the way forward is the update.

We do not publish details on exploitation. What matters for operators: every operating mode in which workers serve several requests needs to be kept in view, and these are exactly the usual operating modes.

## The two PHP2Shell vulnerabilities compared

| Feature | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub identifier | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Rating | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Trigger | Out-of-memory during initialisation of the request data | Internal state persists after being freed |
| Effect | Code execution without logging in | Code execution without logging in |
| Fixed in | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are affected. The PHP team sees the highest risk with mod_php; we explain why at [Why mod_php carries the highest risk](https://phpsos.de/en/php2shell/mod-php-risiko/).

## Closing CVE-2026-109619: update, then restart all workers

With this vulnerability in particular, the restart is decisive. As long as old workers are running in memory, the server keeps working with the faulty code, even if the new files have long been on disk.

Check the version and package version. Package names differ by distribution and hosting interface:

```bash
php -v
php-fpm8.3 -v                  # the FPM binary may have a different version than the CLI
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL family
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Then restart all affected services:

```bash
sudo systemctl restart php8.3-fpm     # per installed PHP version
sudo systemctl restart apache2        # with mod_php; on RHEL the service is called httpd
```

If your distribution or hosting provider applies a backport, the displayed version number may stay the same. In that case, the package changelog and the provider's written confirmation count. You will find a step-by-step check at [Restarting PHP-FPM and all workers](https://phpsos.de/en/php2shell/php-fpm-neustart/).

> **Tip:**
> Note the date and time of the restart. For the later assessment of whether an attack took place before or after the patch, this point in time is the most important reference.

## What still needs to be done after the patch

A patch does not prove that nothing happened beforehand. According to media reports, a first attack attempt was observed on 17 October, four days before the patches. Keep server logs from 20 October onwards, as the trade press recommends, and check the server for anomalies. Notes on this are on the page [Am I already compromised?](https://phpsos.de/en/php2shell/bin-ich-gehackt-anzeichen/).

Keep the reach in mind: with successful code execution, the attacker has the rights of the PHP process. They can read whatever the application is allowed to read, such as configuration files with database credentials or API keys. If an incident is confirmed, these credentials should be renewed after the cleanup.

## How does PHP SOS help?

With the [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we implement the fix in a traceable way:

- **Record:** Which PHP versions and operating modes run on which server, and which package source supplies them?
- **Patch:** Update from the right source or interim measures according to php.net where the update is still blocked.
- **Verify the restart:** We check process by process that only the corrected version is still running.
- **Document:** Versions, package states and restart times, so that you can prove the state.


## Frequently asked questions

**What distinguishes CVE-2026-109619 from CVE-2026-109618?**  
CVE-2026-109618 arises when an out-of-memory condition interrupts the request in the middle of initialisation. CVE-2026-109619 concerns state that is left over in the worker after a request ends. Both lead to code execution without logging in and are fixed in the same PHP versions.

**Does restarting PHP-FPM workers more often help?**  
It is not suitable as a replacement for the update. php.net does not list more frequent worker restarts as an interim measure. You do, however, have to restart the workers after the update so that the corrected version is actually running.

**Am I protected against CVE-2026-109619 by a CMS update?**  
No. The vulnerability is in PHP and not in WordPress, Shopware, TYPO3 or any other system. Only a PHP update or a confirmed backport from the provider closes it.

**Are there known traces of an attack via CVE-2026-109619?**  
No confirmed indicators of compromise have been published so far. Detection relies on behavioral analysis, for example new PHP files, unusual outgoing connections or unknown cron jobs.

## Sources

- [php.net: Security announcements](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/)