What the PHP crisis taught me: Security is a shared responsibility

The recent PHP vulnerabilities should make everyone who develops software or runs servers reconsider their responsibilities. When we put a working application online, we also take responsibility for maintaining it and protecting the data people entrust to us. Users bear the consequences when security is treated as something to revisit only if a problem appears after delivery.

The contributions of teams such as OpenAI, Calif, and Wiz to investigating these vulnerabilities are valuable. Faster security research with the help of AI is an important development too. However, the PHP Foundation’s account of the disclosure process also describes serious coordination problems.

According to the PHP Foundation, Calif accidentally published a video demonstrating a working attack. Although it was subsequently deleted, copies circulated. Chainguard released built images containing the security fix more than six hours before the coordinated disclosure time. This made the fix available for inspection while users of other distributions were still waiting for their updates.

I expect organizations discovering vulnerabilities and distributing fixes to take responsibility for the whole process. The success of security research cannot be measured by showing a working attack video. Getting the fix to people safely, in a form they can actually deploy, is part of the work. At this scale, even an accidental publication can have serious consequences, and that needs to be accounted for.

Amazon / AWS’s findings also show why timing matters. AWS reports identifying an exploitation attempt dating back to October 17, before the public disclosure on October 21. That means an investigation starting only on the announcement date could miss earlier activity. However, this observation does not establish that the first attempt resulted from publications by Calif or Chainguard. We need to keep the chronology and the evidence clear.

I also consider it important that the PHP Foundation addressed delays on its own side. The foundation describes problems with decision-making, a limited number of specialists, and insufficient resources. Infrastructure this important needs a structure that prevents difficult decisions from remaining unresolved for months.

Companies and public institutions have questions to ask themselves as well. We use PHP to provide services, conduct business, and generate revenue. How much do we contribute to maintaining that infrastructure, researching its security, and developing the necessary expertise? If open source saves us licensing costs, we should discuss putting some of those savings toward sustaining its ecosystem. Expecting continuous security without budgeting for the people who deliver it is not sustainable.

As someone who runs systems, I want concrete answers: Which application runs on which server, and which PHP version does it use? Has the fix actually reached the service handling requests? If containers are involved, has the updated image been deployed? Was the application checked after the update? Has earlier suspicious activity been investigated? A successful update command does not answer all of those questions.

Technical guidance also needs to be precise. Fixes for these two vulnerabilities were released in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Teams should verify the release appropriate to their branch, or the package into which their distribution provider has backported the fix. Giving everyone a single version number does not adequately describe the situation across different systems.

We cannot expect end users to install a PHP update on their phones. But they are entitled to ask how the services they use protect their data. Preserving that trust is a shared responsibility for developers, system administrators, service providers, and the management teams deciding their budgets.

The cover and the presenter video in the Turkish edition are AI-generated illustrative content.