PHP2Shell and the Math of Vibe Coding Your Own Software

The value proposition from vibe coding businesses and LLM developers is that everyone will be able to make their own software easily. PHP2Shell, the pair of critical PHP flaws patched on October 21, 2026, is a good reminder that there is a lot more to the software industry than the creation of the initial software. I put the published numbers into a simple model. In that model, shared open source costs roughly 2,000 times less than a world where every user writes their own copy. LLMs do not close that gap except for very small pieces of code.

What is PHP2Shell?

PHP2Shell is the name for two vulnerabilities in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2. Datadog Security Labs reproduced both flaws and confirmed that application-level authentication cannot block the attack, because PHP processes the malicious request before any application code runs.

The flaws affect PHP versions 5.4 through 8.5, so the bug class dates from 2012. According to W3Techs, PHP runs about 69% of the websites whose server-side language is known. That share includes WordPress, Drupal, Joomla, web-hosting control panels, and vendor appliances. Attackers used the flaws against Palo Alto Networks management interfaces, which most owners probably did not consider PHP servers.

A researcher at Calif found the flaws as part of OpenAI's Patch the Planet project, and Wiz found them independently. Both teams used LLMs in the search. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 26. Amazon Threat Intelligence found an exploitation attempt from October 17, four days before the public disclosure.

Was PHP the only problem in October 2026?

PHP was not the only problem. The press now calls the month Black October. In the same week:

• Node.js shipped a fix for CVE-2026-111497, an out-of-bounds write in the Brotli decoder that Node.js bundles. People call it Node2Shell.
• Attackers published a malicious version of LiteLLM, a Python gateway for LLM providers, to PyPI. The package stole credentials and API keys, and it stayed on PyPI for 1 hour and 44 minutes.
• Eight intermediate certificate-authority keys from eMudhra were weak enough to recover. The incident triggered updates in Java and Python trust stores.
• GitLab fixed a remote-code-execution flaw in self-managed instances.

Microsoft's guidance lists PHP, Node.js, .NET, Java, PowerShell 7, Visual Studio, Git for Windows, and container images as software that customers must patch themselves. None of these issues started in Microsoft code, and all of them required work from Microsoft and from every customer.

These vulnerabilities in Node.js, Python, PHP, Java and others show that software, like art in the saying often credited to Paul Valéry, is never finished, only abandoned. Once you create and run software, you also create a security attack surface for malicious users.

Who fixed PHP2Shell?

The response to PHP2Shell shows how shared maintenance works:

1. Two research teams found the flaws and reported them.
2. The PHP maintainers wrote the fixes and released PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
3. Distributions such as Ubuntu, cPanel and CloudLinux built and shipped packages.
4. Ondřej Surý, a volunteer maintainer, built installable packages for old PHP versions that no longer get official releases.
5. Cloudflare deployed rules in its web application firewall for all customers, free plans included.
6. CISA, the NSA, the UK NCSC, CERT-EU and other agencies published advisories.

For most site owners, the result of all that work was one package update and one restart.

The team at the center of that chain is small. The PHP Foundation has one full-time staff member and 14 mostly part-time contractors, and it runs on about $974,000 a year. xkcd 2347 drew this situation in 2020.

The shared model also failed on PHP2Shell. A PHP core developer found the out-of-memory bug behind one of the flaws during a 2024 audit. The team could not agree on a fix, and nobody had shown a working exploit, so the bug stayed in the code for two more years.

How many packages does a typical application use?

Black Duck's 2026 OSSRA report audited 947 commercial codebases. The report found the following:

• 98% of the codebases contain open source.
• The average codebase contains 1,180 open source components, 30% more than the year before.
• The mean number of known open source vulnerabilities per codebase rose 107%, to 581.
• 92% of the codebases contain components that are four or more years out of date.
• 93% contain components with no development activity in the last two years.

Black Duck links the growth in files and components to AI coding assistants. Vibe-coded software does not remove dependencies. A 2025 study of LLM-generated imports found that LLMs mostly prefer third-party libraries over the standard library. A plumber's vibe-coded app still runs on PHP or Node.js, and it still uses packages. The LLM adds a new layer of code that only the plumber owns, on top of the shared stack.

Who maintains a vibe-coded app?

Imagine the shared applications that people use today replaced by their own vibe-coded apps. Who is going to do the security maintenance, the patches and the updates?

Is a plumber who vibe-coded an accounting app, a receipt tracker, a job to-do tracker and a customer scheduling app going to also be a cybersecurity team and patch all of these projects?

