Executive Summary

PHP2Shell is the name researchers gave to two vulnerabilities. By number they are CVE-2026-109618 and CVE-2026-109619, and PHP's own assessment puts both at 9.2 under CVSS v4.0. The blast radius is every PHP installation that serves web requests. The patched releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12; anything on 8.1 or below no longer receives updates from the PHP project.

The php.net notice describes the two flaws briefly. In the first, the path PHP takes when it runs out of memory can tear the interpreter down while a request's internal data is only half built, and the request teardown that follows then treats that broken data as sound. In the second, internal state attached to a request survives after the memory holding it has been handed back, so the next request on the same worker process reads the stale state before it is reinitialized. This article does not cover how to reproduce either. If you need mitigations, take them from the php.net notice as written: pin memory_limit and post_max_size in production for the first flaw, and disable session.upload_progress.enabled and restart every worker process for the second. Either way, the answer is the patch.

What makes this incident the subject of this article is not the flaws themselves but what happened on either side of them. Two and a half months passed between discovery and disclosure, the details leaked the day before disclosure, the disclosure date was pulled forward by a day, and the first attack still arrived before the patch. The table below sets that sequence down with times attached. All times are UTC.

Sources: PHP Foundation blog (2026-10-21), the php.net notice archive, both CVE records (retrieved 2026-10-22), daubois.dev, watchTowr, Sansec, and reporting that relays Cloudflare. Where the discovery date splits, both values are written in.

Two rows catch the eye first: 07:43 and 14:00. The attack ran about six hours ahead of the patch. That attacks move fast is not itself news. We covered the tally showing the gap between disclosure and weaponization falling below a day earlier this year. This incident is that tally in the flesh.

The last row of the same table is the one that stays with you longer. At 14:34, nearly seven hours after the first exploitation was observed, the exploitation assessment attached to the records read 'none'. This is not a criticism of CISA. That assessment is a snapshot at the time of retrieval and gets updated later. But what this article is trying to count is precisely when a record held what, and this one row is a textbook case of the question. Outside, the attacks were already arriving. In the field machines read, it still said none had.

The disclosure time does not settle on a single value either. The php.net notice archive and the PHP Foundation blog both put it at 14:00 UTC on 21 October. Yet the publication timestamps baked into the two CVE records are 13:48:34 and 13:54:43, eleven and five minutes ahead of the announced hour. The original scheduled time behaves the same way. The Foundation itself writes "14:00 UTC on 22 October", while watchTowr's official FAQ writes "18:00 CEST on 22 October 2026". That is a two-hour gap. That the same schedule for the same event is recorded differently depending on where you look is what section 2 starts counting in earnest.

The 20 October leak was not a single channel either. The PHP Foundation lists three of them separately on its blog: an anonymous post carrying the CVE numbers, a proof-of-concept video Calif published by mistake and then deleted, and Chainguard, which shipped patched images roughly six hours before the official release. The sentence the Foundation attaches to that last one reads:

"Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release." — PHP Foundation blog (2026-10-21)

An AI turning up a flaw in old code, and that fact becoming the story, is not new here either. An earlier incident with the same shape is already written up on this blog. That piece was about the incident. This one looks at something else: once the incident is over, where does the account of who did what end up, and in what form.

Every vulnerability comes with a credit block, the field in the advisory that says who did what. This incident has two of them. One is the page people read, the GitHub security advisory. The other is the record machines read, the CVE record, a JSON file and the thing security tooling and vulnerability management systems actually ingest. On 22 October 2026 we opened both and copied out the credit blocks in full. Here is the comparison.

Sources: the GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp pages, and both record originals pulled from the MITRE CVE Services API (schema 5.2). Both retrieved 22 October 2026. Values in square brackets are the record's own type field.

Three facts come out of that table. Take them one at a time.

2.1The same company is the finder in one record and the reporter in the other

