Two critical PHP flaws turn an unsupported version into a live exposure

What happened

On 20 October 2026, the PHP security team gave advance notice of a security release scheduled for 21 October at 14:00 UTC, covering two critical vulnerabilities. Security firm Sansec, in an article dated 21 October, reports that both are remote code execution flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619, and that the PHP security team rates both at CVSS v4.0 9.2. The team reserved the right to release earlier if details became public or attacks began.

Details then leaked ahead of the release. Sansec's timeline puts a Hacker News post about the upcoming disclosures at 15:20 UTC on 20 October, and says watchTowr confirmed the leak and that the flaws are remote code execution bugs. A write-up from Phoenix Security, also dated 21 October, adds that watchTowr reproduced CVE-2026-109618 in a lab, and that exploitation in the wild had not been observed when it was written.

What is and is not known, according to the two sources:

Both sources recommend updating PHP at the infrastructure level, and say the problem cannot be fixed inside application code. As an interim step, Sansec suggests setting session.upload_progress.enabled to off and session.use_strict_mode to on. Phoenix suggests the first of those too, plus rate-limiting or inspecting multipart form uploads on endpoints that do not accept uploads. Phoenix notes that PHP 8.2 reaches end of security support on 31 December 2026.

Why it matters

The fix does not reach everyone. Both sources say servers on PHP 8.1 or older are not expected to receive an official patch. That turns an age of software, usually a background modernisation item, into a dated exposure with a critical rating.

The patch sits below your application. Sansec is explicit that this cannot be fixed from within a store's codebase, and that application-level protections run after PHP has already handled the request. Teams that own the code but not the platform, such as agencies, retailers on managed hosting and SaaS vendors on shared stacks, depend on someone else to act.

You may not know where PHP is. Phoenix's first recommendation is an inventory of every PHP host, with version and how it serves web requests. Many organisations cannot produce one quickly, because PHP sits under content management systems, shop platforms and internal tools nobody has touched in years.

Support dates are now the real deadline. PHP 8.2 loses security support on 31 December 2026. Estates that clear this incident on 8.2 will have bought about ten weeks.

What we would do

1. Inventory every PHP host today. Record the PHP version, how it serves web requests and who owns it. Include agency-run sites, marketing microsites and forgotten internal tools.
2. Apply the interim settings now. Use the two session settings Sansec describes, check they are active in a running request, and treat them as a stopgap.
3. Patch supported branches the day the fix ships. Read PHP's own release notes, not summaries, take internet-facing hosts first, and restart PHP-FPM or the web server. If you use a managed platform, confirm in writing when the provider will apply it.
4. Decide about unsupported versions this week. Ask the provider for a backport, or restrict access by VPN or IP allowlist, or put the application behind a hardened proxy. If neither is possible, take it offline until it is upgraded.
5. Watch for compromise, not only for the patch. If any host was exposed with a vulnerable version while details were public, review web server and process logs for unexpected uploads and new processes spawned by PHP.
6. Turn the inventory into a modernisation plan. Rank each application by exposure and business value, and fund the upgrade of anything on a branch that is out of support or will be by the end of the year.

An old PHP version is a decision that gets made whether or not anyone makes it. This incident only puts a date on it.