Five Finders, One Fix, and a Honeypot Hit on the 17th

On Wednesday 21 October, at 14:00 UTC, PHP released four security versions fixing two flaws that let an unauthenticated request run code on a server. The Rundown’s newsletter the next morning was headed “AI finds a security hole in 70% of the web.” Fortune’s headline the day before said AI tools discovered the vulnerability “that could take down 70% of the internet.” Both sentences have a defensible source behind them, and both mislead in the same two places. The PHP Foundation’s own account, published the same afternoon as the release, says a human found the first signs in 2024, and the 70% is the share of websites that run PHP at all, not the share anyone has shown to be exploitable. What the Foundation’s post adds, and what I spent the evening laying end to end with the vendors’ posts, is a disclosure timeline with five parties who found the bugs, two of them after being told the bugs existed, a release 71 days after the report that made the problem urgent, and one exploitation attempt, logged in Amazon’s honeypots on 17 October, three days before the first leak the Foundation names and one day after a tip-off that Chainguard’s chief executive has described in print.

Who found it, by whose calendar

The Foundation’s version starts two years back. In 2024 PHP had its first external audit in years, funded by Germany’s Sovereign Tech Agency, organised by OSTIF and carried out by Quarkslab. The published audit report, version 1.4 dated 14 March 2025 with an initial version from 6 September 2024 and with details of unfixed issues removed in a February 2025 revision, does not describe it. The Foundation says that “while fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs” of the problem behind CVE-2026-109618, that “a potential exploit for the OOM problem was theorized, but no concrete vectors were found,” and that other issues “overshadowed these concerns.” Greg Brockman posted the same account from the outside, in a post Fortune quotes: “A limited version of it had been discovered in 2024 and wasn’t considered significant at the time.”

Then the 2026 dates, which do not line up across sources, and I think the misalignment is the interesting part rather than an error to be corrected.

• Calif. The Foundation says the firm began an audit of PHP on 30 July under the Patch the Planet programme, which Fortune and OpenAI describe as OpenAI’s, and that on 11 August “researcher Ryan A at Calif reported an unconditional remote code execution with the same root cause.” Fortune says Calif “found the first issue” on 1 August using GPT-5.6 Sol, and the Rundown says it found “the first bug” that day. The Foundation gives a report date; the press gives a find date. Ten days apart, and both can be true.
• Wiz. Wiz’s post dates its own discovery to 19 August, using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, and its report to 24 August. The Foundation agrees on 24 August. Wiz’s timeline then has PHP acknowledging the reports on 21 September, 28 days later. The Foundation’s post says fixing the problem “became the top priority” from 11 August, so the acknowledgement date is not a start-of-work date, but it is the only acknowledgement date a reporter has published. Daubois’s own timeline adds that the advisory was opened on 27 August, the fix pull request on 25 September, and the final commit on 18 October. One aside: Wiz’s find date is six weeks before Google announced Argon on 30 September and released it first to vetted cyber defenders. Wiz is Google-owned, as Fortune notes, which would explain the access.
• OpenAI. The Foundation says OpenAI “independently reported the same root cause,” with no date, “followed by further attack vectors from OpenAI on September 18th.” OpenAI’s own account, published on 21 October, says it “led a coalition of maintainers, researchers, and security providers” over “the past two months,” credits Calif with the find and Wiz with “independently discovering and reporting both vulnerabilities,” and gives no date for its own first report. Fortune’s version is that Calif “then informed OpenAI, which looked into the issue on its own and found additional elements of the bug.” The Rundown says OpenAI “worked on patches alongside the PHP maintainers for two months.”
• Chainguard. Dan Lorenc, its chief executive, told The Register that a researcher who had found the bugs told him on a Friday, 16 October by the article’s own sequence of a Saturday with the maintainers, rumours from Monday and an interview on Wednesday the 21st, that “something was coming in PHP,” that his team found the same flaws that night with a model and a basic prompt, and that on the Saturday they began working with the maintainers and testing the patches. His summary: “Just being told there’s a vulnerability in a piece of software - even something as big as PHP - is enough to find it.”

