Home / Articles / The evidence behind four days: Jeremiah Grossman's php2shell post, checked claim by claim against the data, with the provenance and the graphs, and the two things that changed since

The evidence behind four days: Jeremiah Grossman's php2shell post, checked claim by claim against the data, with the provenance and the graphs, and the two things that changed since

By Dinis Cruz · 2026-10-27 · article v1.0.0 · newsroom v0.13.101 · php2shellevidencevulnerabilitieskevepssdataarticle

Abstract: Four days after php2shell went public, Jeremiah Grossman, CEO of Root Evidence, posted on LinkedIn that the evidence does not support the wave of AI-enabled breaches many were bracing for, that the exploits are environment-specific, that in the same four days over a thousand CVEs were published and almost none were exploited, and that the rule is the old one: patch what adversaries exploit. This is the data behind each claim, re-counted from public sources and from the PHP story site's evidence, with every number traceable to a query or a captured source. Most of it holds. The post's timestamp is the CVE record's to the second; NVD counts 1,394 CVEs in the same window, not 1,448; none references Exploit-DB or Metasploit; VulnCheck published 25 old bugs with 2017 to 2025 IDs on 22 October; CISA had listed one, the Arista flaw. Two things changed after the post: CISA added both php2shell CVEs to its catalogue on 26 October, and their EPSS scores jumped from about 0.1 to 0.9998 the day before. Still no organisation has said it was compromised through php2shell. And the yearly numbers back the post's wider point: CVE publications more than doubled this year, while additions to CISA's catalogue rose by 30%.

In short

• Jeremiah's post holds up. Most of its numbers reproduce from public data; the rest are marked below.
• The timestamp is exact. The CVE record was published at 13:48:34 UTC on 21 October.
• 1,394, not 1,448, by NVD's count for the same window. Close; the difference is explained below.
• Almost none show signs of exploitation. 1,361 of 1,383 have an EPSS below 0.01; none cites Exploit-DB or Metasploit.
• Still no confirmed victim. 53 rows of evidence, eight named organisations, none confirmed as php2shell.
• The exploits are environment-specific, as the post says: the public ones are tuned, raced, or wrong.
• Two things changed since. CISA listed php2shell on 26 October; EPSS jumped to 0.9998 the day before.
• The yearly data backs the wider point. CVEs more than doubled; the exploited catalogue grew by 30%.
• Some numbers need data we do not have. We have asked the PHP story site's team for them.

The post

Jeremiah Grossman is the CEO of Root Evidence. Four days after the disclosure, Jeremiah wrote that "plenty of people are calling it the arrival of AI-enabled exploitation at scale and bracing for a wave of breaches", and that "the evidence says otherwise". The claims, in the post's order: the exploits that work are built "for specific environments and a generic wide sweeping exploit is unlikely"; honeypots "have caught plenty of attempts"; "nobody has reported mass compromise, some reports of individual breaches, but nothing confirmed"; in the same four days 1,448 more CVEs were published, nobody published exploit code for any of them in Metasploit or Exploit-DB, VulnCheck put 25 of them on its KEV list, 24 of them old bugs given IDs on 22 October, and CISA added just one, the Arista VeloCloud Orchestrator flaw; Censys counts 32 million PHP services on an affected version. Then the opinion: nothing in the record shows AI "driving up how many vulnerabilities adversaries exploit, or how fast", adversaries "keep working a small set of bugs until those stop paying", so patch php2shell, then "patch what adversaries exploit".

The PHP story site keeps exactly the record needed to check this, and the rest is public: NVD's API, CISA's catalogue, FIRST's EPSS scores and the CVE records. Every number below comes from one of them; the queries and the derived data are in this article's dataset.

Claim by claim

No wave, and nothing confirmed

The PHP story site's evidence on compromise is a list of every statement, each with its captured source. Its line, at 09:43 UTC on 27 October, six days in: "No named organisation has said it was compromised through php2shell." Its 53 rows divide as the figure shows. The eight named organisations are the "reports of individual breaches": GMO Internet Group found malicious programs on servers of its trading service and has not stated the cause; Czech Technical University stopped an attack; Valtec first blamed the PHP flaw, then said the attackers used a flaw in its own service; DMM halted services and would not say whether it was PHP; Germany's Interior Ministry said its site "was not hacked"; Anexia confirmed attempts; Ahold Delhaize denied any link; and the Square Enix report is second-hand and does not say how the access happened.

Two more data points from the site's claims since Jeremiah posted. Palo Alto Networks Unit 42 retracted, on 25 October, its statement of two days earlier that tied an attack on a European government agency to php2shell, having been unable to confirm the initial access (as reported by SC Media). And watchTowr's head of threat intelligence put reliable indiscriminate exploitation at "a firm No".

Exploits built for specific environments

The record agrees with him, and is specific about why:

• The CVSS vector itself says attack complexity is high (AC:H) for both CVEs.
• The public bounty win needed one exact PHP build and worker setup, succeeded about seven times in ten in its author's own lab, and took about three hours once the target had a PHP page to attack, as we checked yesterday.
• A honeypot result of 35 working shells came from what the site's sources call a deliberately favourable setup, on a vulnerable build.
• VulnCheck, as cited by a detection author, found that none of the public proofs of concept it reviewed had the correct mechanism; Fastly says a working exploit needs knowledge of the running binary's layout.

Honeypots did catch plenty: Amazon's MadPot saw an attempt four days before disclosure, ELLIO's sensors and Chainguard's honeypots logged hits from the first morning, and Cloudflare's CEO counted "millions" of attempts. The site's exploitation timeline lists each with its source.