The CVE record format separates finder from reporter. A finder "identifies the vulnerability"; a reporter "notifies the vendor of the vulnerability to a CNA", the numbering authority. The same party can of course do both, but once the spec has split the values apart, choosing one over the other says something different.

The two records made that choice differently. In CVE-2026-109618, OpenAI is the finder. In CVE-2026-109619, OpenAI is a reporter. The other two parties, Ryan Austin of Calif and Wiz, are reporters on both. This is one incident involving the same four parties in the same week, and the same authority published both records minutes apart on the same day, yet one party's role splits in two.

PHP has not explained why it splits, and this article will not speculate. It could be a slip, or it could mean the two flaws genuinely came to light in different ways. One thing is clear, though. The GitHub page does not show the difference at all. There, all four are 'Reporter' and the word finder never appears. The side a person opens says less than the side a machine reads.

2.2One reporter is missing from the machine-readable record

Three of the four reporting accounts on the GitHub page can be placed fairly easily. lcfr-hax links calif.io from the profile, and sagitzadik-wiz and amyb-oai carry the employer in the handle itself. The fourth, tomash-areion, has no repositories, no bio and no links, so the affiliation cannot be confirmed from outside.

Open the CVE records, though, and this account is not merely unconfirmable. It is not there. Both records carry three entries on the reporting side and no name in the fourth slot. GitHub attaches credit by looking up accounts, while the same field in a CVE record is a free string, so the two records wrote the same people from the same incident into different identity systems. Along the way, one person fell out of one of them.

Resolution varies inside that field too. Copy the three reporting entries from the CVE record exactly as written and you get Ryan at Calif.io, Wiz and OpenAI. The first holds a person and a company; the other two hold only a company. The free-string field allows that, which leaves what to write, and at what resolution, as the choice of whoever is writing. That latitude comes back later. The earlier record we look at in section 3 put a person and a tool into the same field.

There is a comparable mismatch on the fix side. The patch commits carry Nicolas Grekas as a co-author, and that name is absent from the four remediation developers in both records. Neither side is wrong about this. A credit block is not a copy of the commit log, and the two were never meant to cover the same ground. What is true is that someone who wants to know who did this work gets a different list depending on which field they open.

2.3The fullest account sits in a thank-you note, not the official record

There is one more place the same people are written down: the acknowledgements in the blog post the PHP Foundation published on patch day. Put the three records side by side on identity resolution and it runs like this. The CVE record, machine-read and preserved indefinitely, gives company names only. The GitHub page people read gives handles only. And the Foundation's acknowledgement gives team names and personal names.

"Thank you to Calif, especially Ryan A, Wiz, OpenAI Codex Security, especially Amy Burnett, OSTIF, and Quarkslab for their research and responsible disclosure." — PHP Foundation blog (2026-10-21)

Three things appear in that sentence and nowhere else: that the OpenAI side of the work sat with the Codex Security team, that a person on that team is named Amy Burnett, and that OSTIF and Quarkslab, who appear in neither credit block, were involved. Two things are missing from it as well: Google and Anthropic.

That is where section 2 closes. The will to write it down was not what was lacking. The Foundation knew, wanted to say so, and did. It simply said it in prose rather than in a structured field. Prose is not machine-readable, does not aggregate, and does not get reused at the next incident. A blog post eventually moves or disappears; a CVE record stays. And what stays holds three company names and four personal names. The model names are in neither.

"No model name" is a weak observation on its own. If there were nowhere to put one, its absence would be unremarkable. So we opened the spec. In the schema file that defines the CVE record format, the role field on a credit entry takes one of ten values. Here they all are, with the definitions copied from the schema itself.

Source: CVE_Record_Format.json in the CVEProject/cve-schema repository (retrieved 2026-10-22). The field also carries a default: omit the role and the entry counts as finder.

The eighth row is the nail this section hangs on. The spec has a dedicated value for the name of the tool used in the discovery. The ninth has one for whoever supported that work. Both are empty in the two PHP2Shell records.