Will AI agents do all of this work, like gardeners who tend a custom garden of software tailor-made for each individual human?

Who pays for those agents, and who checks their work?

Software engineering research has an old answer about how much of the work comes after the first release. Meir Lehman's laws of software evolution (1980) state that a program in real use must change continually or it becomes less useful, and that its complexity grows unless someone works to reduce it. Robert Glass, in Facts and Fallacies of Software Engineering (2002), puts maintenance at 40% to 80% of total software cost, with an average of 60%. At the average, the maintenance over a program's life costs 1.5 times as much as the first build.

The pressure for change comes from outside the program. PHP 7.4, 8.0 and 8.1 got source patches for PHP2Shell but no official binaries, because those versions are end of life. Tax rules change for the accounting app. Browsers change for the receipt tracker. These changes arrive on their own schedule, and a low cost to write the first version does not delay them.

What does the math say?

Write once, or write everywhere?

Manuel Hoffmann, Frank Nagle and Yanuo Zhou estimated the answer to this question in The Value of Open Source Software (Harvard Business School, 2024). They used the COCOMO II cost model and global wage data to produce these estimates:

• Supply side: one rewrite of the widely used open source packages would cost about $4.15 billion.
• Demand side: if every firm that uses those packages had to write its own copy, the cost would be about $8.8 trillion. Firms would spend 3.5 times more on software than they do now.

The ratio of the two numbers is the duplication factor:

$$\text{duplication factor} = \frac{\$8.8 \text{ trillion}}{\$4.15 \text{ billion}} \approx 2{,}120$$

On average, firms would write each widely used package about 2,120 times if nobody shared it.

LLMs change two inputs in this model. Let f be the factor by which an LLM cuts the cost to write code. Let s be the fraction of a package that one user needs, because a custom copy only has to do what that user wants. The cost of the bespoke world relative to the shared world is then:

$$R = \frac{2{,}120 \times s}{f}$$

Fraction needed (s)	LLM cost cut, bespoke code only (f)	Bespoke cost / shared cost (R)
1	1	2,120
1	100	21
0.1	100	2.1
0.01	100	0.21

The table assumes that only the people who write their own code get the LLM discount. Maintainers of shared projects use the same tools. If the discount applies on both sides, f cancels and R = 2,120 × s. Bespoke code then breaks even only when a user needs less than about 0.05% of the package. Glass's maintenance share applies to both sides too, so the ratio holds for lifetime cost as well as for the first build.

The model also says where the write-it-yourself argument is correct. For very small pieces of code, s is tiny and the custom copy can win. The left-pad incident of 2016 is the classic example of a dependency too small to justify its risk.

How many vulnerabilities does a vibe-coded app ship with?

Veracode tests LLMs on security-relevant code tasks. In its Fall 2026 update, 38% of generated outputs contained a vulnerability, down from 44%. The best models passed about 73% of the tasks, so they failed about 27%.

Take the plumber with 4 apps. Assume each app has 5 security-relevant parts, for example a login, a file upload, a database query, a form and a payment link. The 4 apps then contain 20 tasks. If p is the chance that one task produces a vulnerability, and the tasks are independent:

$$\begin{aligned} P(\text{one app clean}) &= (1 - p)^{5} \\ P(\text{all 4 apps clean}) &= (1 - p)^{20} \\ E[\text{vulnerable parts}] &= 20 \times p \end{aligned}$$

Model	p	Chance one app is clean	Chance all 4 apps are clean	Expected vulnerable parts
Average	0.38	9.2%	0.007%	7.6
Best	0.27	20.7%	0.18%	5.4

The plumber almost certainly ships at least one vulnerability. Nobody else reads the code, so nobody else will find it before an attacker does. The exact values are rough, because they come from benchmark tasks, and real tasks are not independent.

Who watches each codebase?

Let N be the number of people who need the same software, M the yearly cost to maintain one codebase, and u the cost for one user to apply an update:

$$\begin{aligned} \text{shared:} \quad & \text{total} = M + N u, & \text{per user} &= \frac{M}{N} + u \\ \text{bespoke:} \quad & \text{total} = N M, & \text{per user} &= M \end{aligned}$$

With shared code, the maintainers fix each vulnerability once. A CVE announces it, the distributions package the fix, and each of the N users applies one update. With bespoke code, the same work happens N times, and none of it is visible. A vulnerability in the plumber's receipt tracker gets no CVE, no CISA catalog entry, no NSA advisory and no free Cloudflare rule.

