Two critical remote code execution bugs in PHP get their fix on Wednesday. Details leaked before the announcement, and PHP’s release is now scheduled for a day earlier than the leaked timeline suggested. Here’s what that means if you run PHP in production.
What happened
On October 20, 2026 the PHP security team posted an advance notice on php.net. A security release is scheduled for Wednesday, October 21, 2026 at 14:00 UTC, and it addresses two critical vulnerabilities, both rated CVSS v4.0 9.2. PHP’s notice doesn’t name them; the identifiers circulating in the leak and in watchTowr’s FAQ are CVE-2026-109618 and CVE-2026-109619.
Details leaked first. A Hacker News post pointed to a Thursday, October 22 disclosure, claimed a CVSS score of 10.0, and named both CVE IDs. watchTowr confirmed the bugs are real, said it has reproduced CVE-2026-109618, and stated that both are understood to affect PHP versions 5 through 8. PHP’s own notice is dated the same day as the leak and lands the release on Wednesday instead.
No exploitation has been observed in the wild, according to watchTowr and the other researchers reporting on this. No public proof of concept has surfaced. Neither CVE is in the CISA Known Exploited Vulnerabilities catalog as of the October 20 release, which we verified against the raw catalog feed.
What is not settled yet
PHP hasn’t confirmed which versions are affected, how the flaws are exploited, or which releases carry the fix. The developers say full technical details, affected versions, and fixed versions ship with the release itself. The CVE records are still in reserved status.
The gap between the leaked 10.0 and the official 9.2 isn’t worth much in practice. Either number means the same thing for your calendar: this is a patch today, not a patch next quarter.
The part that decides your timeline
Reporting on this puts the fixes on supported PHP 8 branches. PHP 5 and PHP 7 are both long past end of life, so no fixes are expected for them. Treat that as the expected shape of the release rather than a confirmed one, because PHP hasn’t published the fixed version list yet.
If you’re running PHP 7 on a box nobody’s touched since 2022, the 14:00 UTC release most likely does nothing for you. Your fix is a major version migration, which is a planning exercise, not a patch window. Find out which one you’re on before you assume you’ve got a one day job.
What to do now
- Inventory. List every host running PHP. Note the major version (5.x, 7.x, 8.x) and how it was installed: OS package, container, custom build, shared hosting.
- Split the 8s from the 5s and 7s. The two groups need different work. Sort them now so the 8.x list can get patched as soon as the release lands.
- Know your update path in advance. If you build from source or run containers, confirm the image and build pipeline before the release lands, not after.
- Watch php.net and your distro advisories. The release may come earlier than 14:00 UTC. PHP said it reserves the right to publish immediately if technical details surface or exploitation is detected, and details are already leaking.
- Plan for the unpatchable. CERT-EU’s advice for anything you can’t patch right away is to pull internet facing PHP applications off public networks until a fix is available. That’s a real option for a lot of small estates, and it beats assuming a patch is coming.
- Recheck KEV. If exploitation shows up, the priority changes with it.
The bottom line
No exploitation, no public proof of concept, a confirmed release date. This is a manageable one, with one condition: if you’re on PHP 7, the 14:00 UTC release probably isn’t your patch day, and treating it like it is would be the mistake.
We spend a lot of time finding out what’s actually running on our clients’ external surfaces, and the version question comes up constantly. Knowing your PHP inventory before the emergency lands is most of the work. If you’d rather find out what you have exposed, that’s what our external attack surface monitoring is for.