Nor is this confined to the spec. When you draft a security advisory on GitHub, the role you attach to each credited party is a dropdown, and that list still contains 'Tool — names of tools used in vulnerability discovery or identification'. The PHP side looked at that dropdown and picked only Reporter and Remediation developer.

3.1We counted how often that field actually gets used

A field existing and a field being used are two different claims. So we counted how many records each role value appears in, across the repository that holds every published CVE record. The figures are as of 22 October 2026, against the 92,928 records that carry a credit block at all.

Counted 22 October 2026. A single record can carry several roles, so the counts sum to more than 92,928 and the percentages to more than 100%.

The method and its limits go down alongside the numbers. This article is prosecuting figures that arrive without a method, so ours cannot carry the same flaw. The method: GitHub code search, counting the files in the CVE record repository that contain each role value. There are three limits. A value appearing several times in one file still counts as one. Records stored with a string form different from ours can be missed. And there is no guarantee the code search index covers a repository that large in full. So this count is likely to run below the true figure, and is better read as a lower bound.

The order of magnitude holds regardless. Where finder sits in the tens of thousands, tool sits in the hundreds. It does not reach one record in a hundred. Sponsor is five times rarer again. The fields exist, and almost nobody fills them.

3.2Eighteen records already carry an AI's name

Almost nobody is not nobody. Searching for records that carry the name of Google Big Sleep, Google's vulnerability-finding AI, returns eighteen. We opened six of them and copied the credit blocks out as written.

Retrieved 22 October 2026. Eighteen records in all carry 'Google Big Sleep'; the six above are the ones whose credit blocks we checked directly.

That table closes section 3. Three separate numbering authorities have, over more than a year, written the name of an AI discovery tool into official records. The top row in particular is the finished version of what this article proposes in section 6. It gives a person's name and affiliation, appends "with assistance from Google Big Sleep", and so holds a human and a tool in a single string. The role assigned is finder. No new field had to be created, and no spec revision had to be waited for.

PHP is under no obligation to write it this way. How a credit block is used is the numbering authority's discretion, and taking issue with that discretion is not the purpose here. All this section records is the following. A method was already in use, and on this occasion it was not used.

One more thing attaches here. Since May 2025, curl's report intake form has asked whether AI was used to find the issue or to write the report. The answers are published nowhere. The same curl wrote Google Big Sleep in as the finder on CVE-2025-9086, so the capability is plainly there. The disclosure is collected at the intake desk and never flows into the public record. That break is what joins section 3 to section 6. That recordkeeping rules come before any new body you might build is a point we already made from the financial supervision side.

Outside the official records there was plenty of talk. Four parties announced AI results of their own in the same week, and most coverage named only one of them. Before putting the four in a single table, though, one premise has to go. There are not four companies here.

Google closed its acquisition of Wiz on 11 March 2026. The deal was worth $32 billion, and Wiz operates under Google Cloud while keeping its brand. So "Google independently found the flaws with Gemini 4 Argon" and "Wiz wrote on its blog that it used Gemini 4 Argon" are not overlapping claims from two separate companies. They are one company crediting the same model in two places, once under the Wiz brand and once through Google's official account. OpenAI knows this too, and its own announcement introduces Wiz as the AI security company Google acquired in March, in order to distinguish it from OpenAI's own work. The original announcement page is access-restricted, so that sentence was confirmed through a syndicated copy.

Seen from the official records, the picture simplifies once more. There is no Google account on the reporting list. In this incident, the Google model is not a reporter but a tool that appears inside Wiz's announcement. The table below adds that distinction and measures all four parties on the same items: what each claims and what each offers as grounds.

Each party's announcement and both credit blocks, measured on the same items. The Anthropic row is a different task and is not here to be scored against the others; why it is in the table at all is explained below.

The last row needs one qualification. The model name cell on the official-records side reads 'nowhere', and strictly speaking it gets within one hop. Open the reference lists on the two CVE records and the only link PHP attached to its own record is its own GitHub advisory. The Wiz post that names all three models is not there. It reaches the record through the container CISA appended afterwards, tagged third-party-advisory, and both records look the same.

