Urgent: Two Critical PHP RCEs (CVE-2026-109618, CVE-2026-109619) — Patch on 21 October
The PHP security team ships an emergency release on 21 October 2026 at 14:00 UTC for two remote code execution flaws rated CVSS v4.0 9.2. What is known, what is not, and the six things to do before and after the patch lands.
Update your PHP today. The PHP security team has announced an emergency release for Wednesday, 21 October 2026 at 14:00 UTC that fixes two critical vulnerabilities, both rated CVSS v4.0 9.2. Researchers describe both as remote code execution in PHP itself — not in a framework or a plugin — which means almost every PHP site is in scope until the release notes say otherwise. The team has said it may release earlier if details leak further or exploitation appears. Plan to patch within hours of the release, not days.
What we know
- Two CVEs: CVE-2026-109618 and CVE-2026-109619. Details were due later this week, but the issue leaked early on social media and Hacker News, and PHP brought the release forward.
- Severity: CVSS v4.0 9.2 for each, per PHP's own notice. The "10.0" figure in the leak was never official.
- Reproduced: watchTowr says it has reproduced CVE-2026-109618 and is holding back technical details until patches are out.
- Not exploited yet: no in-the-wild exploitation has been reported, and neither CVE is in CISA's Known Exploited Vulnerabilities catalog. Expect that to change quickly once the patch is public — a fix is also a map to the bug.
What we don't know yet
PHP will publish the affected versions, fixed versions and conditions (for example whether FPM, CLI or a specific extension is required) with the release. Until then, treat these as unconfirmed:
- Early reports claim every version from PHP 5 onwards is affected.
- Fixed versions are expected on the supported branches only — 8.2, 8.3, 8.4 and 8.5. Some reports name 8.2.35, 8.3.36, 8.4.27 and 8.5.12; check the release notes before relying on them.
What to do now
- Inventory every PHP you run. Not just the version your site uses — every installed branch, every PHP-FPM pool, every CLI binary that cron or a queue worker calls, and every container image with PHP inside. Old branches left installed "just in case" are still attack surface if something can reach them.
- Know where your patch will come from — and how late it arrives. Upstream ships source at 14:00 UTC; your packages follow on their own schedule. Third-party repositories such as
ppa:ondrej/php/packages.sury.orghave historically followed within hours; distribution security teams (Ubuntu, Debian, RHEL) can take longer; official Docker images rebuild on their own cadence, and an image that pins an old base tag will never receive the fix until you rebuild it on a current one. If a hosting panel manages PHP for you, find out today how it rolls out updates. - Find your end-of-life PHP. PHP 8.1 and older no longer receive upstream fixes. If a fix reaches them at all it will be a backport from your distribution or package source — and some sources have stopped publishing for old operating systems entirely (for example, Ubuntu 20.04 packages have been withdrawn from
ppa:ondrej/php). For those servers the real fix is an upgrade or a move, so start planning now. - Restart, don't just install. After the upgrade, reload every PHP-FPM service — and remember long-running PHP processes: queue workers, schedulers, Octane/Swoole/RoadRunner servers, websocket daemons. They keep the old, vulnerable binary in memory until they restart.
- Stop advertising your version. Set
expose_php = Offso responses no longer carry anX-Powered-By: PHP/x.y.zheader that tells a scanner exactly which hosts to try first. - Watch for the details. When the release notes name the vulnerable configuration, check whether yours matches — and look at logs from the hours before you patched.
How TCSR helps
A TCSR scan reports the PHP version your server advertises in its Server and X-Powered-By headers, and Audit-plan scans match detected component versions against the NVD vulnerability feed. Once NVD publishes these two CVEs, a rescan will show whether an advertised version falls in the affected range. A clean result is not proof you're patched, though: a server that hides its version can still be vulnerable, which is exactly why step 1 matters more than any external scan.
We'll update this post when the release is out with the affected and fixed versions.