The Bug Was Found by AI. The Patch Still Needs You.

On 21 October, PHP shipped fixes for two flaws that let an attacker take over a web server without logging in. Both were found with the help of AI models. Someone tried to exploit them four days before they were made public, and the oldest affected versions get no fix from the PHP project at all. AI has made finding a catastrophic bug cheaper than it has ever been. Fixing one still takes a person, a server and a maintenance window. That gap, not the bug, is the story.

What is PHP2Shell?

PHP2Shell is the name given to two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, which the PHP project fixed on 21 October 2026 and rated 9.2 on the CVSS v4.0 scale. Wiz, one of the firms that reported them, says it achieved "unauthenticated remote code execution on WordPress, Drupal and Joomla", and says PHP "powers 70% of all websites in the world".

PHP's own advisory describes them in two lines. The first, "RCE via OOM corruption", arises when out-of-memory handling interrupts PHP while request data is only half set up, and the cleanup that follows treats the broken data as valid. The second, "RCE via stale global state", arises when state belonging to one request survives after its memory has been freed and a later request on the same worker picks it up. The advisory on php.net rates the risk highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs," and the GitHub advisory for the first flaw names the setup as "Apache mod_php".

Was PHP2Shell found by AI?

Partly, and which part is the whole argument. Calif, the first firm to report, says its researcher "asked my LLM companion for help" and that "No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery." The PHP Foundation says it got the PHP project into OpenAI's Patch the Planet programme, "as part of which security firm Calif began an audit of PHP on July 30th, 2026". Wiz, working separately, writes: "We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research."

The weakness behind the first flaw, though, was not new. Calif's own timeline begins in 2004, with Stefan Esser's first memory-limit vulnerability in PHP, and runs through a 2020 bug report, #78876. In 2024 an external audit by Quarkslab and OSTIF, funded by the Sovereign Tech Agency, led a core developer to the first signs of the out-of-memory problem. The Foundation sums up what happened next: "In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found". Calif is blunter: "However, exploitation was not proven, hence the bug was not fixed."

So AI did not reveal that PHP had a weak spot here. People had seen it two years earlier. What AI-assisted researchers supplied in 2026 was proof, and fast. Wiz's timeline records its first finding on 19 August and unauthenticated code execution confirmed against Drupal on 20 August and WordPress on 21 August.

Which PHP versions are affected by PHP2Shell?

Nearly all of them. Wiz writes that "Nearly every PHP version is affected by at least one of these issues, including releases dating back to PHP 5.4," and PHP's GitHub advisories list every release below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected.

PHP shipped fixed releases only for the four branches it still supports, 8.2, 8.3, 8.4 and 8.5, and even that set is shrinking: "PHP 8.2 reaches end of life on 31 December 2026 and will receive no further security fixes after that date." For 7.4, 8.0 and 8.1, the security team published "minimal source-backports", code branches for people who compile PHP themselves, not releases. The advisory is plain about the rest: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version." CISA is blunter still: its alert tells organisations that "continue to use PHP 8.1 or earlier unsupported versions" to take PHP-based systems offline until they can be patched or updated.

Is PHP2Shell being exploited?

Attackers are trying, and one tried before the public knew. Amazon says its MadPot honeypots recorded "a PHP2Shell exploitation attempt dating to Oct. 17, 2026", which it places "four days before public disclosure of CVE-2026-109618 and CVE-2026-109619." The attempt came from an anonymization network, "though it remains unclear how the actor acquired exploit information prior to disclosure." After the release, Amazon wrote that "PHP2Shell is now seeing broad exploitation attempts in the wild", while cautioning that "it’s unclear if any of these attempts would have succeeded in real-world systems."

The government advisories I read are more guarded. CISA's alert, last revised on 23 October, says the agency "has not observed successful exploitation of these vulnerabilities in the wild as of the time of publication." Canada's Cyber Centre, updated the same day, says open-source reporting indicates a proof of concept is available, "with no active exploitation being identified at this time". When I read CISA's Known Exploited Vulnerabilities catalogue on 26 October, its newest entries were dated 23 October and neither PHP2Shell identifier was among them.

How do I fix PHP2Shell?

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP's release notes put it without hedging: "There are no complete mitigations, updating is the only safe choice."