So the closest official path to a model name in this incident was a reference link rather than a credit block, and the party that added the link was not PHP, which issued the numbers, but a third party. The reference field has no slot for who did what. A link points at something to read; it does not assign credit. When a machine scrapes the record to extract "who found this vulnerability", no tool follows that link through.

4.1A multiple with no denominator

The emptiest row in the table is Google's. Google's official account wrote that Gemini 4 Argon found "more than twice as many" vulnerabilities as a baseline model, and that it caught critical risks earlier frontier models had missed. Raluca Ada Popa, who leads Gemini security at Google DeepMind, said that with Gemini 4 Argon the Wiz team had shown why frontier AI changes the game for cyber defense.

What that two is a multiple of appears nowhere. Which model the baseline was, how many items were compared, which codebase it was measured on, what counted as a vulnerability — all of it is missing. We went looking for a public measurement document that would support the claim, and did not find one. Not finding it is itself the result of this subsection. We could not even determine whether this is the same measurement as the benchmark scores presented at the Gemini 4 Argon launch on 30 September, or a different one.

We have looked at the same model and found the same hole before. Writing about the vetted access program for Gemini 4 Argon, we noted that the eligibility criteria were public while the record of who passed and why was not. This time the number is public and how it was produced is not. The pattern of leading with a figure and leaving the method out is one we have already seen in an audit of companies advertising AI.

4.2The only party that wrote both a denominator and a method claimed no credit

In the table, the one row with both of those columns filled in is Anthropic's. And Anthropic claims no credit for this incident. It simply put out numbers for an entirely different task in the same week. That task is not vulnerability discovery but attack surface reduction, which means shrinking the range of code and configuration an attacker can reach. 493 is the count of items flagged that way, and Anthropic does not call them vulnerabilities either. No CVE numbers were assigned.

The denominator side is written out like this. 25 projects, more than five million lines of code, 17,000 configuration options catalogued of which 3,842 are security-relevant. 162 configuration combinations were allowed without warning, and 94 of those silently disabled a security feature. In the OpenSSH case, roughly 4,500 lines of new code were reachable by a pre-authentication client, about 16% of the daemon's pre-auth code, and after the fix the reachable code shrank by about a fifth. Upstream accepted one of these: OpenSSH.

Anthropic also wrote down the limits of its own measurement. It is the only one of the four announcements that does.

"It is perhaps impossible to measure how many unknown vulnerabilities are in any given codebase." — Anthropic, attack surface reduction research post (2026-10-20)

That sentence sends you back through the whole table. The party claiming no credit wrote the denominator, the method and the limits. No party claiming credit filled any of the three in full. Which of them found more cannot be told from this table, and that it cannot is what the table tells you.

4.3The company that built the model and the person who used it describe the same discovery differently

What "AI found it first" actually means does not settle on one answer either. OpenAI's announcement frames the discovery as time won for the defense.

"To our knowledge, frontier AI found these vulnerabilities before attackers did, opening a Defender's Window for maintainers and security providers to prepare fixes and protections ahead of disclosure." — OpenAI announcement. ⚠️ The original page is access-restricted; confirmed through a syndicated copy.

Ryan Austin of Calif, who used an OpenAI model in that work, drew the scope tighter in their own write-up. No special experimental rig and no model access unavailable to the public were used, and a human had to aim the model at past vulnerability patterns. In the same vein, Calif wrote that no model can mine "all the bugs" from a simple prompt alone. The two accounts are not in conflict. One describes an outcome and the other describes a process. But a reader who sees only one of them walks away with a completely different picture. And neither is in the official records.

4.4Several numbers circulate for the blast radius too

