Found Five Times, Fixed Once: What PHP2Shell Says About AI Bug Hunting

PHP2Shell is a pair of critical bugs in PHP, the programming language running underneath WordPress, Drupal and roughly 70% of websites whose server-side language is known. A single crafted web request, with no login, can let an attacker run their own commands on the server. Fixes shipped on October 21, and almost no servers had installed them a day later.

The weakness behind PHP2Shell kept getting found. Its corner of PHP was flagged in 2004, 2020 and 2024, and two separate research teams proved it could be exploited this August, both working with AI models. The fix then took 71 days to go from first report to public release, and an unknown attacker was already using the bug four days before that. AI made finding and proving bugs cheap and parallel. Fixing them is still one slow queue run by a small foundation, and that queue hasn't sped up at all.

What PHP2Shell does, in plain English

PHP is the engine. A WordPress or Drupal site is code that runs on top of it. PHP2Shell lives in the engine, so the site's own code can be perfect and the server is still exposed.

There are two separate flaws, tracked as CVE-2026-109618 and CVE-2026-109619 (a CVE is the public ID number every known vulnerability gets). In the first, a request that pushes PHP past its memory limit makes PHP abandon the request halfway through setting it up, and the cleanup step then works on half-built internal data. In the second, certain errors leave PHP holding pointers to memory it has already released. A skilled attacker can steer either broken state into running their own code, or into leaking secrets like passwords and keys out of server memory, according to Wiz's write-up.

Both fire before any website code runs. PHP rates them 9.2 out of 10 on CVSS, the industry's standard severity scale. Every PHP version back to 5.4, released in 2012, is hit by at least one of the two. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which covers only the four branches PHP still supports.

How many times was PHP2Shell found?

Five, by a loose count, and six if you include the attacker. Calif, the security research firm credited with the 2026 discovery, lays out the history in its own write-up:

• 2004. Stefan Esser finds the first PHP memory-limit remote vulnerability. Same corner of the engine, earlier bug.
• 2020. PHP bug #78876 reports long variables running PHP out of memory.
• 2024. An external audit paid for by OSTIF (a nonprofit that funds security reviews of open-source projects) and carried out by the security firm Quarkslab flags a related issue, but "exploitation was not proven." A PHP core developer finds the memory-handling bug itself while fixing one of the audit's findings.
• August 1, 2026. Ryan Austin at Calif finds the first remote-code path using a generally available OpenAI model.
• August 19, 2026. Wiz Research, the research arm of the cloud security company Wiz, finds it independently and has working takeovers of Drupal and WordPress by August 21.
• October 17, 2026. Amazon's honeypots, decoy servers built to attract attackers, record an exploitation attempt, four days before disclosure.

Viral posts this week counted three independent teams, but Calif did its work inside OpenAI's Patch the Planet program, so that's one effort counted twice. Two teams proved it within three weeks of each other, after the bug sat in plain view for years. The code barely moved between 2024 and 2026. Proving the bug went from a theory nobody built to a few days of work.

What AI changed: the cost of proof

In 2024, PHP's security team knew about the memory-handling flaw. No one found a working exploit, and the work was deprioritized, according to The Next Web's reconstruction. A suspected bug with no working attack sits in a long line of other suspected bugs.

Two years later, Calif's researcher had a working path in days. Calif is specific about the tooling:

"No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery."

Calif, October 2026

Wiz, working with its own Atlas system plus Gemini 4 Argon and GPT-5.6 Sol, describes the chain as "at the edge of what human researchers could practically achieve," a barrier it says frontier models substantially lowered.

Worth being clear on what the AI did and didn't do. Calif's own post pushes back on the five-words-into-a-chatbot version: "No model is simply capable of unearthing 'all bugs' with simple prompts." Austin aimed the model using his own catalog of PHP's past bugs. So this was an expert working with a model, and the pairing collapsed months of proof work into days. That's enough to change the math. If one expert can do it in days, two teams can do it in the same month, and so can anyone else who points a model at the same old code.

Finding a bug is a search problem, and search parallelizes. Fixing one runs through a single team that has to agree on a single patch.

Why did the PHP2Shell fix take 71 days?

Calif reported the first bug to PHP on August 11. The public fix shipped October 21, 71 days later. Wiz's timeline puts the start of PHP's coordinated fix work on September 21, a month after the second report came in.

The delay traces back to 2024. PHP's security team built several competing fixes for the memory-handling flaw, and each one had a cost. One broke backward compatibility. One added a denial-of-service risk. One required changes to thousands of third-party extensions. The team decided by consensus, worried about shipping the wrong fix, and the work stalled and restarted for months. The PHP Foundation's own verdict:

"We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."

PHP Foundation, via The Next Web, October 2026

That team is small. Wikipedia's entry, citing The Guardian, puts the foundation at about 13 full- and part-time employees. It created an Ecosystem Security Team in May 2026 and hired two engineers over the summer. That's the whole fix side for the engine under roughly 70% of websites with a known server-side language.

Any number of teams with models can search the same code at the same time, and every one of them shortens the odds of a find. Only one group can ship the fix. It has to pick one approach that won't break every plugin and extension built on PHP, test it across every supported branch, and release it once. A model can draft a patch, but a handful of people still have to choose which compatibility break the whole ecosystem eats.

The fix side did get some speed from automation this round. Chainguard, which builds hardened container images, published fixed images about six hours before disclosure, per The Next Web, and a model can draft a candidate patch in minutes. Those gains land after the decision. The slow part in 2024 was choosing among candidate fixes that each broke something, and that choice stayed open until outside researchers proved the bug could be exploited.

Even the release date wasn't PHP's choice in the end. On October 20, the two CVE numbers started circulating on forums with the wrong severity and the wrong release time. That evening, Calif accidentally published a proof-of-concept video. Disclosure moved up a day.

