Open Source Built the Internet. Who Will Keep It Secure?
The PHP security crisis of October 2026 reveals a difficult problem beneath the internet's shared infrastructure: everyone depends on it, but responsibility for securing it is scattered across people and organisations with very different resources and incentives.
In 2024, while addressing findings from an external security audit, a PHP developer discovered signs of a problem in the programming language's memory management. Several possible fixes were considered, but each threatened to break something else. The work stalled, restarted and stalled again.
Two years later, researchers demonstrated how the underlying weakness could be exploited to run an attacker's code on a vulnerable server. On 21 October 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under the CVSS 4.0 scoring system. The affected software was hardly obscure. According to W3Techs, as of 24 October 2026, PHP is used by approximately 69% of websites whose server-side programming language it can identify.
The developers had not knowingly ignored a proven critical exploit for two years. In 2024, an exploit was considered possible, but no concrete route to remote code execution had been demonstrated; that evidence emerged only in August 2026. The more revealing failure was institutional. A suspected defect remained unresolved because each correction carried serious costs, and the people responsible had no dependable means of deciding between them.
In its own account of the incident, the PHP Foundation described the delay as a structural failure involving both decision-making and insufficient resources. On 23 October, CERT-EU also reported a separate, more restricted remote-code-execution vulnerability affecting unusual configurations, for which PHP did not plan another emergency release.
For decades, the openness of shared software has been regarded as an advantage: anyone can inspect it, improve it or help repair it. That remains true. Yet the freedom to contribute does not, by itself, ensure that somebody has the expertise, authority and resources to make a difficult security decision in time. PHP's crisis is therefore about more than an underfunded programming language. It exposes the uncertain distribution of responsibility beneath much of the modern internet.
The bargain that built the internet
Few developments have reshaped computing as thoroughly as software that anyone can inspect, modify and redistribute. Linux, web servers, databases, programming languages and countless libraries made sophisticated systems available to organisations that could never have developed every component themselves. A company building a website no longer needed to invent a web server, a database or a programming language before it could begin.
Open source was an extraordinary arrangement. Developers could pool expertise without belonging to the same company; businesses could share costs even while competing elsewhere; improvements made for one user could benefit thousands of others. Independent scrutiny promised security benefits as well. Eric S. Raymond's well-known argument in The Cathedral and the Bazaar suggested that sufficiently broad examination of code would make defects easier to discover.
Yet publication is not the same as examination. Someone must know the code well enough to recognise a subtle flaw, and someone else may need the expertise to correct it without damaging everything built on top. Complex software develops its own history: old assumptions, undocumented interactions, extensions and compatibility promises. Understanding them cannot be crowdsourced into existence simply by opening a repository to the public.
There is also an economic asymmetry. The benefits of a maintained library can spread to millions of users, while its maintenance costs remain concentrated among a much smaller number of contributors. Users can enjoy the benefits of shared software without ever seeing the labour required to maintain it.
When nobody can agree on a safe fix
The PHP vulnerability identified in 2024 affected the handling of memory when a request ran into its permitted allocation limit. Under particular circumstances, an interrupted operation could leave internal data in an unsafe state. The problem lay deep inside the language, in code that many applications indirectly depend upon.
Changing it was not straightforward. One proposed approach risked breaking backwards compatibility; another introduced the possibility of denial-of-service failures; a further option could have required changes to a large ecosystem of third-party extensions. Every choice imposed costs on people far beyond the security team. A hasty change might have caused widespread damage; repeated deferral left a genuine defect in place.
At the time, PHP's security team relied on consensus. Faced with competing proposals and uncertain consequences, it struggled to choose. The Foundation has since begun changing the process to allow majority decisions and faster escalation when a technical disagreement remains unresolved. Those changes recognise a problem that additional money alone cannot solve: expert developers still need an institution capable of authorising difficult decisions.
Money nevertheless matters. In an October 2026 Reuters interview, the Foundation's executive director, Elizabeth Barron, said that the organisation had one full-time employee and fourteen mostly part-time contractors. That is the Foundation's staffing, not a count of everyone who contributes to PHP. The staffing figure still illustrates how narrowly funded one of the institutions supporting a globally important language can be.
More funding could provide experienced maintainers with time to investigate difficult problems and reduce dependence on a few individuals. Better governance could prevent unresolved technical disagreements from drifting for months. Neither substitutes for the other. A larger team without decision-making authority may still be unable to act; a decisive organisation without the necessary expertise may choose badly.
Heartbleed, XZ and the limits of trust
PHP is not the first widely used open-source project to reveal this imbalance. In 2014, Heartbleed exposed a serious flaw in OpenSSL, a cryptographic library that protected an enormous volume of internet communication. The vulnerability was a technical defect, but its discovery illuminated an institutional weakness: software of global importance had been maintained with remarkably limited funding. In response, the Linux Foundation established its Core Infrastructure Initiative, which funded two full-time OpenSSL developers and a security audit.
The XZ Utils incident of 2024 exposed a different risk. An attacker gained influence over a compression utility's maintenance process and introduced a sophisticated backdoor into releases that reached some Linux distribution channels. The attack was caught before it spread widely into production environments. Its discovery demonstrated the benefits of independent investigation, but its method showed that malicious actors could exploit maintainer trust and the pressures surrounding a small project, rather than merely exploiting programming mistakes. The Open Source Security Foundation's account describes the backdoor and its attempted distribution.
These are not three examples of the same failure. Heartbleed illustrates thinly resourced maintenance; XZ, a compromised development and trust process; PHP, the difficulty of choosing and coordinating a safe correction. Their connection lies in the concentration of crucial responsibilities within structures that can be far less resilient than the systems depending on them.
Nor do they establish that open source has become less secure than proprietary software. Commercial vendors also delay fixes, make poor technical decisions and suffer supply-chain attacks. Open source makes independent scrutiny and emergency collaboration possible in ways that closed systems may restrict. The more pertinent question is whether the organisations surrounding a critical project can exercise those advantages reliably, rather than only when a crisis forces extraordinary cooperation.
What happens when finding bugs becomes cheap?
Artificial intelligence is adding a new pressure to this arrangement. Security researchers have long used automated tools to search software for defects, but newer AI systems can help examine unfamiliar codebases, generate test cases, identify suspicious behaviour and investigate possible ways to exploit it. The same tools can assist defenders in reproducing problems, comparing reports and developing patches.
That dual use is central to the PHP story. Following further audits and AI-assisted work in 2026, researchers demonstrated the seriousness of the memory-management issue. The Foundation reported contributions from Calif, OpenAI and Wiz, alongside the use of AI tools in its own security workflow. The researchers supplied evidence of what an existing defect could actually permit, changing the urgency of the decision.
Yet a convincing-looking report is not a verified vulnerability. A model can describe a plausible attack that does not work, or produce a crash in conditions no real installation is likely to encounter. Someone still has to reproduce the behaviour, establish what an attacker controls, judge the likely impact and work out whether the proposed fix creates other failures.
On 14 October 2026, PHP security-team member Alexandre Daubois described the workload of this process. Since 1 July, the team had published fifteen CVEs and closed 106 other reports that were invalid, duplicates or could not be reproduced. These figures do not show that AI produced all those submissions, nor that the number of genuine vulnerabilities had increased by the same proportion. The difference between a reported weakness and a confirmed vulnerability consumes precisely the expert attention that is in short supply.
Three developments are possible at once. AI may generate more low-quality reports, reveal important defects that human researchers have missed, and help developers resolve those defects more efficiently. The balance between those effects is not yet established. The concern is that report volume could rise faster than the ability to evaluate those reports and safely repair genuine problems.
That capacity depends on more than processing power. In an old language with millions of deployments, a fix may require intimate knowledge of decisions made years earlier. Such expertise develops through sustained work, code review and the debugging of difficult problems. The same concern about the apprenticeship of expertise appears in an earlier essay on AI, cognitive offloading and lost expertise: some of the work AI makes easier is also the work through which future specialists learn to recognise mistakes.
If vulnerability discovery becomes inexpensive while experienced judgement remains scarce, the bottleneck could move from locating a weakness to determining what it means and removing it without creating another. That remains a plausible scenario, not a measured trend. It makes investment in maintainers and their successors more urgent even as machines become more capable.
A patch is not yet protection
Even a technically correct fix does not make every affected system safe. A vulnerability moves through several different institutions before users are protected. Researchers investigate it; maintainers verify the findings and change the code; distributors prepare packages; hosting providers and organisations deploy the updates. Each stage has its own expertise, timetable and constraints.
The October PHP release made those handoffs unusually visible. On 20 October, vulnerability identifiers began circulating publicly alongside inaccurate information about the planned release. The PHP team moved its announcement forward and advanced the scheduled fixes from 22 to 21 October. It did not simply release the patches immediately: distributors still needed time to prepare versions that administrators could actually install.
On the morning of 21 October, before the coordinated release, Chainguard published images containing the patched software. The PHP Foundation criticised the action because the corrected binaries could reveal information about the vulnerabilities while other users were still waiting for updates. The incident illustrates an uncomfortable truth of security coordination: one participant may consider rapid publication responsible while another sees the same action as exposing the wider ecosystem.
Once updates are available, deployment presents its own obstacles. Administrators must identify affected systems, test compatibility, schedule changes and account for old applications that cannot readily move to a supported version. A hosting provider may patch its platform quickly, while a business running an outdated application remains exposed. For these PHP vulnerabilities, CERT-EU advised immediate updates and noted that temporary mitigations could reduce exposure but were not equivalent to fully fixing the issues.
Open source allows these groups to cooperate without handing every decision to one vendor. Still, a correction to the source code is only the beginning of protection. What matters to an exposed organisation is whether the corrected software reaches its servers in time.
Who pays for software everyone depends on?
Behind the technical and organisational problems lies a familiar economic arrangement. Open-source software creates benefits that spread widely, while the cost of maintenance often falls on a much narrower group. An organisation may build a profitable service on shared infrastructure without paying anything directly towards its upkeep. A competitor may employ developers whose contributions benefit both of them.
There is nothing inherently wrong with this. Shared development is part of what makes open source so productive, and many successful projects receive substantial corporate contributions. The Linux kernel, for example, is not maintained solely by unpaid enthusiasts. But the distribution of funding is uneven, and dependence on a piece of software does not necessarily produce an incentive to pay for its security before something goes wrong.
Heartbleed prompted the industry to fund critical projects in 2014. Twelve years later, the same issue remains unresolved across the wider ecosystem. In March 2026, the Linux Foundation announced $12.5 million in grants, backed by major technology companies, for work on sustainable open-source security. The programme explicitly recognised the growth of AI-assisted vulnerability findings and the pressure these create for maintainers.
Grants can help build capacity, but they are not a replacement for dependable maintenance institutions. Critical projects need time for preventative maintenance, succession planning and training, not only for the weeks when a major exploit draws public attention. They need people capable of understanding inherited code and mechanisms for deciding when the risks of changing it are preferable to the risks of leaving it alone.
They also need to preserve the independence that makes open source worth protecting. Handing control of essential projects to their richest corporate users would not necessarily produce better priorities or greater accountability. The task is to combine transparent, distributed development with durable organisations: foundations, maintainers, vendors and commercial users whose roles are clear enough to support coordinated action without subordinating the project to a single sponsor.
Governments have a stake as well. Public services increasingly depend on shared libraries and languages, yet security spending often concentrates on the systems an agency owns directly. The software beneath those systems can be treated as somebody else's responsibility until a vulnerability makes that assumption untenable.
The cost of success
The October PHP response provides its own counterargument to any claim that the open-source model has failed. Independent researchers found serious attack paths. Developers worked with security firms and distributors. Coordinated patches reached all supported PHP branches. The system's openness was part of the solution.
The earlier delay exposed a weaker assumption: that openness would somehow produce enough expertise, funding and decision-making authority whenever they were needed. PHP has acknowledged that organisational failure. Turning a crisis response into a routine capability will require more than another emergency release.
Open source has never promised that code would repair itself. Its achievement is to let many people contribute to keeping shared software working. But the freedom to contribute cannot substitute for a clear obligation to decide, maintain and deploy. For software that has become critical infrastructure, the distinction is no longer theoretical: it determines how long a known weakness remains everyone's problem and nobody's responsibility.
Comments
Post a Comment