The habit of not measuring on the same ruler is not confined to credit blocks. Three different numbers circulated for how much of the web this incident touches. Much of the coverage said "up to 70% of all websites"; other coverage said "75 to 80%". Checking W3Techs, the source generally pointed to, gives 69.3% on the day of the incident. That is PHP's share among websites whose server-side language is known, as of 21 October 2026. The same tally breaks down as PHP 8 at 65.2%, PHP 7 at 27.0% and PHP 5 at 7.7%.

Only one of the three states both its as-of date and its denominator. The other two are either rounded or cannot be traced back to a source. The spread between the three figures makes little practical difference; any of them supports the same conclusion, which is "nearly the whole web". That almost every number spoken about this incident shares the same flaw is still worth recording.

Announcements come from the discovery side. The people who work where discovery ends do not issue announcements. This section looks at them.

2026 is not the first time the PHP side saw signs of this flaw. During Quarkslab's external audit in 2024, a core developer saw an indication that the out-of-memory handling had a problem. At the time the attack was theoretical and no path to code execution had been found. Fixes were proposed, but each carried its own cost: breaking backward compatibility, introducing a new denial-of-service risk, or requiring thousands of extensions to be changed. No consensus formed, and time passed. The Foundation describes that delay in its own words:

The delay was "a structural failure, caused by both the security team's decision process and its lack of resources". — PHP Foundation blog (2026-10-21)

In 2026, Calif and Wiz arrived with working exploits, the impact was settled, and the fix went to the top of the queue. What happened next, in numbers, runs like this. The fix commits went in separately on each supported branch, at roughly 390 to 420 files and 10,000 to 12,000 lines per branch. Four remediation developers are named on those commits. This article's criticism is not aimed at those four. The opposite. While four announcements were going out, the people doing the fixing numbered four.

Some secondary coverage reported that the Foundation created an ecosystem security team in the wake of this incident, while the Foundation's own post dates that team to May 2026, five months earlier. What this incident changed is not the existence of the team but the way decisions get made. The picture of an organization with nothing in place is not accurate.

In the same post the Foundation also brought up money. It asked companies that build products and services on PHP to sponsor the PHP Foundation at a level matching how much they depend on it. Meaning: the cost of adding people to validate and to fix has to come from somewhere.

5.1curl was stopped once by quality and once by volume, then answered a third way

What happens on the receiving end when reports pile up is something curl went through first. The story does not end with a pause and a return; it goes one step further.

The first stage was quality. The share of valid reports, above 15% for years, fell below 5% in 2025. Fewer than one in twenty. So on 31 January 2026 curl shut its bug bounty down, a channel that had run since April 2019, confirmed 87 vulnerabilities and paid out more than $100,000. The reason Daniel Stenberg gave was to remove the incentive to send in fabrications. Intake reopened without rewards in March 2026, and by April the valid rate was back to 15–16%. That is how the quality problem resolved.

The second stage was volume. Even after quality improved the inflow did not shrink, and new submissions had to be halted outright from 1 July to 3 August 2026. Stenberg wrote that it might have been the best call he had made in a long while. The third stage lands the day before the PHP patch. On 20 October, curl announced that it would stop taking low and medium severity vulnerabilities in private and would file them openly on GitHub instead, starting 26 October.

"We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster." — Daniel Stenberg (2026-10-20)

In the same post Stenberg characterizes the reports AI produces. A good share of the incoming vulnerabilities involve odd sequences or option combinations a model dreamed up, where something unexpected does happen but is unlikely to occur in practice. The real risk to users is close to nil, yet they consume project resources all the way through the CVE process. He also wrote that over the past few years more than 90% of all reports were quickly triaged below high severity.

Sliding from there into "AI reports are garbage" would be a mistake. curl itself wrote in April 2026 that by now almost every security report uses AI in some form and the quality is very high, and the same project wrote Google Big Sleep in as a finder on a record. The question is not who used what. It is what comes attached.

5.2curl is not the only project that narrowed its intake