The two GitHub advisories, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, settle credit the way advisories do: four handles marked “Reporter,” one with a Wiz suffix and one with an OpenAI suffix, in a different order on each advisory, followed by four remediation developers. The Foundation does not name the contractor who found the first signs in 2024, so the credit lists cannot tell you whether that person is among the remediation developers. What they can tell you is that credit goes to reporters, and a 2024 suspicion with no concrete vector was never a report. The Foundation’s prose thanks Calif, Wiz, “OpenAI Codex Security,” OSTIF and Quarkslab. The newsletter credits one model. Each document is accurate about the thing it is designed to record.

The fix was the slow part

The gap that matters in this timeline runs from 2024 to 11 August 2026, and then from 11 August to 21 October. The models sit at one end of it. The Foundation is unusually direct about the first gap. The security team “developed several competing approaches, but each came with its own trade-offs,” it “struggled to choose between these and feared the repercussions of shipping the wrong choice,” and the work “stall[ed] and restart[ed] repeatedly over months.” Its own verdict: “the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.” The announced remedies are organisational, not technical: decisions “by majority,” leadership brought in sooner, and a promise that complex fixes “get resolved faster.”

The second gap is 71 days from the report that made the problem urgent to the release. That is the number to set against the “AI found it” framing. The models shortened the time from suspicion to demonstrated impact, which had been running at about two years. Whether they shortened the ten weeks of choosing a fix, backporting it to four branches and getting distributors packaged is less clear. Wiz’s post, quoting Google DeepMind’s head of Gemini security, credits Argon with “validation of the patch,” OpenAI says its process includes adversarial testing of fixes with frontier models, and the Foundation says the decision itself was not one a tool could make, in its closing section: tools “find bugs faster than ever, for defenders and attackers alike,” but “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.”

There is a volume number behind that sentence. Alexandre Daubois, who joined the Foundation in July to handle reports, wrote on 14 October that the team had published 15 CVEs since 1 July and closed 106 reports that “did not constitute vulnerabilities, were duplicating something already in the queue, or didn’t reproduce.” That is 121 reports handled in fifteen weeks, one in eight of them a real flaw, by “a small group of volunteers and PHP Foundation contractors.” No published study I could find measures how AI-assisted discovery programmes change the report volume a maintainer receives or the time to fix; the Foundation’s two figures are the closest thing to a measurement that exists for this project.

Twenty-three hours

The coordinated part of the disclosure, in the Foundation’s words, “worked well until 2 days ahead of the targeted release date.” The release was set for Thursday 22 October at 14:00 UTC. Then, on Tuesday 20 October at about 15:00 UTC, the two CVE identifiers appeared on forums and social media with a wrong release time and a wrong CVSS score of 10.0, against the real 9.2. No technical detail leaked at that point. The Foundation published its pre-announcement early, at 19:30 UTC, and moved the release forward a day. One clause in the pre-announcement matters later: “We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”

From there the Foundation’s chronology, Daubois’s personal account from inside the security team, and the vendors’ posts give a 23-hour strip that I have drawn below. Around 20:00 UTC, Calif “mistakenly published a video” of its proof of concept, deleted it, and copies circulated. Around 23:00 UTC, mitigation advice went to “a few critical infrastructure providers” and, the Foundation says, “may have leaked as well.” At about 02:00 UTC on the 21st, Amazon’s MadPot honeypots saw the earliest proof-of-concept attempts, with more between 02:00 and 08:00 from “additional anonymized infrastructure.” At 03:02 UTC Cloudflare turned on default protection for all its WAF customers, which it describes as “about 9 hours ahead of public disclosure”; by my clock it is just under eleven. At 07:41 UTC Chainguard published container images containing the fix. At 13:43 UTC, seventeen minutes before the embargo lifted, Wiz’s write-up was on Hacker News, where it collected 446 points and 184 comments. At 14:00 the release went out.

