The PHP Security Wake-Up Call: Fixes Are Only the Beginning

By Jeff Borek and Mike Linksvayer Recent PHP vulnerabilities highlight why open source security requires sustained investment and action from everyone who builds on it.

PHP, an open source programming language, powers roughly 70% of websites whose server-side language is known.

On October 21, 2026, the project released security updates for two critical vulnerabilities that could, under certain conditions, allow unauthenticated attackers to execute code on servers running PHP. Much of the attention has focused on how those vulnerabilities were discovered, disclosed, and fixed.

But the organizations incorporating that software into products and operating it in production are equally important to the outcome. A coordinated security release is a critical milestone. It is not the finish line. A vulnerability remains a risk wherever affected software continues running without an effective mitigation or update.

For the Open Source Security Foundation (OpenSSF), the policy lesson is clear: investment in upstream security and responsibility for downstream deployment must advance together. Governments have important roles in both as funders, software consumers, participants, and policymakers.

Shared code, distinct responsibilities Modern products and services reuse common components, from libraries to runtimes such as PHP, across both open source and proprietary applications. A security improvement in one widely used component can benefit many organizations simultaneously, but only if it reaches the systems that depend on it. Maintainers develop and release fixes.

Distributors and product vendors incorporate them into supported products and services, communicate actionable guidance, and make secure configuration and updating practical by default. Operators assess exposure and deploy appropriate mitigations and updates.

These roles overlap, but they are not interchangeable: upstream developers generally do not control downstream deployments, and customers should not need specialist expertise to compensate for avoidable weaknesses in the products they use. This is why OpenSSF’s 2023 response to the U.S. Office of the National Cyber Director (ONCD) made accelerating the uptake of fixed components its first priority.

Improving software at the source and protecting running systems are complementary responsibilities. PHP shows what sustained investment makes possible On October 21, 2026, the PHP project released updates addressing two critical vulnerabilities that could, under certain conditions, allow attackers to execute code on affected servers. The PHP Foundation’s account explains the sustained work behind that release.

Follow-up work from a 2024 security audit funded by Germany’s Sovereign Tech Agency surfaced early signs of the underlying problem behind one vulnerability. Developing a safe fix required deep expertise and difficult choices involving compatibility, reliability, and third-party extensions. The Foundation candidly identifies both resource constraints and weaknesses in decision-making.

It also describes how funded engineers made intensive remediation and coordination possible. That experience supports a practical investment agenda: fund not only audits and discovery, but also the expertise, testing, decisions, and maintenance needed to resolve findings safely. As the Sovereign Tech Agency argues, sustained investment can also support preventative improvements that reduce future vulnerability risk.

The next stage is just as consequential. Vendors, hosting providers, public institutions, and other operators must get those fixes into the systems they deliver and run. Coordination and AI should improve the whole security lifecycle AI is accelerating vulnerability discovery for defenders and attackers alike.

It can also help validate findings, develop patches, improve tests, and prevent vulnerabilities. Realizing those benefits requires investment across the security lifecycle, not simply more scanning. As Red Hat’s discussion of responsible disclosure emphasizes, trusted coordination helps maintainers, distributors, and operators prepare defenses.

Well-supported coordination reduces duplicated effort and avoidable disruption; effective deployment turns that preparation into protection. OpenSSF provides practical ways to strengthen this work. Alpha-Omega, an associated project of OpenSSF, funds and catalyzes sustainable security improvements in critical projects and ecosystems.

Complementary efforts such as Akrites bring industry participants together to coordinate vulnerability discovery, remediation, and disclosure with upstream maintainers, with the stated goal of measuring success in patch deployment rather than publication.

OpenSSF’s coordinated vulnerability disclosure guides help researchers and maintainers navigate response, while its new guide to finding and fixing vulnerabilities using AI covers validation, remediation, verification, deployment, and prevention. These efforts connect investment, engineering practice, and collaboration.

OpenSSF’s policy work brings that operational experience into conversations with governments about how to achieve better security outcomes. Five practical steps for policymakers 1. Invest in shared security infrastructure Support sustained maintenance, security engineering, audits, testing, and coordinated response in widely used open source projects.

Fund follow-through on findings as well as discovery. OpenSSF’s recent recommendations to NIST call for interoperable vulnerability information and coordination so organizations can reliably determine whether they are affected, identify the appropriate fix, and connect that information to their security and remediation tools.

Improvements to shared infrastructure can deliver benefits across government, industry, and society. 2. Lead as responsible software consumers Governments should understand their dependencies, maintain supported systems, and deploy updates according to risk. Procurement should assess suppliers’ ability to maintain and update the software they deliver, including its open source dependencies.

Seek risk-based evidence from suppliers while avoiding duplicative requirements or compliance demands passed through to community maintainers. The objective is demonstrably safer systems, not simply more documentation. 3. Participate upstream Enable public-sector teams and encourage commercial users to contribute funding, engineering expertise, testing, and fixes.

Engagement should follow project processes and reduce maintenance work rather than create additional demands. OpenSSF’s Concise Guide for Collaborating with Open Source Projects provides practical guidance for organizations building these relationships.

4. Allocate responsibilities according to control and capability Manufacturers, commercial integrators, and operators control how software is selected, configured, supplied, and deployed. Policy should reflect those roles rather than allowing obligations to roll upstream to volunteer or non-commercial maintainers merely because others depend on their code.

Align security requirements internationally to support shared improvements and avoid conflicting obligations that fragment the global software ecosystem. OpenSSF’s Public Policy Primer sets out this distinction and governments’ complementary roles. 5. Raise the security baseline Support research, open tooling, workforce development, and technologies that make software secure by design and default.

AI-assisted engineering and practical transitions to memory-safe technologies offer opportunities to prevent classes of vulnerabilities, not only respond to individual findings. Public and private investment can make these capabilities accessible to more projects. Turn this moment into lasting progress The opportunity is larger than responding to the latest emergency.

Shared investment can strengthen widely used software once and benefit many users; responsible consumption ensures those improvements reach production. OpenSSF brings together maintainers, security practitioners, industry, and public-sector participants to advance that work.

We invite policymakers and organizations that depend on open source to help shape the conversation at our planned Washington, D.C., Policy Summit in spring 2027 and through our continuing engagement in Europe and other regions. Follow our policy work and upcoming events, or get involved directly. The goal is not simply to find and publish more vulnerabilities.

It is to make the software we share, and the systems everyone depends on, more secure. About the Authors Mike Linksvayer is Vice President of Developer Policy at GitHub, where he leads global advocacy for developers and open source collaboration. He co-chairs the OpenSSF Public Policy Committee and is a Fellow at Open Forum for AI.

His experience spans over two decades in open technology and culture, including as Vice President and CTO of Creative Commons. Jeffrey Borek is a WW Sr. Program Director of Open Technologies and AI Supply Chain Security at IBM. He chairs the Governance Committee at the Open Source Security Foundation and is also active in the Agentic AI Foundation and the Coalition for Security AI (CoSAI) at OASIS Open.

He also guides the open source agentic MCP gateway project ContextForge, and frequently promotes the concepts of open source AI as an international speaker.