If you are running PHP 7.4, 8.0 or 8.1 right now, no patch is coming. Not late, not waiting behind other work. Never.
On 21-23 October 2026, two critical remote code execution flaws landed in PHP core: CVE-2026-109618 and CVE-2026-109619, CVSS 9.2 each. Unauthenticated. Any web-facing PHP runtime counts, so mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. CISA and CERT-EU both say patch immediately, and exploit attempts have already been reported.
Emergency fixes exist for 8.5.12, 8.4.27, 8.3.36 and 8.2.35. That is the whole list. A third flaw, CVE-2026-115560, was disclosed on 23 October with no patch at all, and the only mitigation today is session.upload_progress.enabled=0 in php.ini.
Teams keep misreading this part. An unpatched version is a maintenance problem. An unpatchable version is an architecture decision that someone already made for you, two or three years ago, by not moving.
Three things to do today if you stay on PHP:
- Move to a patched 8.2+ build.
- Set session.upload_progress.enabled=0.
- Ask your hosting vendor what they have actually patched, not what their status page says, what the running binary reports.
Then the harder one. If the only way forward is a jump anyway, you get to pick whether it is a version jump or a stack jump.
We have done legacy rewrites before: monolith-to-microservices on inherited systems, runtime migrations, systems with money and compliance on the line. Send us the service today and within one day we tell you what moving it off PHP onto a supported, modern stack costs and how many weeks it takes. Small services come out in days, not months. Large ones we scope honestly, including the parts we would probably leave alone.
Message us with the service and we will come back with numbers.
If you are on 7.4, 8.0 or 8.1 today, tell us what is actually blocking the move. Our experience says it is rarely the code.