The Chainguard entry is the contested one. The Foundation’s post says Chainguard “unilaterally broke the embargo,” that “any attacker could now study the fix in binary form while every other PHP user was still waiting for the release,” and that this “disregarded weeks of work by many parties.” Dan Lorenc, Chainguard’s chief executive, told The Register that “people were getting hit in advance” of the disclosure, “so we made the call to ship the fixes,” that the company’s rule is “coordinated vulnerability disclosure, unless there’s evidence of active exploits in the wild,” and, asked whether he would do anything differently, no. He told The Record he had begun seeing exploitation attempts the night before and that “these situations are always tough and require judgment calls.”

I do not think the two positions are as far apart as the tone suggests. Both invoke the same trigger, evidence of exploitation in the wild, and the Foundation wrote that trigger into its own pre-announcement. The disagreement is about who gets to pull it. The Foundation’s post also names only Chainguard, and not Cloudflare, whose rules went live more than four and a half hours earlier. That is not an oversight. Cloudflare’s post says it worked with the Foundation, OpenAI and Wiz, and OpenAI’s account lists it among the partners preparing protections ahead of disclosure, so it was inside the circle rather than acting on its own; the same account says the coalition engaged the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA before the release. The distinction the Foundation draws is that a shipped binary lets an attacker diff the fix, while a firewall rule does not reveal it. Whether a binary diff of a memory-management fix really hands an attacker what six hours of waiting would have withheld is a question for people who build exploits, and the Foundation’s own observation cuts against the worst case: its team “did not identify any functional exploits at the time of release.” One critic’s post from the same day says the public proofs of concept did not work against a standard install.

The 17th

Everything above is a story about a leak on 20 October. Amazon’s post is about something earlier. Its author, CJ Moses, the CISO of Amazon Integrated Security, writes that MadPot telemetry contains “a PHP2Shell exploitation attempt dating to Oct. 17, 2026,” four days before disclosure, from “an IP address associated with a commercial anonymization network,” and that “it remains unclear how the actor acquired exploit information prior to disclosure.” An Amazon spokesperson told The Hacker News the activity was largely a one-off probe. The post does not say when Amazon found the entry in its logs; the phrasing “dating to” reads to me as a retrospective match made after the signature was known, which is how honeypot findings usually arrive.

Three days before the identifiers leaked and the video went up, four before the images, the embargo was the only thing between the flaw and the public, and the Foundation dates every breach of it to the 20th or later. One earlier event is on record, in Chainguard’s own account: the Friday tip-off and the overnight rediscovery described above, one day before the honeypot entry. Nothing in either post connects the two, and I am not suggesting a connection. What Lorenc’s account establishes is narrower and, I think, more important: by the night of the 16th, the set of people who could find these bugs was not the embargo list but anyone who had been told something was coming and had a model to point at the code. The possibilities for the 17th are the usual ones, a party inside the embargo, an independent finder who never reported, or a false match on something that only looks like this flaw in hindsight, and Amazon does not pick between them. OpenAI’s account says that “to our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender’s Window.” The MadPot entry is the one datum that sits against that sentence, and the phrase “to our knowledge” is doing its job. What the published record says about one-sensor observations is this. In a 2025 conference paper on four exploitation feeds over 2019 to 2023, Khoury and colleagues report that 86.6% of the CVEs flagged as exploited were flagged by exactly one of the four feeds, and only two CVEs by all four; I have those figures from the paper’s summary and could not check them against the full text. If they hold, sensors that disagree are the normal case rather than a red flag, and “exploited in the wild” is a property of the sensor as much as of the world, which this week illustrated: SecurityWeek reported early on the 21st that watchTowr and Huntress had seen no exploitation; watchTowr’s FAQ later recorded exploitation through its own honeypots on the 21st; Chainguard’s honeypots, per The Register, caught probes on the Wednesday; and as of 22 October neither CVE was in CISA’s Known Exploited Vulnerabilities catalogue.

