The PHP Meltdown Shows How AI Makes Bugs More Exploitable

The Bug Was Old. The Panic Was Brand-New.

How AI-assisted researchers turned longstanding weaknesses in PHP into an internet-wide security emergency—and exposed the shrinking distance between finding a flaw and turning it into a weapon.

There are more glamorous ways to frighten the world than a problem with PHP. A rogue satellite, perhaps. A malfunctioning trading algorithm. Something with a glass headquarters and a chief executive who wears expensive sneakers. PHP, by contrast, belongs to the internet’s utility closet: essential, ubiquitous, and generally noticed only when something has gone terribly wrong.

On October 21, something did. Government websites went dark. Hospital sites disappeared into precautionary maintenance. The Internet Archive briefly went offline. In the Netherlands, even the national cybersecurity agency took down its website—a development with the exquisite irony of a fire station evacuating because someone smelled smoke. Across the web, administrators raced to install emergency fixes for two critical vulnerabilities in one of the technologies holding their digital lives together.

The flaws became known as PHP2Shell, a name that sounds almost jaunty until one understands the proposition: under exploitable conditions, a request arriving from the internet could become a route to running an attacker’s code on a server. No stolen password necessarily required. No employee obligingly clicking a suspicious attachment. Just vulnerable software, an exposed system, and someone who knew how to make the machinery misbehave.

Artificial intelligence had helped researchers work out how.

Now defenders faced the prospect that it would help everyone else.

The Infrastructure Nobody Invites to Dinner

PHP is a server-side scripting language, which is a bloodless way of describing something that does an enormous amount of work on behalf of people who have never heard of it. A visitor requests a page; PHP helps assemble what the server sends back. It sits beneath familiar publishing and commerce systems, including WordPress, Drupal, Joomla, and Magento.

Its importance is easy to exaggerate and foolish to underestimate. Reuters, citing the web-technology tracker W3Techs, reported that PHP powered roughly 75 percent of websites whose programming language could be identified. That is not the same as three-quarters of the entire internet, although the distinction tends to disappear once a security scare acquires an apocalyptic nickname. It is, nevertheless, an extraordinary concentration of dependence.

The resulting emergency was not simply a story about bad code. It was a story about accumulated trust. Organizations had built services, revenue streams, and public obligations on software that usually worked. Its very familiarity made it recede from view.

Then came the reminder that a website is not merely its design, its content, or the executive who approved its budget. It is also a stack of dependencies, any one of which can abruptly become the most important thing in the organization.

On Wednesday, PHP moved from the basement to the boardroom.

What the Machines Actually Changed

The most arresting detail was not that software contained vulnerabilities. Software does. Nor was it that researchers used AI. By now, the appearance of a language model in a technical investigation hardly qualifies as a plot twist.

The unsettling part was the relationship between age and danger.

According to WIRED, some underlying PHP issues had been identified in 2024 but were considered too difficult to exploit at the time. Researchers at Calif subsequently developed practical exploits with help from frontier AI tools and substantial human expertise. Researchers at OpenAI and Google-owned Wiz also investigated and independently identified the flaws using AI.

That distinction matters. A weakness can exist without anyone having demonstrated a reliable way to turn it into a break-in. The gap between those two states is where much of security research happens: understanding obscure behavior, connecting conditions, testing assumptions, and determining whether an apparent dead end is actually a door.

AI did not need to invent a new category of failure. It helped skilled researchers navigate an existing one.

Sagi Tzadik, a researcher at Wiz, told WIRED that the vulnerability had been known to the PHP team for years but had not been addressed because it was not thought usable by an attacker. That account points to the incident’s central discomfort: judgments about what is practically exploitable can expire even when the software itself has not changed.

The code remained old. The capabilities brought to bear against it were new.

A Discovery, Not a Magic Trick

Every technological upheaval attracts a convenient mythology. In this one, a researcher opens a chatbot, types something like “find catastrophic internet bug,” and waits for civilization to wobble.

The actual account is less cinematic and more consequential.

Calif’s work drew heavily on researchers’ familiarity with PHP’s codebase and exploitation history. AI assisted an investigation directed by people who knew where to look and understood what they were seeing. Ryan Austin, the Calif researcher associated with the discovery, explicitly warned against the fantasy of effortless omniscience: “No model is simply capable of unearthing ‘all bugs’ with simple prompts. At least for now.”

That is not a minor qualification. It changes the story from autonomous machine genius to amplified human capability.

A powerful tool in expert hands can still shift the balance dramatically. It need not replace the researcher to increase the amount of difficult work that researcher can attempt. Nor does it need to produce a perfect exploit on command to make previously discouraging avenues worth pursuing.

The operative word is leverage.

The defenders gained it first. The anxiety was that attackers would gain it next—and that the interval between those events would prove shorter than the time required to protect everyone downstream.

The Embargo’s Awkward Social Life

Before a major vulnerability becomes public, there is often a carefully managed period of private coordination. Researchers notify maintainers. Fixes are developed. Selected organizations prepare. Everyone involved attempts the delicate trick of distributing enough information to protect critical systems without distributing enough information to accelerate attacks.

PHP2Shell entered that machinery. The PHP Foundation coordinated fixes and gave some large internet companies and hosting providers advance opportunity to prepare. Public patches arrived on October 21. techcrunch

Then there was the problem of what had happened before the announcement.

Amazon’s security chief, CJ Moses, said the company detected an exploitation attempt against a decoy system on October 17—four days before public disclosure. The activity came from an anonymous internet address. Amazon did not know how the actor had learned about the vulnerabilities, and it was initially unclear whether the attempts would have succeeded against real websites.

That leaves an uncomfortable blank, not a license to fill it with certainty.