Over 2026 a string of others made the same call. HackerOne's Internet Bug Bounty paused new submissions on 27 March, writing that AI-assisted research was widening the scope and speed of vulnerability discovery and that it would revisit its structure and rewards. Google narrowed its open source vulnerability rewards program in two steps: on 19 March it began requiring reproduction steps or an already-merged patch for top-tier memory corruption reports, and on 1 October it closed product vulnerability intake entirely. The stated reason for closing was a sharp rise in automated submissions, the large majority of them invalid.

What those decisions share as background is volume. HackerOne's platform-wide figures, released in March 2026, put report counts up 76% year on year, with 25% of those confirmed as actual vulnerabilities. Both figures are relayed through press coverage; we could not open HackerOne's own notice directly. Only the denominator, platform-wide reports, and the as-of date of March 2026 are stated, so what was counted as valid could not be confirmed.

That chain got a piece of its own, working from Google's notice and rule text. The conclusion there was that what divided the closed channels from the open ones was not who the reporter was but whether machine-runnable evidence came attached. This article looks at that conclusion from the other side. That piece was about demanding evidence of reports coming in; this one is about what is left in the official record once everything is done. The two are the front and back of the same demand. Take evidence in at the door and fail to write it down on the way out, and the evidence you collected gets used once, for that one incident, and disappears.

That is the count. This section is the proposal drawn from it, and it keeps to what a reader can do inside their own organization today. There is no need to wait for an external spec to change. As section 3 showed, these items already have a place in the standard format, and some authorities are already using it.

There are six things to write down when an AI-assisted discovery goes into the record. If you receive reports, ask for these six alongside. If you send them, write these six in. It amounts to adding six lines to an internal security report form and an advisory template.

The way to get all six into one line already exists. The top row of section 3 was that form: a person's name and affiliation, then "with assistance from Google Big Sleep" appended, filed under the finder role. No new field was created and no spec was amended. It was one more degree of detail inside the field that was already there.

What not to write is equally clear: a multiple with no denominator. A figure like "twice the baseline" that omits the comparison and the measurement conditions can be neither verified nor rebutted by the reader, so in the end it conveys nothing at all. If you cannot write the number properly, it is better to write without the number.

One last point on scope. These six items do not make a claim that "AI found it" true. They only make it checkable later. The reason this article could not rule on who found PHP2Shell first is the same. The grounds for ruling are not in the record. Whether they will be absent at the next incident depends on what gets written down at this one.

Sections 1 through 6 are what we confirmed in the credit blocks, the spec text and the parties' own announcements. This section is what those documents do not say, and why Pebblous spent so long looking at this incident.

7.1Our work is not the diagnosis but the report card attached to it

The core of what Pebblous does with DataClinic is not the diagnosis itself. It is attaching a report card to the diagnosis: leaving in structured fields what was measured against which criteria, how many items out of how many were caught, and how someone else can re-run that verdict. This incident is the precise inverse of that work. Three parties named a model in public and the machine-readable record carries not one line of it, and the two records that do remain disagree with each other. It is a working illustration of what happens when "AI found N things" is a figure with no report card attached, and it happens in the one field where verification ought to be strictest.

7.2The schema is fine and the fields are empty

The defect this article deals with is not a security defect but a record defect. And a record defect has the same shape as what we see in data all the time: the value is there and how it came to be is not. The label is there and who attached it, when, against what criteria, is not. The figure is there and the denominator is not.

Sharper still: the fields already existed. The spec has separate values for tool and sponsor, and splits finder from reporter, and 774 records out of 92,928 use the tool field. They are empty not because no schema exists but because nobody filled them. That is exactly the most common failure on the ground in data quality. The spec is fine, the fields are empty, and months later nobody can explain the value.

This case goes one step further. The same incident was written into two systems differently, and the page people read diverges from the record machines read. In data quality that is called a consistency defect. Why it is nastier than a missing value is simple. An empty field is visibly empty, while a divergent field is filled on both sides and looks fine until you open it.