If a hosting company runs PHP for you, ask it which PHP version your site runs and whether that build carries the October fixes. If you use a Linux distribution's packages, PHP notes that "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages."

If you cannot update quickly, the agencies' advice is uncomfortable. CISA says organisations "that cannot update immediately" or "that continue to use PHP 8.1 or earlier unsupported versions" "should take PHP-based systems offline until they can be patched or updated." The UK's NCSC points first to the temporary mitigations "the PHP Foundation have provided", and where those cannot be applied, or would take too long, says "you should consider taking the system offline until it can be fully mitigated." The NSA is the most direct about old branches: among the steps organisations should consider, it lists "Replacing end-of-life PHP services which will not be compatible with patching," and it says "If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated." PHP says its partial configuration changes "do not make an installation safe." On 23 October PHP also flagged a separate flaw, CVE-2026-115560, which it calls "an unlikely RCE vector" and will cover in its next release.

What happened between the PHP2Shell report and the patch?

Calif's first report reached PHP on 11 August and the fix shipped on 21 October, and the last two days of that stretch went wrong. The table assembles the sequence from the parties' own accounts.

One account differs. Wiz's timeline says that on 21 September "PHP acknowledges the reports and begins developing a coordinated fix", whereas the Foundation says fixing the out-of-memory problem became the team's top priority from 11 August, and Calif says PHP confirmed its proof of concept on 15 August. I report each as written.

Two of the leaks had human fingerprints. The Foundation says "Calif, one of the security firms that had reported the issues, mistakenly published a video," and that "Chainguard unilaterally broke the embargo and published built images containing the fix." It also says it "did not identify any functional exploits at the time of release/public disclosure."

How many PHP servers are still unpatched?

Nobody outside can count patched servers, but the branch data shows how much of the web cannot be patched in one step.

Three caveats keep these numbers honest. Version strings are not patch status: a distribution can backport the fix into a package that still reports an old version. Many servers hide their version, and Bitsight says those "are likely exposed but not shown". And the WordPress endpoint publishes shares, not a count of sites.

The direction is still not in doubt. PHP's end-of-life table shows 7.4, the branch Bitsight sees most, out of support since 28 November 2022, and 5.6, the last of PHP 5, since 31 December 2018. PHP 5, which W3Techs finds on 7.7% of PHP websites, gets no fix of any kind from the PHP project.

Is AI making bugs easier to find than to fix?

In this case, yes: finding ran in parallel and fixing did not. What follows is my argument, built on the record above. At least three groups, Calif, Wiz and OpenAI, reported the same weakness independently, the first on 11 August, and the GitHub advisories credit a fourth reporter, listed as tomash-areion. Wiz adds the part defenders should fear most: "LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts," which "significantly lowers the barrier to scaling attacks across different deployments." Wiz's point is that fitting an exploit to each old version, once slow hand work, is getting easier.

Fixing has stayed serial. At the source, the Foundation says "security work on PHP itself still depends on a small group of foundation-funded developers", that "a person makes every call and works on every patch", and that without its funding "it would have been impossible to have multiple people work on this issue full time." It calls the delay since the 2024 audit "a structural failure, caused by both the security team's decision process and its lack of resources." Meanwhile the inflow grows. The team "has published 15 CVEs since July 1st", has "worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible", and expects that "the number of reports will keep growing."

Then the fix travels through distributions and vendors, and finally to every operator, where a person must book a window, take a backup, run the update and check that the site still works. None of that gets faster because a model found the bug sooner. On an end-of-life branch it gets harder, because the update is a migration. Here a finding took days of researcher time on generally available models; the repair is still counted in human hours at every server.

Doesn't AI speed up patching too?

Yes, at the source, and the counter-case deserves its full strength. The audit that found the first flaw ran inside OpenAI's Patch the Planet programme, and that programme was built for repair as much as for finding. Its launch page, dated 22 June, says "AI is accelerating vulnerability discovery, but discovery alone does not protect users," and that its security engineers "work with projects to develop patches and tests". It adds: "Maintainers remain in control of what patches are deployed and how disclosure is handled." OpenAI's Daybreak for Frontline Defenders page, dated 3 September, says "OpenAI is committing $1 billion in subsidized Daybreak access, training, technical support, and partnerships to help frontline defenders protect essential services," and that the access can help defenders "identify and validate vulnerabilities, prioritize the most serious risks, and develop and test fixes." It describes a pilot with MS-ISAC that helps them "coordinate remediation". PHP itself uses the tools: the Foundation says it worked with Alpha-Omega to "scan PHP with Anthropic's Claude Mythos", and uses "OpenAI's Daybreak Red for validating reports and exploits". The fix was written by people: both GitHub advisories credit four remediation developers, listed as arnaud-lb, iluuu1994, bukka and ndossche.

