CISA and CERT-EU flag two PHP RCE flaws rated 9.2; no patches for EOL PHP 7.4–8.1

Two unauthenticated RCE flaws in PHP core

According to a write-up on dev.to, CISA published an alert and CERT-EU issued advisory 2026-018 on 21 October 2026, covering two remote code execution vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 9.2, and both let an unauthenticated attacker execute code on a PHP runtime exposed to the web. The write-up reports that exploitation attempts have already been seen.

Because the bugs sit in PHP core rather than in an extension or a framework, the php.net release notes, as cited by the post, indicate that every mainstream way of serving PHP over HTTP is reachable: mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. No configuration change neutralises an exposed runtime; the fix has to come from the interpreter itself. The post also refers to the episode by the name PHP2Shell.

Fixed branches, and branches that will never be fixed

Emergency releases now carry the patches: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For anyone on PHP 8.2 or newer, the post says this reduces to a routine package upgrade followed by a restart.

PHP 7.4, 8.0 and 8.1 are in a different position. All three branches are past end of life, no fix was produced for them, and the write-up is categorical that none is coming. Operators on those versions cannot patch at all; the only thing on offer is a mitigation aimed at a separate, newer flaw.

A third flaw and a one-line mitigation

On 23 October, a third vulnerability was disclosed as CVE-2026-115560, and it also has no patch yet. The only published workaround, per the dev.to write-up, is a single php.ini setting: session.upload_progress.enabled = 0.

The post stresses verifying that the setting reached the SAPI that actually serves traffic. Command-line and FPM processes frequently load different configuration files, and a mitigation placed in the wrong one has no effect.

The write-up also dismisses some early noise: details appeared on Hacker News before the official release carrying an inflated score of 10.0, while the official rating is 9.2. As the author puts it, the decimal point changes nothing about the work either way.

What the write-up tells operators to do

The recommended sequence is to move to one of the four patched builds, apply the one-line mitigation and confirm it took effect, verify what a hosting provider actually runs — meaning the binary answering requests rather than a vendor status page — and inventory every machine executing PHP, including cron hosts, queue workers and container images. A scheduled job on an unpatched build is less exposed than a web-facing one, the post notes, but that is not the same as being safe, and such machines often hold credentials for everything else.

The choice facing PHP 7.4 to 8.1 users

The post's central argument is that an unpatchable branch is not a one-off incident but a standing condition: every future CVE will land on these versions with no upstream answer, leaving operators improvising mitigations that may or may not exist for each particular bug. The realistic question becomes whether to jump to a supported PHP version or move off the runtime entirely. The author proposes four tests: the service's surface area of endpoints, scheduled jobs and integrations; the balance between replaceable framework glue and undocumented business logic; whether any executable tests describe correct behaviour; and whether anyone still on the team understands the business rules. Two strong branches and a staffed team point toward a version jump; mostly glue, thin rules and no remaining owner point toward leaving PHP.

Why it matters

Unauthenticated remote code execution rated 9.2 in a runtime as widely deployed as PHP is a serious exposure on its own, and the post says attacks are already being attempted. What makes this event unusual is the hard split between versions that received emergency fixes and versions that never will. For any organisation still running PHP 7.4, 8.0 or 8.1, this is not a patching exercise but a forced platform decision — and the same dilemma will return with every vulnerability these branches accumulate from here on.