The other 1,393

NVD counts 1,394 CVEs published between 13:48:34 UTC on 21 October and the same time on 25 October. The difference from the post's 1,448 is small, and has two likely causes: NVD's publication time is not always the CVE record's, and counts move as records are added, rejected or re-dated. Of the 1,394, NVD had fully analysed 3; 12 were rejected; most were waiting. They came mostly on weekdays: 494 and 497 on 22 and 23 October, 39 on the Sunday.

None references Exploit-DB or Metasploit. FIRST's EPSS, which models the probability of exploitation activity in the next 30 days, scored 1,383 of them on 26 October: 1,361 below 0.01, 19 between 0.01 and 0.1, one Brotli decoder flaw at 0.36, and the two php2shell CVEs at 0.9998. VulnCheck, acting as a CVE authority, published 25 CVEs with ID years from 2017 to 2025, all on 22 October, which is the pattern Jeremiah describes: old bugs, known to be exploited, given an ID only now.

What changed after the post

Two things, both in the direction of "php2shell is exploited", neither in the direction of a wave:

• CISA listed both CVEs in its Known Exploited Vulnerabilities catalogue on 26 October, version 2026.10.26 released at 22:24 UTC, with a due date for federal agencies of 29 October. A listing requires evidence of exploitation; it names no victim, and the PHP story site's compromise line did not change. So the window's count on CISA's catalogue is now three: the Arista flaw and the php2shell pair. The site's newsroom carried the listing to readers 5 h 21 min later.
• EPSS jumped first. Both php2shell scores went from about 0.06 and 0.12 on 24 October to 0.99997 and 0.99981 on 25 October, a day before CISA's listing. Meanwhile the Arista flaw, which CISA listed as exploited on 23 October, sits at 0.01. A model of likely exploitation and a catalogue of evidenced exploitation are different instruments, and they disagree in both directions.

Attention is not exploitation

The PHP story site has an agent, Pulse, that tracks other vulnerabilities in the news beside php2shell, with two things kept apart: the evidence of exploitation, as eight levels from a public proof of concept to a named victim, and the attention, as counts of news items. On 24 October, in comparable feeds, php2shell had 295 news items and had reached levels 1 and 4: a public proof of concept and attempts reported by a named party. Twelve flaws that CISA had listed as exploited in the same fortnight, or that were old flaws newly listed, had 11 to 48 news items each. Three of them were from 2015 and 2016. That is the post's closing argument in one chart: what is exploited and what is talked about are different lists, and patching should follow the first.

Is AI driving it?

Jeremiah's opinion is that nothing in the record shows AI driving up how many vulnerabilities adversaries exploit, or how fast. The yearly numbers are consistent with it, with one caveat. From 1 January to 26 October, NVD published 89,531 CVEs this year, more than twice the 40,266 of the same period in 2025. CISA's catalogue added 274 entries, 30% more than the 210 of 2025. Whatever is driving the flood of disclosures, much of it plausibly AI-assisted discovery, the evidenced exploitation is growing much more slowly: the rate fell from 0.62% of publications in 2023 to 0.31% this year. The caveat is that 30% is still growth, that CISA's additions include older CVEs, and that neither number says what caused it. "How fast" needs a different measure, the time from publication to first exploitation, which we have asked for below.

The 32 million

The post's 32 million is Censys's count of services, not servers or organisations. Censys's dashboard was quoted at 36.7 million services on 22 October, which, if both figures are the same measure, would mean the count is falling as sites patch. We could not read the dashboard ourselves, so that is a question, not a finding. What the record does show is how far apart the published figures are: from 1.57 million unpatched hosts to "almost 70% of websites", because each counts a different thing, and a version string is not the same as an exploitable server.

What we asked the PHP team for

Some of the post cannot be checked from public data, and some of it deserves a better dataset than the one we have. We have written a brief for the PHP story site's team asking for: VulnCheck's KEV entries for the window; Censys's exposure count as a series since 21 October, with its definition; the reconciliation of 1,448 and 1,394; a check of Metasploit, Exploit-DB and nuclei for the php2shell pair and the window, which Pulse could not do because its GitHub searches were refused; a Pulse run over all the CVEs CISA and VulnCheck listed in the window, with the same feeds for every row; honeypot and sensor volumes by day, to test whether adversaries "keep working a small set of bugs"; and the time from publication to a KEV listing, by year, to test "how fast".

What this does not claim

• The post is quoted, not endorsed by its author. This article is ours.
• NVD's count differs from the post's, and both are snapshots of moving records.
• VulnCheck's KEV and Censys's dashboard were not read. The table marks them as such.
• "No reference in NVD" is not "no exploit anywhere". NVD's references are incomplete.
• The yearly ratio is a rate, not the share of the same set of CVEs.
• The compromise record is a time-bounded absence. One statement from one organisation would end it.

Where this comes from

Jeremiah Grossman's LinkedIn post on php2shell, written four days after the disclosure, as shared with me on 27 October 2026. Public data read on 27 October 2026: NVD's CVE API 2.0 for the window and for yearly totals; CISA's KEV catalogue, version 2026.10.26; FIRST's EPSS API; the CVE record for CVE-2026-109618; Fortinet's post for Censys's 22 October figure. The PHP story site's data at version 0.1.77: compromise.json, exploitation.json, claims.json, numbers.json and pulse.json, each pointing to its captured sources on the references site. This article's own data: the dataset. Related: what the bitcoin bounty actually proves, PHP October 2026, update 4, the side stories of php2shell, patch for breakfast. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles