Summary
CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10, let an attacker run code on a PHP server remotely, without logging in. I use their timeline to separate three steps that are easily confused: finding a defect, understanding how it could be exploited, and demonstrating the attack. According to SentinelOne, a 2024 audit had flagged a weakness in out-of-memory handling without proving it exploitable. In August 2026 Calif, a security research lab working with an OpenAI model, found a path to code execution, and Wiz Research found the same flaws independently a few weeks later. A leak then forced an early release of the fix, on 21 October. The article ends with what to patch, how to cover versions PHP no longer maintains, and which interim measures reduce exposure without making a server safe.
Key ideas
- Spotting dangerous behaviour in code does not mean knowing how to turn it into an actual breach: the 2024 audit stopped at that first step.
- AI shortened the path from hypothesis to demonstrated exploit, but it replaced neither testing, nor coordination, nor validating the fix.
- The danger came from two defects combined: memory corruption when a request exceeds its memory limit, and a request’s state reused after its memory was freed, a use-after-free.
- The absence of a known exploit is no lasting guarantee: the flaws affect PHP back to version 5.4, over ten years of releases, and a new method can quickly change how the risk of an old flaw is assessed.
- Finding the flaw is only part of the work: disclosure must be coordinated, patches prepared, users informed and exploitation limited in the meantime, even when a leak sets the timetable.
Why I wrote this
A vulnerability is not necessarily new when it becomes critical; sometimes what has changed is our ability to understand its consequences. For organisations using PHP, the priority is to check the versions actually deployed, apply the official fixes and assess what is exposed in production.