On Wednesday, 21 October 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These versions fix two critical vulnerabilities in memory management and error handling, parts of PHP that nearly every request touches. If you run PHP and have not updated yet: please do it now.
The underlying problem stayed unsolved for too long, and the PHP Foundation itself says why: the security team's decision process held the work up, and the team lacked the resources. The hate that is being poured over PHP these days changes nothing about the second reason; broader funding of the work on PHP would.
The Foundation names the failure itself
In its post on this release, the PHP Foundation describes how the vulnerabilities were found and fixed, and it is open about what did not go well. The first signs of the problem were found as early as 2024, during an external security audit, but without a concrete attack vector. Every possible fix came at a price, the security team decided by consensus, and only a few people know the engine in enough depth. So the fix stalled, and the Foundation calls that a structural failure.
From 11 August, the fix was the top priority for everyone working on security at the Foundation, eventually on weekends and around the clock as well. It is now available for all supported branches. For the decision process, the Foundation announces changes so that security decisions can be made by majority in future.
I am grateful to everyone involved: the PHP security team, the release managers, the package maintainers at distributions and LTS vendors, and the security researchers who reported their findings responsibly. I particularly thank Volker Dusch, Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche.
The embargo did not hold until the release
I am annoyed that the coordinated disclosure was disrupted in the final stretch. The CVE IDs circulated two days before the planned date with wrong information about the time and the severity, and the project then brought the release forward by a day, to Wednesday. One of the reporting companies accidentally published a video of its proof of concept. A vendor of container images made images with the fix available more than six hours before the release and thereby broke the embargo. That devalued weeks of careful coordination between many parties.
Security needs more people who know the engine
What annoys me even more is that the occasion was used to pour hate over PHP: over the language, over the people who work on it, and over those who use it. Every piece of software of this size and age has vulnerabilities. What matters is how they are handled. In this case there is something to criticise about that, and the Foundation has done so itself.
I see no point in defending PHP. I would rather look at what the language is today, and I did that twice this summer: in Four out of five against the criteria of modern language design, and in A language has non-functional requirements, too against the criteria on which architecture decisions are actually made.
The second article also covers how much of the paid work on PHP depends on a small number of sponsors. The eleven developers contracted by the Foundation authored roughly 42 % of all commits to php-src in 2025, and the sponsor count fell year on year. The Foundation's post arrives at the same observation from the side of security: the security work on PHP depends on a small group of developers paid by the Foundation and a little volunteer help.
This brings us back to the delay since 2024. A fix in the memory management of the engine can only be written and reviewed by people who know that engine in detail. Such knowledge grows over years of work on php-src, and today the Foundation pays for a large part of that work. At the end of its post, it therefore asks companies, hosting providers, cloud platforms, distributions and governments to fund it.
I serve on the board of the PHP Foundation, so you can read this request as mine as well. If your company makes money with PHP, support the Foundation. Then, when the next problem of this kind comes along, more people will be there who can fix it before someone from outside demonstrates an attack vector.
