Two critical PHP vulnerabilities: impact and what to do.
A closer look at two serious flaws in PHP’s core: what they mean, how they were found and what server administrators should do.
On October 21, the PHP team announced two critical security vulnerabilities that could lead to remote code execution in some PHP setups. They appeared in big headlines, so I tried to understand what was happening technically—and how worried we should be—in plain language.
First, an important distinction: this is not a coding mistake in every PHP application. The flaws are in PHP’s own runtime, in the memory and error-handling layers it uses while processing requests. The official PHP announcement lists them as CVE-2026-109618 and CVE-2026-109619. Both are rated critical, with a score of 9.2 on the CVSS 4.0 scale.
The first flaw: an unfinished state when memory runs out
CVE-2026-109618 concerns how PHP terminates a request after an out-of-memory (OOM) condition. Some internal data may not be fully prepared while a request is being processed. If the memory limit is reached at that moment, execution stops early; during cleanup, PHP may then treat incomplete data as if it were valid.
This does not mean every memory error automatically lets someone take over a server. Timing and request-processing conditions matter. The PHP team identifies Apache with mod_php as the riskiest scenario: there is a demonstrated path to remote code execution that can be triggered before application code starts. PHP-FPM is also at risk, but the confirmed scenarios depend on specific paths in application code. Details are in PHP’s CVE-2026-109618 security advisory.
The second flaw: a trace left in memory by an earlier request
CVE-2026-109619 is a different memory bug. When a request ends with an error, some internal state belonging to it can continue pointing to memory that has already been freed. The same worker process may later handle another request and access that old state before it has been fully reset. In software security, this is called a use-after-free bug.
The PHP team says it confirmed a worker-process crash and remote code execution in a real application. Details are in the security advisory in the official source repository. The two flaws are not the same, but both are serious because they affect mechanisms PHP uses to handle requests.
What’s behind the “AI found it” headline?
One reason this story drew attention is the role of AI-assisted security research. According to the PHP Foundation, the first signs of the memory-management problem appeared during a security audit in 2024. In 2026, reports from teams including Calif, OpenAI and Wiz helped show that the issue could lead to remote code execution. OpenAI says a Calif researcher found the critical flaw using GPT-5.6 Sol, and that OpenAI independently reported the same root cause. The PHP Foundation’s account describes the process and the teams’ contributions.
It would be misleading to say “AI found and fixed the vulnerability on its own.” Researchers verified the findings; the PHP team investigated the bugs and prepared patches; other teams helped with testing and coordination. The PHP Foundation stresses that many reports were invalid or duplicates, and that people carried out the final assessment and fixes. OpenAI’s coordinated disclosure post also summarizes how its contribution fit into the process.
What should server administrators do?
The safest step is to update PHP according to the security notice from your Linux distribution or hosting provider. The PHP project released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and long-term support providers may backport patches into their own packages, so if your version number looks different, check your provider’s notice. PHP 8.1 and older no longer receive security updates directly from the PHP project, although some distributions may provide backported fixes. For the current status, see the official PHP announcement.
If you cannot update immediately, the PHP team lists some temporary configuration options. They narrow only certain attack paths and are not a substitute for moving to a patched version. Check with your system administrator or hosting provider which SAPI your server uses (mod_php, PHP-FPM, php-cgi and so on) and whether your distribution has shipped a patch. Don’t assume a random php.ini change has fully fixed the problem.
In short
This does not mean every website using PHP has been compromised. But administrators of PHP systems that handle web requests should not delay applying the patch. The broader point I take from this is that AI can help researchers spot a serious bug, but reducing real-world risk still depends on careful verification, well-prepared patches and deploying them in time.