Two critical PHP flaws rated CVSS 9.2 leaked a day before the patch, and exploits are already out

The PHP project has shipped fixes for two bugs that let an unauthenticated attacker run code on a server. A leak of the CVE IDs and an accidentally published video gave attackers a head start, so admins are now racing working exploits.

The patches shipped a day early because the CVE IDs leaked

On October 21 the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical bugs rated CVSS v4.0 9.2. The first (CVE-2026-109618) appears when a request hits memory_limit at the wrong moment. PHP then treats half-initialized data as valid and corrupts memory. The second (CVE-2026-109619) leaves a fatal error pointing at memory that a previous request has already freed.

The patches were due on October 22 at 14:00 UTC. A day earlier, around 15:00 UTC, both CVE IDs surfaced on forums and social media, together with a wrong score of 10.0. According to the PHP Foundation, no technical details leaked. The project moved the release forward by a day. That evening the security firm Calif mistakenly published a video showing its proof of concept working against several targets. It deleted the video, but copies kept spreading and, according to the foundation, sped up the development of further exploits.

Apache with mod_php is in the worst position. There a single unauthenticated request can trigger the attack before any application code runs, with default settings. But every installation serving web requests is affected, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Wiz Research, one of the firms that reported the bugs, demonstrated unauthenticated attacks on WordPress, Drupal and Joomla. According to Wiz, every PHP version since 5.4 is affected. The same firm says PHP powers 70% of websites.

The bug sat in PHP for two years until frontier models cracked it open

The timeline is the most interesting part. A developer paid by the PHP Foundation found the first signs of the memory problem back in 2024. It happened during an external audit funded by the Sovereign Tech Agency and carried out by Quarkslab. Nobody knew a path to code execution at the time. The team weighed several fixes and each one broke something: compatibility, performance or third-party extensions. The foundation itself calls the delay a structural failure of a small team deciding by consensus.

The turning point came in August 2026. On August 11 Calif reported unconditional code execution with the same root cause. Wiz and OpenAI added further attack paths. Wiz says it found the first bug with its own Wiz Atlas tool and the models Gemini 4 Argon and GPT-5.6 Sol. Building the exploit, it says, means chaining several bugs and tuning them to each target's memory layout. Frontier models cut that work down to hours.

That is the second layer of the story. Exploit complexity long served as quiet protection: the bug was known, but nobody had the time to finish the job. Once a model can do that work, a theoretical bug no longer waits for years. Admins get less time between disclosure and attack, and open source projects get more work with few people. Since July 1 the PHP team has published 15 CVEs and worked through more than 100 reports that were invalid, duplicates or not reproducible.

No configuration fully protects the server

The PHP project lists temporary measures, such as disabling session.upload_progress or handling memory_limit differently. It also says none of them makes an installation safe. Only updating gives full protection. Versions older than 8.2 get no fix from the project. Anyone running them depends on backports from their distribution or a long-term support vendor. The volunteer-maintained package repository that many servers rely on had no update on release day.

For European sites the key question goes to the hosting provider. On shared hosting customers often cannot change the PHP version themselves, so the risk depends on how fast the provider reacts. Custom containers and images will not fix themselves. They need to be rebuilt and every worker restarted.

Hosting speed will show how many sites stay exposed

The first signal will come from hosts and distributions. Linux distributions and LTS vendors received the patches in advance, so they should have packages right away. Sites at slow providers will be first in line for attackers who already have a working exploit.

The second signal is long term. The PHP Foundation is asking companies that depend on PHP to help fund its security work. If AI keeps speeding up both bug hunting and exploitation, maintenance funding becomes a question of operational security. Version 8.2 also reaches end of life on December 31, 2026, so the next fix like this will miss it.

Lilith's verdict

A bug from 2024 sat in a small team's notes for two years until frontier models turned it into an exploit. Then one accidentally published video was enough for attackers to set off on the same night as the server admins.