For scale, the only large baseline I know of is old. Shahzad, Shafiq and Liu’s 2012 study of some 46,000 vulnerabilities found 2.8% exploited before public disclosure, with 88.2% first exploited on the disclosure day itself. A 17 October attempt would put this flaw in the 2.8%. Whether that rate has moved since 2012 is not something anyone has measured with public data, and there is a structural reason. Muegge and Murshed pointed out in 2018 that the CVE record had no field for when a flaw was discovered or reported, so report-to-patch intervals could not be computed from the public databases; the current record format has an optional timeline field, and nothing obliges anyone to fill it. The discovery dates in this essay exist because the Foundation, Wiz, Daubois and two reporters chose to publish them. The advisories carry one date, 21 October, and four handles.

Seventy percent of what

W3Techs, the source every outlet is leaning on, put PHP at 69.3% of websites whose server-side language it can identify on 22 October. That is a share of the web that runs PHP. The share that was exploitable without authentication depends on the server configuration, which the Foundation’s post describes at the level of “on Apache with mod_php” for the default-settings case and “through application-level code paths” for PHP-FPM, and I found no published split. The nearest figure is an initial Palo Alto Networks count of 22.6 million potentially vulnerable instances, reported by Fortune, which counts installations rather than configurations. Wiz’s post says “70% of all websites in the world.” Cloudflare says “almost 70%,” citing W3Techs. The Foundation itself says “a large share of the web.” I would print the Foundation’s phrase. The newsletter’s “security hole in 70% of the web” is true in the sense that the hole was in software 69.3% of the web runs, and false in the sense most readers will take it, which is that seven in ten sites could be taken over.

The last time two groups found one bug

The closest well-documented precedent for a flaw found twice and disclosed under pressure is Heartbleed, and its paper trail has the same feature as this week’s. Durumeric and colleagues’ IMC 2014 paper gives the timeline: Neel Mehta at Google found the bug on 21 March 2014, Google patched its own servers and told OpenSSL on 1 April, Codenomicon found it independently on 2 April and told Finland’s NCSC-FI, and “after receiving notification that two groups independently discovered the vulnerability, the OpenSSL core team decided to release a patched version,” on 7 April. Codenomicon’s own heartbleed.com dates its discovery to 3 April. Even the canonical case has two dates for the second discovery, and in that case too the second finder is what moved the release. Cloudflare was privately notified on 31 March, a week before the public; Red Hat, Debian and FreeBSD got less than 24 hours. The argument about who should be inside the embargo, and for how long, is twelve years old and was not settled then either.

What is new in 2026 is that all three firms were running frontier models against the same codebase in the same few weeks, so three finds in five weeks is roughly what one would expect, and the Foundation says it also had the codebase scanned with Anthropic’s Claude Mythos through Alpha-Omega earlier in the year, and now validates incoming reports with OpenAI’s Daybreak Red, from the Daybreak line whose Sophos case-study arithmetic I went through last week. Independent discovery used to be a coincidence that told you a bug was ripe. When five parties point models at one 31-year-old interpreter, and one of them finds the bugs in a night on the strength of a tip from one of the finders, it is closer to a certainty, and the thing that bounds the embargo is no longer how long the finders will wait but how long before someone with no agreement to wait finds it too. Lorenc’s Friday night is a measurement of that interval, and it came out at one night. The Foundation’s 71 days were spent on a fix, which is defensible. The two years before that were spent deciding whether to spend them, which the Foundation itself no longer defends. The honeypot entry from the 17th is the one line in this record that nobody has explained, and I would rather have it sitting there unexplained than have it tidied into one of the leaks it predates.

References

