PHP Security Flaws Put Focus on the People Who Maintain the Web

Two severe security flaws in PHP set off a race between attackers and the people responsible for fixing and installing the software. The episode also exposed a less visible weakness: keeping widely used internet infrastructure secure can depend on a small group of maintainers, including volunteers.

PHP is used by roughly 70 percent of websites, according to figures discussed by PHP package maintainer Ondřej Surý. The vulnerabilities could allow remote code execution, meaning an attacker could run their own code on a server using affected PHP software. That access could be used to interfere with a site or exploit its computing resources.

The PHP project had prepared a fix for the flaws, but information about the vulnerabilities leaked before the planned release. The project moved the release forward by a day, from Thursday to Wednesday, leaving less time to prepare. Matthew Prince, chief executive of web hosting company Cloudflare, reported a sharp increase in attempted exploitation: thousands of attempts in the 10 hours before the public announcement, tens of thousands in the first 45 minutes afterward, hundreds of thousands within two hours, and millions by the time he posted.

The work behind a fast fix

Publishing corrected source code is only one part of a software security response. Many organizations rely on installable packages: prepared versions of the software that can be deployed across servers without each team having to build PHP from source. Surý helps create and automate those packages, making it easier for administrators to apply updates across many machines.

Surý lives in Czechia and does this work as a volunteer alongside his job as director of domain-name-system engineering at the nonprofit Internet Systems Consortium. He is not employed by the PHP Foundation, which maintains the language. The PHP project invited him into a restricted group that learned about the vulnerabilities before their public release, giving him time to prepare packages in advance.

That preparation mattered because the release schedule suddenly changed. Surý told interviewer Charlie Warzel that his work was manageable because he has more than 20 years of experience and has automated many of the steps. He also had time to prepare and did not need to patch PHP on his own systems. From his perspective, the work was serious and time-sensitive, but it did not become a personal emergency.

Surý described his contribution as making the project’s source code easier to install and deploy. Administrators can use packages to update large numbers of servers without compiling the language themselves. Without his packages, people could still obtain PHP from other sources and build it, but that process would take longer and require technical skills that some teams may not have.

After the patch became available, websites began taking services offline to install it. The reported examples included sites in Germany and Finland, some hospital and school websites in Europe, and the international site 4chan. Posts on Reddit and X drew attention to Surý’s role. One software developer, Ian Landsman, wrote that much of the world’s PHP distribution depended on one person, capturing the concern that a key piece of internet maintenance rested with a volunteer.

Exposure remains while updates spread

A patch release does not mean every affected server is secure immediately. Organizations still need to identify which systems use PHP, determine how to update them, and deploy the fix. Surý said that not every installation had been updated, so the risk could persist. He also pushed back on a claim circulating online that older PHP releases could not be patched: he said there are ways to update older versions.

The possible consequences extend beyond a website being vandalized or knocked offline. Surý said attackers could use compromised servers to run a botnet or perform cryptocurrency mining. In those cases, the affected machines can be repurposed for activity that benefits the attackers. He described financial incentives behind these operations, including selling access to botnets or using server resources to mine cryptocurrency.

The reported surge in attempts shows that attackers can move quickly when details of a serious flaw become public. It does not, by itself, establish how many systems were successfully compromised. The article gives no confirmed count of affected servers or resulting intrusions. The practical concern is the interval between disclosure and installation of the fix, which can vary across a large and diverse set of organizations.

That gap is harder to close when software is old, maintenance is underfunded, or the people responsible for updates are stretched thin. Surý said older versions can still be patched if their users make the effort. His account suggests that the work is possible, but that technical ability, time, and access to prepared packages all shape how quickly a fix reaches users.

AI may speed up both sides

The vulnerabilities were found by cybersecurity researchers using a frontier model from OpenAI, according to the source account. The episode prompted concern that AI systems could help attackers find and exploit flaws faster than defenders can respond. Surý agreed that the pace is accelerating, while pointing out that security teams can also use large language models to search for vulnerabilities.

That leaves the effect of AI unsettled. Tools that help find weaknesses may aid security research and repair, while also making discovery and exploitation faster. Surý’s emphasis was on the condition of the systems those tools encounter: much of the infrastructure people depend on is taken for granted, and organizations do not consistently devote enough priority or funding to maintaining it.

He included both company systems and outdated consumer electronics in that concern. Devices that no longer receive attention can still be connected to the internet and become targets. Faster vulnerability discovery puts added pressure on the people maintaining these systems, but Surý also sees the moment as a possible prompt for organizations to take maintenance more seriously.

Surý said he is optimistic that repeated warnings will eventually change how people treat infrastructure. He described the PHP incident as one in a series of wake-up calls, rather than a one-off problem. His optimism comes with a clear condition: the current approach cannot continue indefinitely without consequences for the people doing the work and the systems depending on them.

Maintainer capacity is part of security

The attention surrounding Surý raised a straightforward question: what happens if a key maintainer becomes unavailable? He said he is considering contingency plans and is talking with Raphaël Hertzog of software company Freexian. Surý has particular experience with the packaging work, but he said Freexian has expertise that could help take it over.

That is a useful distinction between a project having a possible backup and having a fully staffed, durable maintenance system. Surý did not describe a detailed handover plan or say that all of his work already has a named replacement. His comments indicate that conversations are under way and that other expertise exists. Planning for continuity still takes time and resources.

Donations rose sharply after the vulnerability response. Surý said the contributions received in the previous 24 hours amounted to roughly a year’s worth of donations he had gathered before. He thanked those who contributed, while making clear that the money was not at the scale associated with major technology companies.

For Surý, the support also carried personal meaning. He said messages and emails of thanks helped him feel that his volunteer work had a purpose. The public attention may have made one maintainer visible, but his broader point was about the conditions facing open-source contributors. He said that work which began as enjoyable can come to feel exploitative when organizations benefit from it without adequately supporting the people maintaining it.

He wants companies that depend on open-source software to recognize the hours contributors put in and help reward that work. His concern is that an arrangement built on unpaid effort is not sustainable: people may eventually lose the motivation to keep maintaining software that many others rely on.

What users and organizations can take from it

Surý’s advice to ordinary users was to rely on the people who maintain the systems they use. For most people, responding to a server-side PHP flaw is not a matter of changing a personal setting; organizations and service providers need to update the affected software. Users who want to understand whether a particular service is affected can ask its provider or technical support team how it handles security updates.

For organizations, the episode points to practical questions: who tracks the software running on their servers, how quickly can updates be installed, and who can carry out the work if a key maintainer is unavailable? Prepared packages and automation can make updates faster, but they do not remove the need for someone to manage deployment and confirm that systems are covered.

The PHP flaws show how a serious software weakness can turn into a race once details become public. The rapid patch effort depended on the PHP project, package maintainers, and the teams installing updates. Surý’s work helped shorten that path, while the incident left a larger lesson: dependable internet services require ongoing investment in both the software and the people who keep it running.

[Matteo Wong: Read this website while you still can]

[Ian Bogost: Invasion of the self-replicating AI-malware botnet]