The other objections are fair too. The long tail predates AI: PHP 5.6 left support in 2018, years before any of these models existed. Two of the leaks were human failures, a published video and a broken embargo, not a model's. And finding a bug before an attacker does is plainly good.

Here is why I still hold the thesis. The sharpest objection is the 2024 one. The flaw was known and left unfixed because "exploitation was not proven", AI-assisted researchers supplied the proof, so the missing piece was arguably a discovery-side output. For the first months of this story, I accept that. But the Foundation does not blame missing proof alone. It blames "the security team's decision process and its lack of resources", and even with a confirmed proof of concept on 15 August, the release came on 21 October and depended on funded people. The Foundation is explicit: "What tools cannot do is decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch." And the source fix is only the first repair. Patch the Planet puts engineers on the project's patch, which is real help, and its page describes that work as "in service of maintainers"; it does not mention the operators who must then install the fix. None of the programmes I read pays cash for the operator's upgrade, the step where most of the exposure now sits. OpenAI describes the $1 billion as subsidized Daybreak access, with training and technical support, and says that access can help defenders "develop and test fixes". What none of it offers is cash for the operator's own upgrade hours. Discovery getting better is good news. Repair not keeping pace is the problem.

What should change after PHP2Shell?

In my view, four modest changes would narrow the gap without slowing discovery. None describes current law; they are proposals.

1. Fund the fix with the find. Any programme that sends AI-generated findings to a volunteer-run project should budget named maintainer hours for repair, in money, alongside the model credits.
2. Make hosts patch within a branch by default. Shared hosting providers should apply security point releases automatically within a published number of days, and publish each quarter the share of customer sites on end-of-life branches.
3. Put hosts on the embargo list and write the early-release rule down. PHP gave distributions and LTS vendors the patch in advance; for flaws in core infrastructure, the largest hosting providers belong on that list too. That has a cost, and the Foundation names it: mitigation advice it began giving "a few critical infrastructure providers" "may have leaked as well". PHP's pre-announcement already reserved "the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild." Every party on the list should sign that rule, and a party that breaks the embargo should lose its place on the next one.
4. Make end-of-life exposure reportable, not fineable. For public bodies and regulated sectors, running an internet-facing runtime that its own project calls end of life, after a critical advisory, should be reported to their supervisor with a date for fixing it. PHP already tells such users they "should upgrade as soon as possible, as they may be exposed to unpatched security vulnerabilities." A reporting duty would turn that sentence into a deadline.

Wiz reaches back to 2014 to describe this moment: "In 2014, Heartbleed exposed the fragility of shared infrastructure securing the internet." The comparison holds, with one change. In 2026 the looking is no longer scarce. Machines are doing it for attackers and defenders alike, and the work at the end of every finding still falls to a few people with a server to take down and a window to book. The bug was found by AI. The patch still needs you.

---

This analysis is by Mücahit Kaya, founder and editor-in-chief of AI Tools Police, an AI industry researcher with a public administration background. It draws on the published record, read in the original: PHP's security advisory and release announcements, the GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, PHP's supported versions and end-of-life pages; the PHP Foundation's account of the release; Wiz's research write-up; Calif's write-up; Amazon Threat Intelligence on the 17 October attempt; CISA's alert and CISA's Known Exploited Vulnerabilities catalogue; the UK NCSC; Canada's Cyber Centre; the NSA's advisory; Bitsight on observed PHP branches; W3Techs on PHP usage; the WordPress.org PHP version statistics; and OpenAI's Patch the Planet and Daybreak for Frontline Defenders pages. Where the piece moves from the record to argument, it says so. Our writing workflow uses Anthropic's models; Anthropic appears once in the piece, as the maker of a tool PHP uses. The conclusions are the author's own.