1. The PHP Foundation (2026). Today’s PHP Security Release, and How We’re Strengthening PHP Security. 21 October 2026.
2. PHP project (2026). Upcoming Critical PHP Security Release and the PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements. php.net news archive, 20 and 21 October 2026.
3. php/php-src (2026). GHSA-w8hw-w9fx-j79w, CVE-2026-109618. GitHub security advisory, 21 October 2026.
4. php/php-src (2026). GHSA-6wmf-4rv5-p3rp, CVE-2026-109619. GitHub security advisory, 21 October 2026.
5. Wiz Research (2026). PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. 21 October 2026. Hacker News discussion at item 50180836, posted 21 October 2026, 13:43 UTC; points and comments as of the evening of 22 October.
6. Moses, C. J., Amazon Web Services (2026). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog, 21 October 2026.
7. Cloudflare (2026). Cloudflare deploys protections against php2shell vulnerability. 21 October 2026, updated 22 October 2026.
8. Daubois, A. (2026). What the PHP2Shell rumors got wrong, from inside the PHP security team. Personal blog, 21 October 2026.
9. Daubois, A., The PHP Foundation (2026). How the PHP Security Team Handles Your Reports. 14 October 2026.
10. Lyons, J. (2026). PHP blames supply chain security biz Chainguard for putting huge chunks of the web at risk. The Register, 22 October 2026.
11. Greig, J. (2026). PHP says AI review of critical bugs first sparked alarm in August, but signs surfaced in 2024. The Record, 21 October 2026.
12. Lakshmanan, R. (2026). Someone Tried to Exploit PHP2Shell 4 Days Before the Vulnerabilities Were Publicly Disclosed. The Hacker News, 22 October 2026.
13. Arghire, I. (2026). PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws. SecurityWeek, 21 October 2026, updated 22 October 2026.
14. watchTowr (2026). PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 Fixes. 20 October 2026, updated 22 October 2026.
15. Forlini, E. (2026). AI tools discovered the PHP vulnerability that could take down 70% of the internet. Now, the race is on to patch it before AI-powered hackers attack. Fortune, 21 October 2026.
16. The Rundown AI (2026). AI finds a security hole in 70% of the web. Newsletter, 22 October 2026.
17. W3Techs (2026). Usage statistics and market share of PHP for websites. Figure dated 22 October 2026.
18. Quarkslab (2025). PHP-SRC audit, technical report 24-07-1730-REP, version 1.4. In collaboration with OSTIF; initial version 6 September 2024, version 1.4 dated 14 March 2025.
19. Taylor, E. (2026). There isn’t an easy exploit for this PHP vulnerability. Personal blog, 21 October 2026.
20. Khoury, R., Khanmohammadi, K., Vallé, J. and Hamou-Lhadj, A. (2025). Mining Five Years of Actively Exploited Vulnerabilities. 2025 IEEE 49th Annual Computers, Software, and Applications Conference (COMPSAC), July 2025.
21. Shahzad, M., Shafiq, M. Z. and Liu, A. X. (2012). A large scale exploratory analysis of software vulnerability life cycles. 34th International Conference on Software Engineering (ICSE), June 2012. Historical baseline.
22. Muegge, S. M. and Murshed, S. M. M. (2018). Time to Discover and Fix Software Vulnerabilities in Open Source Software Projects: Notes on Measurement and Data Availability. PICMET 2018, August 2018.
23. Durumeric, Z., Kasten, J., Adrian, D., Halderman, J. A., Bailey, M., Li, F., Weaver, N., Amann, J., Beekman, J., Payer, M. and Paxson, V. (2014). The Matter of Heartbleed. Proceedings of the 2014 Internet Measurement Conference (IMC), November 2014. Historical context.
24. Codenomicon (2014). The Heartbleed Bug. April 2014. Historical context.
25. OpenAI (2026). Patch the Planet: global response coordination as agents uncover critical vulnerabilities. 21 October 2026.