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

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-1deb13u1 on Debian 13 and 8.2.35-1deb12u1 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.