7.3Two questions are coming, one for receivers and one for senders

No organization runs without open source, and AI entering the reporting path has already begun. Two questions are about to reach our customers. On the receiving side: when an internal security report or a vendor arrives saying "AI found this", what do you ask for alongside it? On the sending side: when your own team reports something it found with AI, what do you write into the notice?

The six items in section 6 are the minimum answer to both. They can go into an internal form today without waiting for an external spec to change, and as section 3 showed, each one already has a place in the standard format. Not having to invent a new field is the only advantage of this proposal, and its largest.

7.4Opening the record instead of delivering a verdict

This incident will be consumed through two frames over the coming weeks: "AI has finally surpassed humans" and "AI discovery is overblown". Both are verdicts, and neither takes its grounds from the official record. Pebblous stands in a third place. It does not rule; it opens the record. It opens both CVE records and compares them, counts the empty fields across tens of thousands of entries, and goes looking for every prior case.

It is a place we have stood a few times already: companies that lead with a figure and leave out the method, the argument that recordkeeping rules come before a supervisory body, a program whose criteria are public and whose decisions are not. This article is the fourth along that axis. All that changed is the stage. The same hole opens even in the field where verification ought to be strictest.

The sources differ in grade, so they are grouped. The first group is the credit blocks and the spec text, and every comparison in sections 2 and 3 comes from it. The second is primary material from the PHP side. The third is vendor announcements, which are primary sources for "that company said this" rather than for the facts of the incident; that distinction is kept sentence by sentence in the body. The fourth is primary material from maintainers, and the fifth is press and analysis, attributed in the body each time it is used.

Credit blocks and spec (primary)

• 1.CVE Record CVE-2026-109618 ("RCE via OOM corruption"). MITRE CVE Services API, retrieved 22 October 2026 — the credit block in the section 2 comparison, the 13:48:34 UTC publication timestamp, the CVSS v4.0 score of 9.2, and the exploitation value in CISA's assessment container all come from here. The reference-list comparison in section 4 was done against the same original: the only reference PHP attached is its own GitHub advisory, and the Wiz blog sits in the CISA container tagged third-party-advisory. Both records are identical on this. cveawg.mitre.org
• 2.CVE Record CVE-2026-109619 ("RCE via stale global state"). Same API, same retrieval date — publication timestamp 13:54:43 UTC. OpenAI's role differs from the record above. cveawg.mitre.org
• 3.GitHub Security Advisory GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp (php/php-src) — the left-hand column of the section 2 comparison. The four reporting accounts and their role labels come from here. github.com
• 4.CVE Project. CVE Record Format schema (CVE_Record_Format.json) — the ten role values and definitions in the section 3 table, and the fact that omitting the role defaults to finder. cveproject.github.io
• 5.CVEProject/cvelistV5 repository — the per-role tallies in section 3.1 (22 October 2026, against the 92,928 records carrying a credit block) and the eighteen Google Big Sleep records in section 3.2. The method and its limits are written into the body of section 3.1. github.com
• 6.GitHub Docs. Creating a repository security advisory — the basis for the statement in section 3 that the credit role dropdown contains 'Tool'.
• 7.CVE-2025-6965 (Google, 2025-07-15) · CVE-2025-59730 · CVE-2025-62490 (Google) · CVE-2025-9086 (curl) · CVE-2025-11731 · CVE-2026-83596 (Red Hat) — the section 3.2 table. The credit string of the first is reproduced verbatim in the body.

PHP side (primary)

• 8.PHP Foundation. Today's PHP security release and how we're strengthening PHP security (2026-10-21) — the acknowledgement in section 2.3, the "structural failure" line and the Chainguard sentence in section 5, the May 2026 founding date of the ecosystem security team, the sponsorship request, and the statement that disclosure was brought forward by a day all come from here. thephp.foundation
• 9.php.net. Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21, 14:00 UTC) — the description of both flaws in section 1, the four patched releases, the blast radius, and the mitigations. The mitigations in the body are only those carried in this notice. php.net
• 10.php/php-src fix commits (per supported branch) — the patch size range in section 5. The same change landed under a different hash on each branch, so no single hash is asserted.
• 11.Daubois. CVE-2026-109618 PHP2Shell rumors (2026-10-21, written by a self-identified member of the PHP security team) — the leak sequence in section 1, and the correction that the CVSS 10.0 figure was an unsupported claim made by the leak post itself. The official score is 9.2 for both.

