# PHP RCE Flaws CVE-2026-109618 and 109619 Hit CISA KEV: Patch Now

Page: https://hirantha.me/blog/php-rce-flaws-cve-2026-109618-and-109619-hit-cisa-kev-patch-now
Published: 2026-10-27
Written by: hirantha.me Newsroom (AI-generated). An AI model wrote this from the sources listed below; how it is made: https://hirantha.me/about/newsroom
Topics: php, cve-2026-109618, cve-2026-109619, cisa kev, remote code execution

> Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12; CISA added both critical flaws to its exploited list on 26 October 2026.

Two critical flaws in PHP, the language behind a large share of websites, are now on the United States Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) list. The PHP project shipped fixes on 21 October 2026, and CISA added both flaws to KEV on 26 October 2026, in an update to its alert titled "Critical Vulnerabilities in PHP Require Immediate Patching". CISA's page gives no remediation due date.

The practical question for most site owners is not whether PHP is affected but whether the PHP they run is actually fixed, because several Linux vendors patch without changing the version number.

## The two flaws at a glance

| Item | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Type | Memory corruption after an out-of-memory (OOM) error | Stale request state surviving into the next request |
| Result | Unauthenticated remote code execution | Unauthenticated remote code execution |
| CVSS v4 score | 9.2 (critical), per the PHP advisory | 9.2, per Rapid7 |
| Fixed in | 8.2.35, 8.3.36, 8.4.27, 8.5.12 | Same releases |
| CISA KEV | Added 26 October 2026 | Added 26 October 2026 |
| Remediation due date | Not published | Not published |

The PHP project's advisory for the first flaw is GHSA-w8hw-w9fx-j79w. It says PHP exits a request with `longjmp()` when memory runs out, and if that happens while request memory is only partly set up, the shutdown code can act on invalid data. Specially shaped multipart requests (the format used for file uploads) can push a request into that state while staying inside apparent size limits.

The second flaw is a different bug of the same family. Per Rapid7, state left behind by one request can be reused by the next request on the same worker. The confirmed routes are session upload progress, which is on by default, and, on PHP 8.5 only, fatal error backtraces.

## Who is exposed

Any PHP that serves web requests and is older than the fixed releases. Rapid7 lists PHP-FPM (FastCGI Process Manager), Apache `mod_php`, `php-cgi`, FrankenPHP and LiteSpeed. The PHP advisory treats Apache with `mod_php` as the highest risk, because exploitation can happen before any application code runs. Rapid7 says a confirmed exploit for the first flaw works against `mod_php` with default limits, while PHP-FPM stops the worker on startup failure, which blocks that particular sequence.

No login is needed, only HTTP requests to a PHP endpoint. Researchers quoted by the Computing for Geeks guide trace affected releases back to PHP 5.4. PHP 8.1 and older no longer receive routine upstream updates; the project published limited source-only backports for 7.4, 8.0 and 8.1, which do not restore support.

## Is it being exploited?

The sources disagree on timing, so the dates matter. On release day CISA said it had not seen exploitation. Rapid7 says it has not observed exploitation in the wild but has seen multiple attempts, and that several public proof-of-concept exploits exist, each tied to one operating system, PHP version and web server combination, none broadly reliable. CISA's KEV listing five days later is the signal that exploitation has since been confirmed. Treat the window as open.

## What to do in the next 24 hours

1. **Find every PHP.** Include web servers, containers, build images and old staging boxes. Rapid7 names the Velociraptor artifact `Generic.Applications.PHPInventory` for inventory on Windows, Linux and macOS.
2. **Update to a fixed release:** 8.2.35, 8.3.36, 8.4.27 or 8.5.12, then restart PHP-FPM or Apache so every worker loads the new code.
3. **Do not trust `php -v` alone.** Ubuntu, AlmaLinux, CloudLinux and some end-of-life backports keep the old version string. Confirm the fix in the package changelog:

```
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'
```

   Change the package name to match your version. On Remi repository builds, which use upstream numbering, an empty result is normal and the version number is the proof. Debian ships the upstream release, so `php -v` is valid there; fixed builds include 8.4.27-1~deb13u1 on Debian 13 and 8.2.35-1~deb12u1 on Debian 12.
4. **Rebuild containers.** Pull a fixed `php` image, rebuild with `docker build --pull` and recreate the containers. Restarting a running container does not apply the fix.
5. **If you cannot patch today, reduce exposure.** Rapid7 lists these, and says none is a complete fix:
   - Set `memory_limit=-1` in the server or FPM pool configuration where applications cannot override it, then restart workers.
   - Set `session.upload_progress.enabled=0` administratively. Application-level `ini_set()` and `.user.ini` files are too late.
   - On PHP 8.5, set `fatal_error_backtraces=0`.
   - Keep `post_max_size` conservative (Rapid7 cites 8M, or 32M where uploads are needed) and limit multipart parts and nesting at the front end. Do not use `RLIMIT_AS` or `RLIMIT_DATA`.

Red Hat did not publish errata for the `php:8.1` stream on RHEL 9 or the `php:8.0` stream on RHEL 8, per the Computing for Geeks guide, so those systems depend on the Remi repository or a move to a supported PHP. Remi had no updates on 21 October.

## Decide today whether any PHP 8.1-or-older server stays online

Supported branches have a clear fix. The harder decision is for servers on PHP 8.1 or older with no vendor backport: either move them to a supported branch this week or take them off the public internet. Run the changelog check on every other server today, and record which ones show a fixed build.

The researchers also say the bugs can leak memory from other requests, such as tokens and API keys, without running code. After patching a server that was exposed, rotating secrets held by PHP workers is a reasonable precaution.

## Questions

**Does php -v show whether my server is patched?**
Not always. Ubuntu, AlmaLinux, CloudLinux and some backports keep the old version string, so check the package changelog for CVE-2026-109618 and CVE-2026-109619 (Computing for Geeks).

**Is restarting a Docker container enough to apply the PHP fix?**
No. Pull a fixed php image, rebuild your own images with docker build --pull and recreate the containers.

## Sources

- [CISA Adds Two Known Exploited Vulnerabilities to Catalog](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog), cisa.gov
- [GHSA-w8hw-w9fx-j79w: RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), github.com
- [CVE-2026-109618 and CVE-2026-109619: Critical unauthenticated RCE in PHP](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/), rapid7.com
- [PHP2Shell: check and patch CVE-2026-109618](https://computingforgeeks.com/php2shell-cve-2026-109618-check-patch/), computingforgeeks.com