A leak is one possibility. Independent discovery is another. TechCrunch reported that the PHP Foundation blamed one company for publishing patches hours before the embargo expired, but also noted that this would not explain Amazon’s earlier observation. The chronology resists a tidy culprit.

What it does reveal is the fragility of a security process built around synchronized timing. Information can move unpredictably. Software updates can become clues. A carefully arranged head start can evaporate.

When the Repair Becomes a Road Map

A patch has two audiences.

For administrators, it is a remedy. For attackers, it can be evidence.

When open-source code changes, observers can examine the differences and infer what the developers were trying to prevent. That does not automatically yield a working exploit. But it can narrow the search, pointing researchers—and criminals—toward the relevant behavior. TechCrunch identified that familiar dynamic as one reason disclosure and patching can intensify an attack race.

AI makes the prospect more unnerving because the same analytical assistance used to investigate a flaw can potentially help others interpret the repair.

The challenge, then, is not solved by choosing between secrecy and openness. Keeping a vulnerability quiet indefinitely leaves systems exposed to anyone who already knows about it. Publishing the remedy helps defenders while also releasing information attackers may find useful.

This tension predates modern AI. What changes is the pressure on the clock.

Once public details appeared, Cloudflare observed millions of exploitation attempts within hours, according to WIRED. The rush demonstrated how quickly attackers mobilized around the newly disclosed weaknesses. It did not, by itself, establish that every attempt worked—or that each one had been generated by an AI system.

Those distinctions are essential. An internet-wide storm of requests is not the same thing as an internet-wide takeover.

Panic Is Not a Breach Count

The first days of a security emergency produce an unusual informational weather system: urgent warnings, incomplete telemetry, vendor announcements, alarming screenshots, and claims that may be accurate only until the next update.

PHP2Shell was no exception.

WIRED reported that the PHP Foundation had not seen successful exploitation and that many publicly circulating purported exploits appeared ineffective. TechCrunch, meanwhile, reported that Palo Alto Networks and Trail of Bits had confirmed compromises and post-exploitation activity by late Friday. Both accounts stopped short of describing a demonstrated wave of mass compromise.

The responsible reading is neither “nothing happened” nor “the internet fell.”

Different observers had different visibility, and the available picture was changing. A foundation’s lack of observed successful exploitation does not establish that no victim exists anywhere. Conversely, confirmation of some compromises does not establish that every vulnerable server has been seized.

Even the outages required interpretation. Many organizations deliberately shut services down to reduce exposure while patching. Reuters documented precautionary disruptions across European public services, including Dutch organizations, Finnish government networks, and French Interior Ministry websites. A dark homepage could signify a defensive decision rather than an attacker’s victory.

For the public, the distinction may offer limited comfort. A service is unavailable either way. For understanding the incident, however, it is everything.

The Small Website’s Unfair Fight

Large companies can sometimes turn a security emergency into a logistical exercise. They have specialists, vendor relationships, asset inventories, and staff who can remain awake while other staff sleep.

The smaller operator may have a hosting dashboard and a troubling email.

Reuters noted that risks were higher for small PHP-powered sites operated by individuals or organizations with limited technical resources, particularly on shared hosting where customers do not directly control the underlying server. Automattic, by contrast, said users of its hosted solutions and Tumblr were protected.

Here the abstract language of “the attack surface” becomes a question of who has money, access, and time.

A site owner may know how to update a content-management system without knowing which PHP runtime serves it. An agency may manage the visible application while a hosting provider controls the relevant infrastructure. Responsibility is distributed, but urgency arrives as a single demand: fix it.

Reuters also cited Censys data showing that about 1.5 million of 2.6 million hosts reporting PHP versions were running versions for which no fix was available at that point. That was a measurement of observed hosts, not a census of all websites, but it illustrated the scale of the legacy problem.

An emergency release cannot instantly modernize years of deferred maintenance.

The Apocalypse Has a Marketing Department

It would be convenient for everyone selling an AI product if the lesson were simple: only more AI can save us from AI.

It would be equally convenient for skeptics if the episode could be dismissed as ordinary vulnerability research wearing an expensive new label.

Neither account quite survives contact with the evidence.

The researchers’ achievement was real. So was their dependence on expertise. The defensive coordination mattered. So did the attackers’ rapid response. The threatened catastrophe did not need to materialize at its maximum imaginable scale for the incident to expose a serious change in practical risk.

Security researchers also disagreed about what should come next. Jake Williams of Hunter Strategy told WIRED to expect more longstanding bugs to emerge, while emphasizing PHP’s unusually broad exposure. Researcher Niels Provos was more restrained, noting that highly skilled people had still been required to find this case despite sustained interest in AI-assisted discovery.

That disagreement is healthier than a prophecy. One spectacular incident cannot establish the future rate of discovery, the quality of every model-generated exploit, or the inevitability of systemic collapse.

It can establish that yesterday’s assessment of difficulty deserves another look.

The New Cost of an Old Assumption

The PHP emergency’s most important lesson is not that aging software is doomed, or that an AI assistant can effortlessly commandeer a server. It is that practical security depends partly on what an adversary can afford to figure out.

For years, complexity could function as an obstacle. Not a guarantee, not a fix, but a barrier between a known weakness and a usable attack. PHP2Shell showed researchers using AI assistance to help cross that distance. Then came the scramble to patch, the surge of hostile attempts, and the uncertain accounting of what had actually been breached.

The internet did not suddenly become fragile on October 21. Its dependencies were already there, along with its maintenance backlogs and unevenly distributed resources.

What changed was the price of asking harder questions of old code.

For the organizations that rely on that code, the uncomfortable possibility is that “too difficult to exploit” has become a temporary description—not a durable defense.