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.