The cost of the shared fix per user also falls as N grows. Take one million organizations that depend on PHP as an example. The real count is probably higher. At one million, the PHP Foundation's budget is less than $1 per organization per year. The plumber's own maintenance cost does not fall when more plumbers exist.

AI also changed the attacker's side. Two teams found PHP2Shell with LLM help in a codebase that people had read for decades. The same class of tool can scan thousands of small bespoke apps for little money. Defensive programs such as Patch the Planet aim at shared projects that many people use. A bespoke app gets attention from attackers and from nobody else.

What about the argument to write it yourself?

On X, some people now argue that LLMs make it cheaper to write code yourself than to use open source libraries. Eugene Marinelli, the CEO of Realm Alliance, wrote on October 31: "Open source libraries are a dying idea." His reason is that a library needs constant upgrades for vulnerability patches, so it costs more than an LLM-generated copy of the small part you use. The part you use is the s in the model above. My reply to him was:

I mean... who's going to be patching your own libraries?

Open source crowdsources the maintenance work. Instead of having to patch my own generated code, I can pull patches that someone else created.

It's the evolutionary advantage of social species in digital form

Generated copies work for simple libraries.

The zerodep project used LLMs to rewrite 44 popular Python libraries with only the standard library. The single-file modules cut the installed size from a median of 700 KB to 31 KB. The rewrites removed 88 transitive dependencies that 128 different PyPI accounts maintain, and fewer dependencies mean less supply-chain risk. The authors also cite the Commit0 benchmark, where fully automated LLM rewrites passed about 80% of tests on simple libraries, less than 20% on medium ones, and almost none on networking, cryptography and protocol libraries. Parsers, protocols and cryptography are the places where remote-code-execution bugs usually occur. zerodep is also an open source project that other people can use, so its authors chose to share their work too.

Shared code also creates a monoculture. One flaw in PHP put about 69% of websites with a known server-side language at risk on the same day. A bespoke app does not share its own bugs with anyone. The bespoke app also runs on the shared runtime, so the plumber's app was exposed to PHP2Shell like every other PHP site, and it carried its own bugs in addition. The Log4j review board called Log4Shell an endemic vulnerability that could stay in systems for a decade or longer. Shared failures are visible, and the fix is shared too.

What does vibe coding do to the people who maintain shared code?

Economists Miklos Koren, Gábor Békés, Julian Hinz and Aaron Lohmann model this question in Vibe Coding Kills Open Source (2026 preprint). In their model, vibe coding raises productivity. The AI agent picks and assembles the packages, so users no longer read the documentation, file bug reports or talk to maintainers. Many maintainers earn their returns from that engagement. When engagement is the only way maintainers get paid, more vibe coding means fewer new projects, lower quality and lower total welfare, even with the higher productivity.

The model fits older work. Josh Lerner and Jean Tirole argued in Some Simple Economics of Open Source (2002) that reputation and career benefits explain much of why developers contribute. Nadia Eghbal's Roads and Bridges (2016) described the volunteers who maintain public code with little institutional support. Commentary in The Guardian compared the PHP Foundation's small staff with the billions of dollars that fund the AI research that found the flaws. A vibe-coded app uses that shared base and contributes nothing to it.

Stand on the shoulders of giants

Dwarf on the shoulders of a giant, from an encyclopedic manuscript, southern Germany, about 1410. Library of Congress, Rosenwald Collection, ms. 4, fol. 5r. Public domain, via Wikimedia Commons.

Isaac Newton wrote in 1675 that if he had seen further, it was "by standing on the shoulders of Giants." He borrowed the image from Bernard of Chartres, who used it in the twelfth century. The giants in software are the maintainers of PHP, Node.js, OpenSSL and the rest of the 1,180 open source components in an average codebase. The HBS paper found that about 5% of open source developers create more than 90% of the value.

The math favors shared software. The bespoke world asks each of 8 billion humans to pay for a suite of AI agents that run and maintain a highly redundant suite of apps. A human confederation that reuses open source or paid software, which specialized vendors and maintainers manage, is more efficient, and the industry already works this way. The better use of LLMs is to make the giants taller. LLMs can help maintainers find and fix bugs, and we can pay the maintainers for that work.

The Latin text next to the giant in the manuscript makes the same point. In the Wikimedia Commons translation, our elders had the appearance of giants, and we can equal them if we study their teachings with good sense. A software update works the same way, because it delivers what other people learned about a bug. A vibe-coded copy of everything asks each of us to climb down from those shoulders and stand alone. On the ground, each person has to find every bug in their own code. The LLM that helps with the search costs tokens, time and energy, and each person pays that cost alone, once for every copy.