The embargo held until someone else found the bug

An embargo is the quiet period when researchers and maintainers keep a bug secret while the fix gets built. It only works if nobody else finds the bug in the meantime. Amazon's threat intelligence team, writing up the October 17 attempt it caught, put it in one line:

"An embargo protects defenders only until someone else finds the same bug."

Amazon Threat Intelligence, October 2026

The same post says "the time from patch to working exploit is shrinking for structural reasons," and tells defenders to investigate PHP2Shell activity from at least October 17, four days before anyone outside the embargo knew to look.

Calif's CEO, Thai Duong, saw the next step coming before release day: "Some dude on Twitter could take the patches and run AI against it and post some exploit script. All hell will break loose," he told reporters, per the WSJ/Reuters wire.

Then the volume hit. Cloudflare's CEO said the company saw thousands of attack attempts in the 10 hours before the announcement, tens of thousands within 45 minutes after, and millions by that evening, per SecurityWeek and Fortune. Cloudflare had blocking rules live for every plan about 9 hours before disclosure, by Cloudflare's count.

To be fair, attempts aren't break-ins. An independent code audit found that early public exploit code didn't fire against the released versions, per The Hacker News, and nobody has counted successful compromises. The security firm watchTowr did report real exploitation in the wild by October 21.

Governments didn't wait for the count. The NSA, with the FBI and CISA, urged organizations to update immediately and, if they couldn't, to take systems offline until fixed, per Defense One. Finland's government web services, Dutch parliament sites and Wikimedia systems went offline as a precaution, per Paubox.

After the fix, one queue becomes two million

When PHP ships a fix, the queue multiplies. Every server owner now has their own patch job.

The application security company OX Security tracked roughly 1.97 million internet-facing PHP servers that report their version number. At release, 0.01% showed a patched version. At 12 hours, 0.23%. At 24 hours, 0.72%, about 14,000 servers. WordPress hosts were 99.1% unpatched, Drupal 99.2%.

There's a caveat on those numbers. Linux distributions like Debian, Ubuntu and Red Hat often patch PHP without changing its version string, so a scan that reads version banners overcounts the exposed servers. Analysts at Flare, a threat-intelligence firm, put it flatly: a banner is not a patch verdict.

The number that holds up is worse. Two independent scans found that 59% to 73% of version-reporting PHP servers run branches that will never get an official fix. Flare counted 72.7% of 2.22 million services on unsupported branches, with two PHP 7.4 releases alone making up 21.3% of records. The external-risk monitoring firm CybelAngel counted 59% of about 1.5 million version-reporting hosts. PHP published source-level patches for 7.4, 8.0 and 8.1, but those branches are end-of-life and get no official release. For most of those servers there is nothing to click install on.

Appliances wait on a second queue. Palo Alto confirmed on October 22 that its PAN-OS firewalls from 10.2 through 12.2, all Panorama versions and WildFire WF-500 appliances are affected through their management interface. Hotfixes are rolling out branch by branch, and Palo Alto reports no known malicious exploitation of its products. A firewall owner can't patch PHP inside that box. They wait for the vendor.

And the bug class isn't done. On October 23, PHP disclosed a third flaw, CVE-2026-115560, with no emergency patch. It needs an unusual session configuration, and PHP's guidance is to switch off session upload progress until the next routine release.

Faster bug discovery makes patching look slower

PHP2Shell is one case, but the broader data runs the same direction. Google counted monthly vulnerability disclosures doubling this year, from 5,045 in January to 10,740 in August, and found that half of AI-discovered vulnerabilities lead to remote code execution (an attacker running their own code on the machine), against 26% of the rest, per SecurityWeek.

Meanwhile Verizon's 2026 Data Breach Investigations Report put the median time to patch at 43 days, up from 32, and found only 26% of known-exploited vulnerabilities fully fixed across the organizations it surveyed, per Help Net Security. Verizon blames the slowdown on the surge in volume.

None of this started with AI. Ten months after the Log4Shell bug surfaced in December 2021, 72% of organizations still had vulnerable assets, per Tenable data reported by Help Net Security. Patch latency for code everyone depends on was already measured in months. AI sped up the discovery side and left that number where it was.

In fraud strategy, this is the alert-queue problem. A sharper detection model raises more alerts. The investigators working those alerts don't multiply. Past a point, every extra alert pushes the urgent case further down the line, and the one you needed worked this morning waits until next week. In fraud, the fixes are staffing the queue, triaging harder, or cutting what goes into it. Buying a better detector alone just makes the backlog longer.

Bug hunting is hitting the same wall. Patch the Planet worked as designed here: found, reported, coordinated. OpenAI's Greg Brockman said the company spent two months leading a coalition to mitigate the bug. It still ended with exploitation before disclosure and 99% of version-reporting servers unpatched a day later, because the slow part sat with a foundation of about 13 people and the owners of roughly two million servers.

If programs like this keep finding critical bugs in old, widely copied code, funding probably has to follow the find over to the fix side, into maintainer teams and upgrade work, or the extra finds mostly lengthen the queue.

What to do if you run PHP

• On PHP 8.2 through 8.5: install the October 21 releases.
• On 7.4, 8.0, 8.1 or older: there's no official release coming. Your options are a distribution package with the fix backported, if your distro supports your version, an upgrade project, firewall rules in front of the site while you upgrade, or the NSA's option of taking the system offline.
• Either way: switch off session upload progress until PHP's next routine release, for the third bug.
• If you were exposed: look for suspicious activity from October 17 onward, per Amazon.
• If PHP runs inside an appliance: check the vendor's advisory and hotfix schedule. You can't patch it yourself.