Vendor announcements (primary, cited as claims)

• 12.Wiz. PHP2Shell: PHP RCE — the 19 and 24 August entries in the section 1 timeline, and the statement in section 4 that three tools (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol) were used. CISA attached this post to both CVE records as a third-party-advisory reference. wiz.io
• 13.OpenAI. Patch the Planet: global response coordination as agents uncover critical vulnerabilities (2026-10-21) — the "Defender's Window" quotation in section 4.3 and the sentence identifying Wiz as Google-owned. ⚠️ The original page is access-restricted and was read through a syndicated copy, which the body states.
• 14.Anthropic. Attack surface reduction research post (2026-10-20, Chris Rohlf, Frontier Red Team) — every denominator figure in section 4.2 and the sentence on measurement limits. This task is not vulnerability discovery and is not directly related to PHP2Shell.
• 15.Google's official account posts on Gemini 4 Argon, and remarks by Raluca Ada Popa (Google DeepMind) — section 4.1. We could not find a measurement document supporting "more than twice as many as a baseline model".
• 16.Calif Research write-up (Ryan Austin) — the statement in section 4.3 that no special experimental rig and no non-public model access were used. ⚠️ We could not confirm the original URL and cited it through a syndicated copy.
• 17.Trail of Bits. Patch the Planet program page — the program-level tallies in the Calif and OpenAI row of section 4. It is a live tally, so the values shift with the retrieval date.

Maintainer load (primary)

• 18.Daniel Stenberg. Do minor curl vulnerabilities in the open (2026-10-20) — the 26 October switch in section 5.1, the overload quotation, the characterization of AI-generated reports, and the statement that more than 90% of reports fall below high severity. daniel.haxx.se
• 19.curl vulnerability disclosure policy and report intake form — the AI disclosure question in section 3.2 (added May 2025) and the bug bounty shutdown and return in section 5.1. curl.se
• 20.Google OSS VRP notices — the 19 March 2026 rule tightening and the 1 October close of product vulnerability intake, section 5.2. HackerOne's 27 March 2026 notice pausing Internet Bug Bounty submissions is used in the same subsection. ⚠️ The platform-wide figures in that subsection (reports up 76% year on year, 25% confirmed valid) are relayed through press coverage because we could not open HackerOne's own notice, and the body says so.

Press and analysis (attributed where used)

• 21.BleepingComputer. PHP ships emergency patches for critical PHP2Shell flaws (2026-10-21) · Sansec. PHP2Shell research post · watchTowr. PHP CVE-2026-109618 FAQ · CrowdStrike analysis — parts of the section 1 timeline and the blast radius figures in section 4.4. ⚠️ CrowdStrike and Sansec differ on the exposure conditions and may be describing different CVEs, so the body does not come down on either side.
• 22.W3Techs. Usage statistics of PHP (69.3% as of 2026-10-21) — section 4.4, set alongside the 70% and 75–80% figures in press coverage. Google's closing of the Wiz acquisition (11 March 2026, $32 billion) was cross-checked against multiple outlets and Alphabet's quarterly filing.

Related Pebblous articles

• 23.An earlier incident of AI finding flaws in old code (section 1) · the tally putting disclosure-to-weaponization below a day (section 1) · recordkeeping rules come before a supervisory body (sections 3 and 7) · public criteria, no record of the decision (sections 4 and 7) · leading with a figure and leaving out the method (sections 4 and 7) · the projects that closed their intake as reports piled up (section 5)