I have seen PHP declared dead for years. What has kept me using it is the work I can do with it, the tools I rely on, and the continued development of the language.
The October 21 security releases raise serious questions about how the project handles vulnerabilities. The PHP Foundation has acknowledged failures in that process, and those failures deserve scrutiny.
I still have confidence in PHP. To explain why, I want to look at its continued usefulness and at what would need to change for this crisis to leave the project more resilient.
The language and its tools keep developing
PHP 8.4 introduced property hooks, asymmetric visibility, and native lazy objects. PHP 8.5 added a built-in URI extension, the pipe operator, and new capabilities for modifying properties when cloning objects. The official PHP 8.4 and PHP 8.5 announcements document that work.
The support policy gives teams a planning horizon: PHP 8.5 is scheduled to receive active support through December 2027 and security support through December 2029.
The frameworks are moving forward, too. Symfony 8.1 was released in May 2026 and requires PHP 8.4 or later. Symfony 7.4 LTS has scheduled security support through November 2029. Laravel 13 was released in March 2026 with a published support schedule.
In the applications I work on, I care about explicit types, testable code, predictable updates, and whether another developer can understand the system. Those are the standards I bring to PHP. A maintained runtime and framework give me a foundation on which to meet them.
The platforms matter, and so does their maintenance
MediaWiki powers Wikipedia and is written in PHP. WordPress requires PHP, and Adobe Commerce publishes supported PHP versions in its system requirements.
For me, these examples establish PHP's continuing relevance and the practical importance of maintaining it. They represent publishing, knowledge sharing, and commerce: areas where people depend on software continuing to work.
That maintenance has people behind it. In its 2025 Impact and Transparency Report, the PHP Foundation reports having 11 contracted developers working full-time or part-time at the end of the year. Their work included bug fixes, security fixes, and language development, alongside contributions from the wider community.
For organizations that depend on PHP, supporting that work is a practical reliability question. Experienced maintainers need time, resources, and continuity.
What the security crisis requires us to acknowledge
On October 21, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. Under the relevant conditions, these vulnerabilities can allow unauthenticated remote code execution. The official advisory urges users to update.
The Foundation's account of what happened explains that the first signs of the out-of-memory issue were found in 2024. It describes the delay as a structural failure involving decision-making and insufficient resources.
That is an important part of the story. As someone who uses PHP, I expect those failures to be examined and addressed.
The October 23 follow-up also matters. It describes an additional, unlikely RCE vector involving session upload progress and a particular runtime change to the session serialization handler. It provides temporary mitigation guidance pending the next regular bugfix release. Administrators should check that notice alongside the October 21 update.
These events give us concrete reasons to expect improvements in how security work is handled.
Why I believe PHP can become more resilient
The connection between the acknowledged failures and the proposed changes is what gives me grounds for optimism.
The Foundation describes changes under way in the security team's decision-making, intended to resolve difficult cases sooner and involve Foundation leadership earlier when work stalls.
Some investment was already under way before the October disclosures. In May 2026, the Foundation announced an Ecosystem Security Team, supported by an Alpha-Omega grant, to help with security reports, coordination, and work across the PHP ecosystem.
The next step is to make those improvements sustainable.
If a fix is blocked by difficult technical trade-offs, someone needs responsibility for moving the decision forward. When the team lacks capacity, sustained funding needs to translate into time for experienced engineers to investigate, implement, and review fixes.
That is how I would judge progress: whether difficult issues receive clear ownership, whether blocked decisions are escalated, and whether maintainers have the resources to follow through.
The changes are still under way. Their value will become clearer through the work that follows.
I continue to choose PHP because it is useful to me, its ecosystem keeps developing, and people are investing in its future. The recent failures make that work more urgent.
I believe PHP can emerge from this crisis stronger and more resilient if the lessons become part of everyday practice.
Top comments (5)
The support dates are the strongest argument here. Nobody schedules security patches through 2029 for a language that’s going away.
That’s a big part of it for me too. Those timelines give teams something concrete to plan around, especially when they’re building applications they expect to maintain for years. That commitment to ongoing maintenance is one of the reasons I still have confidence in PHP.
Thank you for sharing this information. I haven't read a lot about PHP but your article gave me a little bit insight of how language development works.
Thank you for taking the time to read it! I'm glad you found it useful. There's a lot of work happening behind the scenes to keep programming languages evolving and secure, and I think that work deserves more recognition.
PHP has outlived more obituaries than any language I know