Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?

Fact-check: how sure can you be of each claim

Every claim on this site has a status word chosen by the agent that wrote it. The fact-check desk grades each one again, independently, by opening the captures it cites and reading them: what kind of statement it is (a record, a count, a quote, an opinion), how strong the evidence is on a scale from A0 to A6, whether anything contradicts it, and whether the status word claims more than the evidence carries. Where the answer is "not as far as the site says", it opens a ticket. It highlights; it does not fix.

70 of 70 claims graded, last run Run-2 against vault commit 31ccc515c29f. 10 can be relied on without reservation (A5 or A6, holding as worded, uncontested, not an opinion, and no open finding against their wording). 11 carry a status word stronger than their evidence. 145 tickets are open.

The spectrum of evidence

Level	Means	Claims now
A0 Unsupported	No capture carries it, or the cited capture does not say it	0
A1 Weak signal	Second hand, unnamed, blocked, or only partly carried by its capture	6
A2 Reported	One named party says it, in a capture this desk checked	33
A3 Echoed	Several outlets say it, tracing to one origin	8
A4 Corroborated	Two or more independent parties say it, at least one checked in a capture	5
A5 Confirmed	Two or more independent primary sources say it, each checked in a capture	1
A6 Established	The authoritative primary record carries it, or this site counted it from a captured file	15
refuted	A stronger source says otherwise	2

A level is earned from captures the desk opened and read, never from how often a thing is repeated: ten outlets restating one headline are one source. An open contradiction caps a claim at A1 and a dispute at A2 until it is explained. An opinion is shown as an opinion and never rises above A3 as a fact; the facts under it are graded in its note. Absence of evidence is not shown, which is not the same as false.

Every claim, graded

Pick how sure you need to be. "Only what I can be very sure of" shows claims at A5 or A6 that hold as worded, are not contested, are not opinions, and have no open finding of medium or high severity against them.

Claim, and why it is graded so	Fact-check	Kind	Verdict	Site status	Tickets
CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalog The CISA alert itself carries the dated negative and the captured KEV JSON (catalogVersion 2026.10.21, 1754 entries, counted by this desk) contains neither CVE; the CVE record's CISA ADP SSVC also says Exploitation none at 14:34Z on 21 Oct. All three are CISA, one party, but each is the authoritative record for what it says.	A6 Established	State	holds	confirmed	Contradiction-2 Evidence-1 Evidence-10 Evidence-6 Finding-13 Finding-63
The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTC The git output in the vault carries every time in the claim: author date 2026-10-18T17:26:39+02:00 (15:26:39Z), committer date 2026-10-21T16:06:22+02:00 (14:06:22Z), and Ilija Tovilo's merges 8.2 into 8.3 at 14:12:35Z, 8.3 into 8.4 at 14:27:03Z, 8.4 into 8.5 at 14:30:04Z, plus 389 files, +10689, five authors. 'Entered the public branches at 14:06' reads a committer timestamp as a push time, which git does not record.	A6 Established	Record	holds in part	confirmed	Finding-41 Finding-69
The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' GHSA-w8hw's Mitigation section states the mechanism in nearly these words, the php.net ChangeLog carries the exact line for all four releases, and the 7.4 branch commit carries the same title. Primary records carry all of it.	A6 Established	Record	holds	confirmed	Finding-70
Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed request The fix commit itself (read from a clone, raw patch hashed in the vault) says 'Replace bailout on OOM with UnwindExit' and 'Properly reset various globals that may be accessed during startup', and removes zend_bailout() from the allocator; the two advisories describe the same two mechanisms. The authoritative record carries it.	A6 Established	Record	holds	confirmed	Finding-71
The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areion Both captured GitHub advisories list exactly these four handles as 'Reporter' (A6, the record itself). The affiliations in brackets are inferred from handle suffixes and other pages (Calif's '@lcfr_hax', Wiz author Sagi Tzadik, the Foundation's thanks to Amy Burnett of OpenAI Codex Security), not stated by the advisories.	A6 Established	Record	holds	confirmed	Finding-73
The risks require immediate patching across United States Government departments and agencies NSA's own press release says 'These risks are serious enough to require immediate patching across United States Government departments and agencies.' As a statement of what NSA says, the primary record carries it, so 'reported' understates. It is NSA's statement, not a binding directive; no CISA emergency directive is visible on the CISA home page at 08:13Z.	A6 Established	Advice	holds	reported	Finding-74
Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTC The CERT.LV notice, the national authority's own record, carries every part: a decision to restrict access from abroad to several state digital resources, possibly until Monday 26 October, and at the 23:00 local (EEST, 20:00Z) update lsm.lv and 112.lv restored. The UTC conversion is correct (Latvia on EEST until 25 Oct).	A6 Established	Event	holds	confirmed	Finding-24 Finding-25 Finding-77
Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline CISA's alert says organisations that cannot update immediately, or that use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until patched or updated. The party's own record carries it.	A6 Established	Advice	holds	confirmed	Finding-88
If an immediate update is not feasible, take the system offline until it can be fully mitigated Both of NSA's own pages carry the advice in nearly the claim's words: the press release ('it is recommended that organizations take the system offline until it can be fully mitigated') and the X post (with the typo 'recommend'). The X post's snowflake decodes to 2026-10-21T13:45:58Z and the capture shows 10.1M views, as the note says.	A6 Established	Advice	holds	confirmed
Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe php.net's advisory carries the claim almost word for word, and both GHSAs and the oss-security post say updating is the only complete/reliable mitigation. The party's own records carry the advice.	A6 Established	Advice	holds	confirmed
Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory finding Counted from the captured Quarkslab page: 2 high, 6 medium, 9 low and 10 informative issues (27 rows), with HIGH-1 and MED-2 redacted and the stated reason 'Fixes are complex and in progress.' No row describes an out-of-memory finding. The Substack piece says the same. The Foundation note is carried.	A6 Established	Count	holds	reported	Finding-95
Remote code execution is confirmed on PHP-FPM As worded, the claim is carried by the PHP security team's own advisory for CVE-2026-109619 (GHSA-6wmf) and its oss-security post, which say RCE was demonstrated on a normal dynamic FPM pool, given a suitable application operation. What is disputed is which flaw does it: the Foundation's blog puts FPM under CVE-2026-109618, whose own advisory says no complete FPM exploit was shown (K-008). That does not touch this claim, so the site's 'disputed' understates it.	A6 Established	State	holds	disputed	Contradiction-8 Finding-48 Finding-49 Finding-96
Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs GHSA-w8hw (the advisory record for CVE-2026-109618) says complete RCE was validated over HTTP against mod_php with default PHP input and memory limits, entirely before application code; oss-security and php.net repeat it. All parts carried by the primary record.	A6 Established	State	holds	confirmed	Contradiction-8 Finding-97
Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Both CVE records (CNA PHP Group) carry CVSS 4.0 9.2 CRITICAL and the four fixed-in versions; the two GHSAs, both oss-security announcements and php.net agree. The authoritative record carries every number, so A6.	A6 Established	Record	holds	confirmed	Contradiction-3 Contradiction-7 Evidence-10 Evidence-6
A web application firewall may provide some protection until systems are patched CISA's alert carries the sentence nearly verbatim, so the advice is established as CISA's. BACS ('alone is not sufficient') and Cloudflare (attackers mutating payloads) qualify it but do not contradict 'some protection'; CERT-FR also recommends WAF-level blocking. 'Disputed' overstates the disagreement.	A6 Established	Advice	holds	disputed	Finding-109 Finding-51
Amazon and Cloudflare saw sites being probed for the flaw Woodward's remark is carried by the BBC, and both companies independently say it in their own captured posts: Amazon (scanning attempts, honeypot hits) and Cloudflare (attack traffic targeting customers). Two independent primary parties, each checked.	A5 Confirmed	Attribution	holds	confirmed	Contradiction-2 Finding-15 Finding-93
watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release Daubois says watchTowr confirmed the bugs and posted both CVE numbers; CybelAngel (via The Repository) independently says watchTowr named both CVEs, and Huntress quotes the same watchTowr line. CERT-EU lists the watchTowr X post as a public report; its ID 2112611507749982605 decodes to 2026-10-20T18:26:48Z, before the 19:30 UTC pre-announcement and the release. The post itself is not captured and watchtowr.com returns 403.	A4 Corroborated	Event	holds	reported	Finding-81
As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim. A search of every vault capture (manifest and unexported) finds no named organisation confirming a php2shell compromise, and several independent parties say none known (Huntress, Imperva, CERT.LV, the German digital ministry via Reuters, the Australian industry minister). A universal negative from a finite, time-bound capture set cannot exceed A4, and it is volatile; "confirmed" without an as-of in the claim text is overstated.	A4 Corroborated status overstated	State	holds	reported	Contradiction-2 Evidence-1 Evidence-10 Evidence-3 Finding-26 Finding-85
The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leak The new time (21 October 14:00 UTC) is in the php.net pre-announcement relayed to oss-security (record). That the original date was 22 October is carried by the Foundation and indirectly by Wiz's thread and the php.net ChangeLog; that the move was because of the leak, by the Foundation and Daubois. The original hour '14:00 UTC' rests on the Foundation alone (echoed by The Hacker News), while watchTowr (via Daubois, Huntress, CybelAngel) put the embargo at Thursday 11am ET, which is 15:00 UTC.	A4 Corroborated measures differently status overstated	Event	holds	confirmed	Contradiction-10 Finding-98
watchTowr sees active exploitation attempts and lists the flaws as exploited in the wild Both cited watchTowr captures are HTTP 403 (A1 as cited), but four independent outlets in the vault quote watchTowr's Jake Knott directly saying it sees in-the-wild exploitation attempts against its sensors, so the first half is A4. 'Lists the flaws as exploited in the wild' is not carried by any capture; Equixly (written before the PHP advisory) says watchTowr 'lists no reported exploitation', an earlier state since overtaken.	A4 Corroborated superseded	Attribution	holds in part	unverified	Contradiction-2 Finding-111 Finding-18 Finding-19
The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched' The quoted words are verbatim in The Cyber Express and, outside this claim's citations, in Newsweek (emailed statement to Newsweek) and the Reuters factbox, which each received the Foundation's statement; CNN independently carries "precautionary measure". Several independent outlets but no Wikimedia-published page, so A4; "reported" fits.	A4 Corroborated	Quote	holds	reported	Finding-114 Finding-29
Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity high The CVSS half is a record (AC:H in the CVE record, A6). The 'much easier' half is Imperva's characterisation, supported by Fastly (single-request trigger; RCE needs binary layout knowledge) and the advisory's reliability caveats; as a reading it caps at A3, so 'confirmed' overstates the claim as a whole.	A3 Echoed opinion status overstated	Opinion	holds	confirmed	Finding-53 Finding-56
The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiative That AI was used is said by each research party in its own capture (Calif, Wiz, OpenAI), but 'found by researchers using frontier AI under Patch the Planet' is a reading: Calif is the only finder shown to be under Patch the Planet, Calif never says 'frontier' and stresses generally available models, and Wiz never mentions Patch the Planet. Readings cap at A3.	A3 Echoed opinion measures differently	Opinion	holds in part	reported	Finding-1 Finding-59
Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link The Scotsman carries the outage, the council's "essential maintenance" and that it had not confirmed a link; the Edinburgh Evening News piece is the same reporter and text (one origin, A3), while LBC, Insurance Business, The Cyber Express and the BBC raw copy independently report the outage. "Late on 21 October" loosely renders "late on Wednesday afternoon".	A3 Echoed	Event	holds	reported	Finding-67
Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs' The Foundation states it and the quoted phrase is verbatim; BBC, The Register, The Record and Feross echo the Foundation (one origin, A3). Daubois separately mentions a short exploitation video that went up and came down, without naming Calif. The time is uncertain: the Foundation's 'As a result of the leak and pre-announcement around 20:00 UTC' can attach '20:00 UTC' to the pre-announcement, which it puts at 19:30.	A3 Echoed	Event	holds in part	reported	Contradiction-9 Finding-80 Finding-9
The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those services The cited primary (Rijksoverheid, 21 Oct 13:59) carries only NCSC.NL taken offline "uit voorzorg" and a general "no active misuse seen yet"; it does not name DigiD, MijnOverheid or Overheid.nl, and the second cited source is a blocked Cloudflare page. DigiD and MijnOverheid are carried by TPO and Insurance Business, Overheid.nl only by Reuters copy (one origin), so A3 for the claim as worded, and "of those services" is the site's own narrowing.	A3 Echoed status overstated	Event	holds in part	confirmed	Finding-27 Finding-28 Finding-84
Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors LBC and Insurance Business carry Edinburgh and Oxford councils and the Met Police unavailable and errors on Bristol, Lambeth and Barnet, in near-identical wording that points to one origin (A3). Neither cited source mentions the Office for Budget Responsibility; only the uncited EADT (PA) says the OBR "had to take down its website".	A3 Echoed	Event	holds in part	reported	Contradiction-5 Evidence-2 Finding-106 Finding-31
All PHP versions from 5 onwards are affected by at least one of the flaws Wiz (a finder) says '>= 5.4'; PHP's own source backports for 7.4, 8.0 and 8.1 imply those are affected; only NCSC-NL and CERT-FR say all of 5.x, and both pre-release texts look like echoes of the leak (CERT-FR lists a 6.x that never shipped). The CVE records list only 8.2 to 8.5 with default unaffected. So 7.4+ is well supported, 5.4+ rests on Wiz, and 5.0 to 5.3 is not shown; disputed caps display at A2.	A3 Echoed disputed	State	holds in part	disputed	Contradiction-3 Evidence-9 Finding-107 Finding-50
Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 August The dates under it are well carried: the hash tweet date is on X and the snowflake ID 2085031675382071483 decodes to 2026-08-05T15:54:24Z (A6); the 11 August report is in both Calif's and the Foundation's pages (A5); the 1 August discovery date is Calif's own word only (A2). 'Found the flaws first' is a reading (max A3): the Foundation says the OOM root cause was found in 2024, OpenAI reported the same root cause the same day, and nothing shows Calif found the second CVE first.	A3 Echoed opinion measures differently status overstated	Opinion	holds in part	confirmed	Finding-113 Finding-2
Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offline Every element is carried by the BBC live page, but Edinburgh council, online stores, the BBC itself and the University of Geneva are only in the 07:55Z raw copy (summary bullet and header-image alt text), not in the cited 08:05Z text capture. One named secondary party, so A2; the vault holds independent and operator captures that raise most items (Wikipedia, Edinburgh, French prefectures, UNIGE) but not "online shops".	A2 Reported	Attribution	holds	reported	Contradiction-6 Evidence-11 Evidence-3 Evidence-4 Finding-22 Finding-23 Finding-57 Gap-1
Frontier AI found the flaw ahead of attackers, giving defenders time to prepare OpenAI's post carries the sentence, but with the qualifier 'to our knowledge' that the claim drops. As a reading it rests on one interested party; the only counter-evidence (Amazon's 17 October honeypot hit) reaches the vault second-hand via The Hacker News, and it shows attackers had exploit information before disclosure, not before AI found the bug.	A2 Reported opinion disputed	Opinion	holds in part	disputed	Finding-58 Finding-7
An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild' Amazon's own post (now cited first) carries all three parts and the quoted sentence character for character; The Hacker News is an echo of the same Amazon post, not independent, so the level stays A2. Amazon's 'broadly exploited in the wild' is disputed by CISA's dated negative and by Austin and Huntress, partly because they measure different things (attempts versus successful compromise) at different times.	A2 Reported disputed	Attribution	holds	reported	Contradiction-2 Finding-122 Finding-14 Finding-60
Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTC Prince's own post carries all four figures and the 01:25 UTC time (UTC browser); the counter and date are known, the population is 'attempts across the Cloudflare network', but the method (what counts as an attempt: rule matches, requests, deduplication) is not stated, so A2 is the ceiling. SecurityWeek, the EADT and Tagesspiegel only repeat it.	A2 Reported measures differently	Count	holds	reported	Finding-61
Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fix The act and time (built images with the fix at 07:41 UTC on 21 October) are the Foundation's and Lorenc 'doesn't dispute the timeline' (The Register). 'Unilaterally broke the embargo' is the Foundation's reading; Lorenc says exploits were in the wild and he notified the coordinated disclosure channel first, which contests 'unilaterally'. Feross and The Hacker News restate the Foundation (one origin).	A2 Reported opinion disputed	Opinion	holds in part	disputed	Finding-10 Finding-62
Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloads Cloudflare's own post carries both halves nearly verbatim; one named party. Echoes (The Hacker News, SentinelOne) trace to the same post.	A2 Reported	Attribution	holds	reported	Finding-64
Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution Helsinki Times carries Valtori restricting incoming public traffic from 12:45 local as a preventive measure; Yle (STT copy) and the Reuters factbox corroborate the precautionary Valtori shutdown but not the 12:45 time. The time rests on one secondary outlet, so A2; status "reported" fits.	A2 Reported	Event	holds	reported	Finding-68
No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress The first half is carried exactly (4:30pm ET = 20:30 UTC). The second half comes from the pre-release section written before the 21 Oct release ('as of this writing'), not from the 20:30 UTC update, and by then Huntress's own 4:40pm update and other parties report public technical details and PoCs.	A2 Reported disputed	State	holds in part	reported	Finding-17
No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoring Imperva's own post carries it verbatim, including that it had the details before disclosure; one named party, a negative about its own customer traffic in an undated window.	A2 Reported measures differently	State	holds	reported	Finding-75
The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one day The KEV JSON (dateAdded 2024-06-12) and the CVE record (datePublished 2024-06-09T19:42Z) give three days (A6), and the php2shell KEV absence is A6 at 08:16Z on 22 Oct. 'Exploited in the wild one day after' rests on Akamai alone (A2), and it describes honeypot exploit attempts; 'the last PHP core RCE' is not shown (CVE-2024-4577 is a PHP-CGI argument injection on Windows).	A2 Reported status overstated	Record	holds in part	confirmed	Evidence-1 Finding-20 Finding-21 Finding-76
Automated exploitation attempts were seen in Latvia; none succeeded CERT.LV's own page carries the automated attempts; it says there are 'no reports of successful attacks so far' (as of 21 Oct 23:00 local, 20:00Z), which is a dated absence of reports, not 'none succeeded'.	A2 Reported	Event	holds in part	reported	Finding-16
On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leaked The Foundation states every element. The time and the CVE IDs circulating are corroborated independently (Equixly: Hacker News post 'about 15:20'; Huntress and CybelAngel: 'morning of October 20', which fits 15:00 UTC as US morning). 'No technical details leaked' is disputed: Daubois (PHP security team) describes a leaked tool screenshot and an exploitation video, and The Hacker News says a PoC leaked. The two Foundation slugs are the same page captured twice, not two sources.	A2 Reported disputed	Event	holds in part	reported	Contradiction-9 Finding-78
The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came down The Hacker News post, its removal and the screenshots spreading are carried by Daubois and corroborated by Huntress, CybelAngel and Equixly (A4). 'Anonymous', 'citing a reliable source' and the screenshot 'credited to Calif.IO' are Daubois alone. Daubois says the screenshot 'leaked alongside the advisory', not that it came down; only the video 'went up and came down'.	A2 Reported disputed	Event	holds in part	reported	Contradiction-9 Finding-79
Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked The Foundation's own sentence carries every element, including its hedge 'may have leaked'. It is one party's self-report; The Register and SecurityWeek repeat it without new evidence.	A2 Reported	Event	holds	reported
Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday before The Register reports, in its own words, that Lorenc said Chainguard learned 'something was coming in PHP' on Friday from one of the researchers and that night independently found the same bugs with its AI harness and a frontier model. One named party, second-hand through one outlet; nobody else checks it.	A2 Reported	Attribution	holds	reported	Finding-82
Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expected Fastly's post says nearly these words; it is one vendor's position (a reading), so A2. The second cited source (the oss-security thread) does not carry it. 'Reported' fits.	A2 Reported opinion	Opinion	holds	reported	Contradiction-11 Evidence-7 Finding-54 Finding-55
The most severe flaws ever detected by AI The BBC attributes to Wiz that the flaws are the 'most severe' ever detected by AI; Wiz's own blog, which the claim cites, says something narrower ('among the most severe vulnerabilities discovered in PHP, and arguably in software history'). A Substack piece relays the WSJ quoting Wiz's co-founder with close wording, so the BBC line probably traces to an interview, not the blog. A reading, held by one party, reported second-hand.	A2 Reported opinion measures differently	Opinion	holds in part	reported	Finding-8 Finding-83
There is no evidence yet that hackers have exploited the flaw The BBC (one named outlet, reporting its own Radio 4 interview) carries Austin saying "Not at the moment", but the claim's wording is the BBC headline, not his words, and his words are narrower: exploitation has not "taken off or been widespread". As a statement of fact it is disputed by Amazon's earlier "broadly exploited in the wild" and by NCSC NZ.	A2 Reported disputed	Attribution	holds in part	reported	Contradiction-2 Finding-11 Finding-12
Reports of active exploitation exist NCSC NZ's own alert carries the sentence verbatim; one named party, unsourced reports. Other agencies captured at about the same time say the opposite (CCCS: no active exploitation identified; ACSC: not aware of successful active exploitation in Australia; CISA: not observed as of publication).	A2 Reported disputed	Attribution	holds	reported	Finding-86
'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated' The NCSC page as captured (last-modified 07:30:02 GMT on 22 Oct) gives the offline advice as step 4 of 6 in other words ('If you are unable to apply the temporary mitigations ...'), so the quote is not verbatim in the party's own capture. The exact sentence is in the BBC, in LBC's article of 21 Oct 15:41 (before the page was modified), and in a CyberExpress copy of the BBC. That is an echo, A3, and points to an earlier NCSC wording.	A2 Reported disputed	Quote	holds in part	disputed	Finding-42 Finding-89
OpenAI independently reported the same root cause on 11 August, with further vectors on 18 September The Foundation's page says this word for word (one named primary party, the recipient of the reports). The GHSA credits and the CVE records corroborate that OpenAI was a credited reporter or finder but carry no dates. OpenAI's own account is blocked; Cybernews relays OpenAI as saying its researcher 'subsequently' found additional flaws after Calif, and the X Community Note disputes OpenAI's discovery role.	A2 Reported disputed	Attribution	holds	reported	Finding-3 Finding-90
Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' The quoted words are verbatim in the @OxfordCity post embedded in the East Anglian Daily Times (PA) capture, but not in the cited Oxford Chronicle, which only paraphrases ("a precautionary response to a worldwide technology problem rather than a cyber incident"). One capture carries the exact words, so A2.	A2 Reported	Quote	holds	reported	Finding-30
The pre-announcement was published at 19:30 UTC on 20 October Only the PHP Foundation states 19:30 UTC, and the same post later says 'pre-announcement around 20:00 UTC'. The oss-security relay of the php.net text (Date 13:22:51 -0700 = 20:22:51Z) bounds it from above, and the feed's 20:32:00Z is later than that relay, so the feed time cannot be the publication time. One party's self-report, A2; 'disputed' fits.	A2 Reported disputed	Event	holds	disputed	Finding-40 Finding-92
The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixed Calif says Quarkslab's audit 'rediscovered the same OOM issue' and 'exploitation was not proven, hence the bug was not fixed', but Calif says it confirmed this 'from PHP', so it is not independent of the Foundation. The Foundation says something different: a PHP core developer found the OOM signs while fixing a Quarkslab finding, and the fix stalled over trade-offs and resources, not only unproven exploitation. Quarkslab's own summary describes no OOM finding.	A2 Reported disputed status overstated	Attribution	holds in part	confirmed	Finding-5 Finding-6 Finding-94
The fixes were released at 14:00 UTC on 21 October 21 October is carried by every primary record. 14:00 UTC was the scheduled time (php.net pre-announcement, oss-security relay, CERT-FR, ACSC 0100 AEDT); only Daubois states it after the event ('Published: 2026-10-21, 14:00 UTC'). The artifacts are stamped earlier and later: GHSA 13:34Z, tags 13:35:38 UTC, CVE records 13:48Z and 13:54Z, GitHub release 14:06:46Z; CERT-EU says 13:30 UTC. 'Disputed' fits.	A2 Reported disputed	Event	holds in part	disputed	Contradiction-10 Finding-39 Finding-99
PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 October Both figures are carried, but only second hand: VulnCheck's 2,608,039 hosts via The Hacker News and SecurityWeek (one origin), and Censys's 2.58 million seen, 1.57 million unpatched via SecurityWeek alone; no scanner's own page or method is captured, so A2. 'Of which' wrongly makes Censys's 1.57 million a subset of VulnCheck's 2.6 million; it is a subset of Censys's own 2.58 million.	A2 Reported measures differently	Count	holds in part	reported	Contradiction-4 Finding-100 Finding-34
Something like 30 million websites could be affected The BBC capture carries Alan Woodward's words 'something like 30 million websites' (from Radio 4's Today). One named party, relayed by one outlet, with no population, method or counter, so A2; 'reported' fits.	A2 Reported	Count	holds	reported	Finding-101
PHP is used by almost 70% of websites Cloudflare, OpenAI and Wiz each state roughly 70%, but they restate one survey (Cloudflare links W3Techs; Tenable and Imperva name W3Techs), so this is an echo of one origin, and the survey's method is not captured, which caps a count at A2. The figure W3Techs publishes is a share of websites whose server-side language is known, a qualifier the claim drops.	A2 Reported measures differently	Count	holds in part	reported	Contradiction-1 Finding-103 Finding-32 Finding-33
About 6,000 potentially affected resources in Latvia, a few hundred in the public sector CERT.LV's own page (update of 21 Oct, 23:00 local) says about 6,000 potentially affected resources in Latvia, only a few hundred in the state sector. One primary party, no method stated, so A2 for a count; 'reported' fits.	A2 Reported	Count	holds	reported	Finding-104
Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 October Only Cloudflare gives a pre-disclosure go-live time (03:02 UTC on 21 Oct, its own account). Imperva says it verified protection and monitored before the announcement but gives no time; Akamai and Fastly give only a 21 October post date; Fortinet's article is dated 22 October 07:55, after disclosure, so 'went live hours before disclosure' does not cover it. Each date is the vendor's own word, A2; 'confirmed' overstates.	A2 Reported status overstated	Event	holds in part	confirmed	Finding-110 Finding-46 Finding-47
Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cache The operator's own blog carries both parts verbatim: webservers off for all wikis, a 13-hour downtime, and about 94% of wiki pageviews served correctly. The 13-hour outage is the operator's own record of its own action, but the 94% is a self-reported figure with no stated method, which the model caps at A2, so "confirmed" overstates it.	A2 Reported status overstated	Count	holds	confirmed	Finding-112
Wiz Research independently discovered the first flaw on 19 August and reported on 24 August Wiz's timeline carries 'discovers the first PHP vulnerability' on 19 August and the report on 24 August, and the Foundation independently confirms a Wiz report on 24 August. 'Independently' is not in any captured primary: Wiz itself says it worked with Calif and OpenAI 'on discovery', and the Foundation frames Wiz's report as 'further attack vectors'. 'The first flaw' means Wiz's first finding, not the first flaw overall.	A2 Reported	Attribution	holds in part	reported	Finding-115 Finding-4
Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS Calif's own post lists all eleven applications as confirmed pre-auth RCE; Wiz independently confirms WordPress, Drupal and Joomla. The full list rests on one named party (A2); WordPress/Drupal/Joomla alone would be A4. No third-party reproduction in the vault (Huntress says it did not reproduce), so 'reported' fits.	A2 Reported	State	holds	reported	Finding-116
The 8.5.12 fix may be incomplete, or there is a third, different bug The only carrier is a relay on oss-security of unnamed Fediverse posts ('While not yet fully confirmed'), not captured themselves; PHP is reported second-hand to have called it unrelated. Second-hand and unconfirmed is A1, and nothing shows the fix is incomplete; 'unverified' fits.	A1 Weak signal opinion disputed	Opinion	not shown	unverified	Contradiction-11 Evidence-5 Evidence-7 Evidence-8 Finding-125 Finding-72 Gap-2
The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasible The captured BBC page does not say this: it says the NCSC 'as well as its counterparts in the EU and Australia' urged users 'to apply the fixes', and attributes the offline quote to the NCSC alone. On the substance, NCSC (after mitigations) and NSA advise offline, CERT-EU and CERT-FR advise isolation, and Italy's ACN advises taking sites offline; only Australia is not shown (ACSC's page as captured has no offline advice). 'Contradicted' overstates an absence for one of four parties and mislabels the BBC's statement.	A1 Weak signal	Advice	holds in part	contradicted	Finding-43 Finding-44 Finding-45 Finding-87
None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200 rjmendez's README carries both halves, but the VulnCheck half is second-hand (VulnCheck's review is not captured), so A1; the lab half is rjmendez's own (A2). Huntress, the second cited source, does not carry either half. 'Reported' implies one named party checked first-hand, which only the lab half has.	A1 Weak signal status overstated	Attribution	holds	reported	Finding-52 Finding-91 Gap-3
Roughly 70% of the Internet is affected Wiz's own headline and X post carry '70% of the Internet', but the body of the same post gives the basis as PHP powering '70% of all websites', a share of websites using PHP with no measurement of what is affected. A count with no population, method or counter for 'affected' stays weak; the status 'unverified' fits.	A1 Weak signal measures differently	Count	holds in part	unverified	Contradiction-1 Finding-102 Finding-124
674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerable The inventory files at commit cca173c64ec5 are in the vault (tree and git bundle), and counting them gives 675 rows: 206 Vulnerable, 46 Fix, 418 Investigation, 4 Not vuln and 1 row with no status. The 206/46/418 figures hold; the total 674 and '3 not vulnerable' are contradicted by the file itself, because the vault's parsed JSON dropped the iBabs row. 'Confirmed' overstates a count the file contradicts.	A1 Weak signal contradicted status overstated	Count	holds in part	confirmed	Finding-105 Finding-120 Finding-35 Finding-36 Finding-37
Criminals are using AI to 'vibe code' an attack method The BBC carries it only as 'Researchers say', unnamed and second hand (A1). The nearest named source in the vault, watchTowr's Jake Knott via The Record, says it sees in-the-wild exploitation with proof-of-concept tools 'vibecoded with the help of AI'; that does not show who coded them.	A1 Weak signal opinion	Opinion	holds in part	unverified	Finding-108
The flaws are CVSS 10.0 The CVE records (the authoritative record for the score) give 9.2 under CVSS 4.0 for both flaws, and the PHP Foundation names 10.0 as a wrong score from the leak. The statement is refuted; the site's status 'contradicted' matches.	refuted contradicted	Record	refuted	contradicted	Contradiction-7 Finding-65
The flaws were disclosed on 22 October 2026 The primary records date the disclosure to 21 October UTC: GHSA published 13:34:25Z, tags 13:35:38 UTC, CVE records 13:48:34Z and 13:54:43Z, GitHub release 14:06:46Z, php.net '21 Oct 2026'. '22 October' is only right in Australian or Japanese local time (ACSC: 0100 AEDT on 22 October). The BBC capture never states a disclosure date, so the attribution to the BBC is not carried.	refuted measures differently	Event	refuted	contradicted	Finding-38 Finding-66

The contradiction ledger

Where the reporting disagrees. Each record keeps every statement, who made it and when, what each actually measures, and the desk's reading of why they differ. A contradiction is not resolved by picking a winner; it is explained, or it stays open.

How much of the web: 70% of websites, or 70% of the Internet? explained

Wiz (blog body), 2026-10-21: a popular general-purpose scripting language that powers 70% of all websites in the world share of websites using PHP Wiz
Wiz (blog headline and @wiz_io on X), 2026-10-21: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet the same figure, restated as a share of the Internet Wiz Wiz on X
BBC live page, 2026-10-22 08:05 UTC capture: cyber-security firm Wiz estimating that "roughly 70%" of the internet is affected, though the BBC is unable to independently verify that figure the Wiz figure, quoted with a word ('roughly') that is not in Wiz's post BBC News
CNN, 2026-10-22 11:26 UTC capture: Websites shut down globally after AI finds a critical flaw affecting 70% of the internet headline: share of the Internet; its own body says 'powers 70% of all websites' CNN

The desk's reading. One origin, Wiz, restated: a share of websites using PHP became a share of 'the Internet' affected, inside Wiz's own post. Every outlet in the vault that carries the figure traces to Wiz, so it is one source, not several (restates, not corroborates). None of them says how the 70% was measured; it matches the usual web-technology survey figure for sites whose server-side language is known, which is a share of websites, not of hosts, traffic or 'the Internet', and not a count of vulnerable installations. The BBC's 'roughly 70%' puts a word in Wiz's mouth that its post does not use.

What would settle it. The survey Wiz relied on, captured, with its population and method.

K-001 · ticket Contradiction-1 · claims: scale-70pc-internet, scale-70pc-websites

Is php2shell being exploited? explained

Amazon Threat Intelligence (CJ Moses, AWS Security Blog), 2026-10-21: we saw them used against our sensors almost immediately. PHP2Shell is now being broadly exploited in the wild. exploitation attempts against Amazon's MadPot honeypot sensors, from 17 October and in volume from 21 October 02:00 UTC Amazon
CISA (alert), 2026-10-21: While CISA has not observed exploitation of these vulnerabilities as of the time of publication exploitation observed by CISA, as of the alert's publication CISA
CISA ADP (SSVC in both CVE records), 2026-10-21 14:34 UTC: Exploitation: none CISA's SSVC exploitation decision point at the time it was scored; unchanged in the records fetched 2026-10-22 18:27 UTC CVE record CVE record (outside the vault: https://cveawg.mitre.org/api/cve/CVE-2026-109618)
CISA KEV catalog, fetched 2026-10-22 18:27 UTC (catalog version 2026.10.21, released 2026-10-21 14:04 UTC): Neither CVE-2026-109618 nor CVE-2026-109619 is in the catalog's 1,754 entries. CISA's official list of vulnerabilities with reliable evidence of exploitation (outside the vault: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)
The Next Web, 2026-10-22 (fetched 18:30 UTC, sha256 c51dfb0561b1bdb2): Officials in Germany, the Netherlands and Japan say they have not seen one succeed. successful exploitation, as seen by national officials (outside the vault: https://thenextweb.com/news/php2shell-millions-exploit-attempts-no-confirmed-breaches)

The desk's reading. They measure different things at different times. Amazon counts attempts against its own sensors and honeypots; CISA and KEV record exploitation it has evidence of against real systems. Both can be true at once: attempts in volume, and no confirmed compromise of a named organisation. The site should never write 'exploited' without saying which of the two it means. Amazon's 'broadly exploited' is the stronger word, sourced to Amazon's own post in the vault; a KEV entry would be the first official signal that attempts have become compromises.

What would settle it. A KEV entry for either CVE, or a named organisation confirming a compromise.

K-002 · ticket Contradiction-2 · claims: no-exploitation, cisa-none, amazon-honeypot, probing, watchtowr-itw, no-confirmed-compromise

Which PHP versions are affected? explained

Cloudflare, 2026-10-21: The vulnerabilities affect all web servers running PHP 5.4 or later affected versions Cloudflare
The CVE records (CNA: PHP Group), 2026-10-21: affected: 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, 8.5 before 8.5.12 the supported branches that received a fixed release CVE record CVE record
php.net advisory, 2026-10-21: the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 the branches that got a source backport php.net
NVD (configuration), fetched 2026-10-22 18:27 UTC: cpe:2.3:a:php:php, versionEndExcluding 8.2.35, with no starting version NVD encodes every version before 8.2.35 as vulnerable NVD NVD

The desk's reading. Affected, supported and patched are three different lists. The CVE record lists only the supported branches the PHP project fixed; the backports reach down to 7.4; Cloudflare and NVD describe what is vulnerable, which goes back further. They are compatible, but read as a contradiction unless the site says so where it shows the version table.

What would settle it. The PHP project stating the earliest affected version.

K-003 · ticket Contradiction-3 · claims: versions-old, two-cves-9.2

How many systems are still unpatched? open

Censys, via SecurityWeek, 2026-10-21 (SecurityWeek captured 2026-10-22 11:23 UTC): Out of 2.58 million internet-facing hosts seen on October 21, roughly 1.58 million were reporting identifiable PHP versions, and approximately 1.57 million were not patched unpatched hosts among those whose PHP version is visible, on release day SecurityWeek
VulnCheck, VirusTotal and Censys, via SecurityWeek, 2026-10-21: more than 1 million PHP servers were running unpatched software releases as of October 21 a floor, with no method given SecurityWeek
BBC, attributed only to 'researchers', 2026-10-22, after the vault's last capture: Major providers have implemented a fix, but globally 90% of systems at risk are yet to do so, researchers say. unknown population and method (outside the vault: https://www.bbc.co.uk/news/live/ckgel5xp2xv9t (fetched 2026-10-22 18:30 UTC, sha256 3842343a8de23fc9))

The desk's reading. The site's claim reads as 1.57 million unpatched out of about 2.6 million hosts (about 60%). The source says 1.57 million out of the 1.58 million whose version could be read (about 99%, on the day the fix shipped); the 2.58 million is all hosts seen, most of which do not announce a version. The two framings give very different pictures. The BBC's 90% has no named counter or method and is not captured. Open, because the site states one framing as fact.

What would settle it. Censys's own post (the vault notes say it was not found), or a later Censys count with the same population.

K-004 · ticket Contradiction-4 · claims: scale-2.6m-hosts

How many UK government services went down? open

The BBC live page, reporting a UK minister, 2026-10-22, after the vault's last capture: In the UK, a minister said just after midday that 32 government services were unavailable and four partially unavailable because they were being fixed central government services, at one moment (outside the vault: https://www.bbc.co.uk/news/live/ckgel5xp2xv9t (fetched 2026-10-22 18:30 UTC, sha256 3842343a8de23fc9))
The Register, 2026-10-22: dozens of UK government services unspecified; seen in the coverage review session, not fetched or captured by this desk (outside the vault: The Register follow-up, URL not recorded in the coverage review)

The desk's reading. Probably the same count, described loosely by The Register. The BBC's line is verified in a fetch by this desk; it says 'a minister' without naming one or the House, so the coverage review's 'in the House of Lords' is not yet carried by any source this desk has read. Neither is captured into the vault: this record is a request to capture.

What would settle it. The Hansard record of the minister's answer, captured.

K-005 · ticket Contradiction-5 · claims: uk-list

How many sites were taken offline? explained

This site's impact ledger (data/impact.json), vault capture to 2026-10-22 11:34 UTC: 10 operators offline operators with a captured source in the exported manifest
PHPocalypse Tracker (Luka Kladaric), fetched 2026-10-22 18:27 UTC: 50 sites in sites.csv, 2 of them with no back-up time sites first reported dark by any public source, aggregators included, with dark and back-up times (outside the vault: https://allixsenos.github.io/phpocalypse-tracker/sites.csv)
The evidence vault itself, head 31ccc515c29f: 40 sources not exported to this site, among them captures of Edinburgh council, French prefectures, ANTS, UNIGE, EPFL, Wikimedia status, and reports from Reuters, The Record and Global News captured but not yet on the site

The desk's reading. Breadth of collection, and an export lag. The site requires a captured source per row; the tracker accepts aggregator reports and says so per row. Part of the gap is not collection at all: the vault already holds captures of more offline operators than the site shows, because the site's export stopped at 144 sources.

What would settle it. Re-run the vault export; capture the tracker's sites.csv into the source watch on a schedule.

K-006 · ticket Contradiction-6 · claims: affected-sites

How severe: CVSS 10.0, 9.2 or 9.8? explained

Social posts relayed during the leak, 2026-10-20: a wrong CVSS score of 10.0 (the actual score is 9.2) a leaked number, corrected by the PHP Foundation PHP Foundation
The CVE records (CNA: PHP Group), 2026-10-21: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, base score 9.2 CVSS version 4.0, scored by the vendor CVE record CVE record
NVD (NIST), NVD record modified 2026-10-22 10:09 UTC: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base score 9.8 CVSS version 3.1, scored by NIST, which rates attack complexity low where the vendor rated it high NVD NVD

The desk's reading. 10.0 was wrong. 9.2 and 9.8 are both right, on two different scales scored by two different parties, and they disagree on one input: the vendor says attack complexity is high, NIST says low. The site explains 10.0 against 9.2 but never mentions 9.8, which is what a reader checking NVD, or a scanner reporting CVSS 3.1, will see.

What would settle it. Already settled as a reading; the site should carry the 9.8 and say what differs.

K-007 · ticket Contradiction-7 · claims: cvss-10, two-cves-9.2

Which flaw was shown to give code execution on PHP-FPM? open

The PHP Foundation (blog), 2026-10-21: Remote code execution was also confirmed on PHP-FPM through application-level code paths placed under CVE-2026-109618 in the post PHP Foundation
PHP security team (GHSA-w8hw-w9fx-j79w, CVE-2026-109618), 2026-10-21: no complete FPM exploit has been demonstrated for this SAPI CVE-2026-109618 on FPM PHP
PHP security team (GHSA-6wmf-4rv5-p3rp, CVE-2026-109619), 2026-10-21: It works with a normal dynamic FPM pool, although it depends on a suitable application operation. CVE-2026-109619 on FPM PHP

The desk's reading. The advisories, written by the PHP security team per CVE, put the demonstrated FPM exploit under CVE-2026-109619, and say none was demonstrated for CVE-2026-109618. The Foundation's blog places FPM confirmation under CVE-2026-109618. The blog appears to have swapped the attribution. That RCE was shown on FPM is not in doubt; which flaw does it is.

What would settle it. A correction to the Foundation's post, or a PHP security team statement.

K-008 · ticket Contradiction-8 · claims: rce-fpm, rce-modphp

Did any technical detail leak on 20 October? open

The PHP Foundation, 2026-10-21: They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked. what circulated with the CVE IDs PHP Foundation
Daubois (a member of the PHP security team, own blog), 2026-10: A screenshot of the PHP2Shell tool, credited to Calif.IO, leaked alongside the advisory, and a short exploitation video went up and came down a tool screenshot and a video Daubois
The Hacker News, 2026-10-21: details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time claims a PoC leaked THN
Equixly, citing Sansec, 2026-10: Sansec cites a leaked screenshot of an exploit tool named PHP2Shell, whose banner claims the tool works against PHP 5.4.0 and later. a screenshot of a tool banner Equixly

The desk's reading. Probably different meanings of 'technical detail'. A screenshot of a tool banner and a demonstration video show that an exploit exists, not how it works; the Foundation may mean that no root cause or code leaked. The Hacker News's 'proof-of-concept exploit leaked' is stronger than anything else in the vault carries, and no capture shows a leaked PoC. Open until the Foundation or Daubois says what the Foundation meant.

What would settle it. A capture of the leaked screenshot or video, or the Foundation saying what 'technical details' covers.

K-009 · ticket Contradiction-9 · claims: leak-cve-ids, leak-hn, leak-video

When was the release planned, and when did it ship? open

The PHP Foundation, 2026-10-21: It also moved the release from October 22nd, 14:00 UTC, to October 21st, 14:00 UTC. the planned times PHP Foundation
The Hacker News, 2026-10-21: Originally scheduled for coordinated disclosure on October 22, 2026, at 2:00 p.m. UTC the original plan, probably from the Foundation THN
CybelAngel, 2026-10: The disclosure was originally under embargo until Thursday 22 October at 11:00 ET; after the leak, PHP scheduled its release for 21 October the original embargo, 15:00 UTC, attributed by others to watchTowr CybelAngel
The php.net ChangeLog, captured 2026-10-22: 22 Oct 2026 the date the ChangeLog gives all four releases, which shipped on 21 October php.net

The desk's reading. The original embargo time has two values, 14:00 UTC (the Foundation, echoed by The Hacker News) and 11:00 ET, which is 15:00 UTC (watchTowr, echoed by CybelAngel and others). The release itself is stamped 13:34 UTC on the GitHub advisories, ahead of the announced 14:00. The ChangeLog still carries the original date. The site should say 'about 14:00 UTC, advisories at 13:34' and give both original times.

What would settle it. A PHP project statement of the embargo time, or the pre-announcement's original text.

K-010 · ticket Contradiction-10 · claims: release-moved, release-time

Is the fix in PHP 8.5.12 incomplete? open

Aaron Rainbolt on oss-security, relaying a Fediverse post, 2026-10-21 15:24 UTC: the Fediverse is reporting that the fix to at least PHP 8.5.12 may be incomplete an unconfirmed report from an unnamed person, relayed oss-security
The same, relaying Canonical via a Matrix channel, 2026-10-21 17:29 UTC: was told that it's "unrelated and not a real issue" PHP's answer to Canonical, second-hand oss-security
Jakub Zelenka, PHP security team, on oss-security (post 2026/10/22/15), 2026-10-22 09:11 UTC: This is unrelated issue with minimal impact (crash in one component in slightly unlikely scenario). It has nothing to do with the RCE. PHP's own public answer (outside the vault: https://www.openwall.com/lists/oss-security/2026/10/22/15 (fetched 2026-10-22 20:5x UTC, sha256 94c69d8f1c07e67d))

The desk's reading. The report and the answer are about different things: the Fediverse post describes some flaw in 8.5.12; the PHP security team says it is a separate crash bug of minimal impact, not a way around the RCE fix. The answer came at 09:11 UTC on 22 October, after the vault's copy of the thread (which stops at 22/2), so the site still says PHP has not answered. Open only until the reply is captured; then it should be marked explained and the claim re-graded.

What would settle it. Capture oss-security 2026/10/22/15 into the vault.

K-011 · ticket Contradiction-11 · claims: fix-incomplete, more-paths

Findings: things on this site to change (125)

Ticket	What	Severity	Status	About
Finding-1	ai-found: Patch the Planet framing generalised to all finders The claim says the flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiative. Calif's page places Calif under Patch the Planet; Wiz's blog and X thread never mention Patch the Planet, and Wiz credits Gemini 4 Argon most. The OOM root cause was first seen by a PHP core developer in 2024 without AI (Foundation blog). Reword to 'Calif, working under Patch the Planet, and Wiz both used AI models'.	medium	open	ai-found
Finding-2	who-first: Priority reading carried as 'confirmed' 'Calif found the flaws first' is an attribution of priority, a reading. The Foundation's capture says the same root cause was 'the OOM problem we had found in 2024' and that 'OpenAI independently reported the same root cause on the same day'. The 1 August discovery date is Calif's own claim. Use status 'reported', or narrow it to 'Calif has the earliest public timestamp (hash on 5 August) of the 2026 reporters'.	medium	open	who-first
Finding-3	openai-same-day: Note quotes OpenAI's blocked post The note says OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol'. OpenAI's blog capture is blocked (text.txt is 0 bytes) and the captured X post contains no such phrase. The wording exists only as a search snippet in the collector's notes. Drop the quote marks or say it is from a search summary.	medium	open	openai-same-day
Finding-4	wiz-independent: 'independently' not carried by any primary capture Wiz's blog says 'Prior to public disclosure, Wiz Research worked with the PHP team, Calif and OpenAI on discovery, coordination and patch verification'. The Foundation lists Wiz's 24 August report as 'further attack vectors'. Only OpenAI's blocked blog (search snippet) and Wikipedia say 'independently'. Attribute the word, or drop it.	medium	open	wiz-independent
Finding-5	quarkslab-2024: Who found the OOM issue in 2024: the two sources differ The claim says the issue 'was found in a 2024 audit by Quarkslab'. The Foundation, the primary party, says a PHP core developer found the first signs 'while fixing one of the issues Quarkslab reported'. timeline.json (at 2024) states the Foundation's version correctly; this claim does not. Quarkslab's published summary lists no OOM finding.	medium	open	quarkslab-2024
Finding-6	quarkslab-2024: 'Two parties agree' is one origin, and 'confirmed' is overstated Calif writes 'We were able to confirm from PHP a similar/related issue was uncovered but exploitation was not proven in 2024', so its account derives from PHP. The causal 'so it was not fixed' is Calif's; the Foundation says the fix stalled because of competing approaches, consensus decision-making and a lack of resources. Status should be 'reported', with the Foundation's version as the lead.	medium	open	quarkslab-2024
Finding-7	ahead-of-attackers: Claim drops OpenAI's hedge 'to our knowledge' OpenAI wrote 'to our knowledge, frontier AI was able to find this vulnerability ahead of attackers'. The site states it unhedged. Restore the qualifier.	medium	open	ahead-of-attackers
Finding-8	most-severe: Cited Wiz source does not say it; the real origin is uncited The claim cites wiz-blog-php2shell, whose wording is 'among the most severe ... in PHP'. The 'ever detected by AI' framing appears in the BBC and, as a WSJ quote of Wiz's co-founder ('the most severe AI vulnerability that was ever found'), in substack-lopezkurtz-patch-is-the-exploit. Cite the Substack relay and label the claim as a quote of a quote from the WSJ.	medium	open	most-severe
Finding-9	leak-video: 'around 20:00 UTC' may be the pre-announcement's time, not the video's The Foundation sentence reads 'As a result of the leak and pre-announcement around 20:00 UTC, Calif ... mistakenly published a video.' The time can modify the pre-announcement (oss-security relayed it at 20:22:51Z; php.net's feed says 20:32Z). The Register reads it as 'a couple of hours later' than 15:00; Feross says 'that evening'. The site (claim and timeline.json at 2026-10-20T20:00Z) presents 20:00 UTC as the video's time. Say 'evening of 20 October' or flag the ambiguity.	medium	open	leak-video
Finding-10	chainguard: Lorenc quote attributed to The Register is not in The Register The note quotes Lorenc 'via The Register': 'I made the call to get these out early when exploits hit in the wild'. The Register capture has 'so we made the call to ship the fixes under that'. The quoted sentence appears only inside a Reddit comment embedded in the Foundation page ('but I made the call to get these out early when exploits hit in the wild.'), apparently quoting Lorenc elsewhere (likely Hacker News). Use The Register's words or capture the original.	medium	open	chainguard
Finding-11	no-exploitation: Time of the Austin interview is wrong: the post is 08:00 UTC (09:00 BST), not 08:00 BST claims.json 'by' says '08:00 BST 22 October'; exploitation.json and timeline.json date it 2026-10-22T07:00Z. The capture's page.html JSON-LD gives the post datePublished 2026-10-22T08:00:23.293Z, and the rendered page (UTC browser) shows 'published at 08:00'. The vault's BBC notes.md is the origin of the BST error (the 07:55Z curl copy showed BST clock times, the Playwright capture shows UTC).	medium	open	no-exploitation
Finding-12	no-exploitation: Claim uses the BBC headline's absolute wording, not Austin's hedged words Austin said "Not at the moment... it doesn't look like exploitation has taken off or been widespread", which allows some exploitation; 'There is no evidence yet that hackers have exploited the flaw' is the BBC's paraphrase. Reword to his words or attribute the headline to the BBC.	medium	open	no-exploitation
Finding-13	cisa-none: Claim drops CISA's own time qualifier CISA says it 'has not observed exploitation ... as of the time of publication' (Release Date October 21, 2026, no time given). The claim text uses an undated present tense ('CISA has not observed exploitation'); the qualifier is only in the note. Put 'as of 21 October' in the claim itself, since Amazon, Cloudflare, watchTowr and NCSC NZ report exploitation attempts after that.	medium	open	cisa-none
Finding-14	amazon-honeypot: The note narrows Amazon's sentence to honeypots; Amazon's text does not Note: 'Attempts against honeypots, not compromises of victims'; history.json: "Amazon saying it is 'broadly exploited' against honeypots"; claims.json no-confirmed-compromise: "'broadly exploited' against sensors". Amazon writes 'we saw them used against our sensors almost immediately. PHP2Shell is now being broadly exploited in the wild.' and also 'With PHP2Shell, compromise may predate the advisory.' The honeypot limit is this site's reading. Say instead: Amazon gives no counts and names no victim; its evidence shown is honeypot telemetry.	medium	open	amazon-honeypot
Finding-15	probing: exploitation.json's Woodward row says Amazon's own post was not found exploitation.json row (2026-10-22, Alan Woodward) has status 'reported; Cloudflare's own post confirms attack traffic, Amazon's own post not found' and cites thehackernews-php2shell-4days, while this claim (confirmed) cites aws-security-blog-madpot as Amazon's own confirmation.	medium	open	probing
Finding-16	latvia-attempts: 'none succeeded' overstates 'no reports of successful attacks so far' CERT.LV: 'ta_u l_dz _im nav zi_u par sekm_giem uzbrukumiem' (but so far there are no reports of successful attacks), in the update of 21.10.2026 23:00 (20:00Z). exploitation.json words it correctly; claims.json does not. Reword and date it.	medium	open	latvia-attempts
Finding-17	huntress-none: 'No public exploit code known' is dated before release, not 20:30 UTC on 21 October The sentence 'we're not aware of public exploit code as of this writing' sits in the original pre-release section ('The fixes aren't out yet'), i.e. about 20 October. The claim and impact.json put it under 'as of 20:30 UTC on 21 October'. By then Amazon reports PoCs 'within hours' of release, CCCS says a PoC is available, and watchTowr reports PoC code on GitHub. Split the two halves and date each.	medium	open	huntress-none
Finding-18	watchtowr-itw: Status 'unverified' understates the attempts half; the vault has four outlets quoting watchTowr securityweek-first-attempts-sensors, securityweek-exploitation-days-before, darkreading-php2shell-red-alert and tenable-php2shell-faq (in data/sources.json) and therecord-php-warnings (vault only) quote Jake Knott: watchTowr sees in-the-wild exploitation attempts. Cite them and mark that half reported or corroborated.	medium	open	watchtowr-itw
Finding-19	watchtowr-itw: Claim omits watchTowr's own qualifier: no successful attempt, and sprayed exploits mostly do not work Knott: 'Whilst nobody has been successful to date' (SecurityWeek) and 'The exploits being sprayed indiscriminately either don't work at all, test for timing-based differences, or crash the target'. Without this the claim reads as more than attempts.	medium	open	watchtowr-itw
Finding-20	kev-precedent: Status 'confirmed' outruns the weakest part (A2), and 'last PHP core RCE' is not shown The one-day exploitation rests on one party (Akamai). The CVE record calls CVE-2024-4577 'Argument Injection in PHP-CGI' on Windows with certain code pages, a SAPI bug rather than the PHP core; and nothing captured shows it is the most recent PHP RCE (only that it is the most recent PHP entry in KEV). Say 'the last PHP flaw in KEV'.	medium	open	kev-precedent
Finding-21	kev-precedent: Honeypot attempts count as 'exploited in the wild' for 2024 but not for php2shell Akamai's one-day evidence is exploit attempts against its honeypot network, the same kind of evidence as Amazon's MadPot hits, which the site's notes (amazon-honeypot, history.json) say are 'attempts against honeypots, not compromises'. Apply one standard to both.	medium	open	kev-precedent
Finding-22	affected-sites: Cited text capture no longer carries most of the list The 08:05:59Z text capture (sha c88b8c5f...) has no mention of Edinburgh council, the BBC, online stores or the University of Geneva. The list is only in raw/page.2026-10-22T0755Z.html (summary bullet "Among the impacted sites are Wikipedia, Edinburgh council, many online stores and the BBC") and the Geneva item only in the header image alt text in raw/initial-data.json. The BBC dropped the bullet between 07:55Z and 08:05Z. The assessment should cite the raw file and its sha, and say the bullet was later removed.	medium	open	affected-sites
Finding-23	affected-sites: Note "Not captured from any of the named organisations" is out of date The vault holds operator captures: unige.ch returned HTTP 503 with an F5 "under maintenance" page at 2026-10-22 08:19:10Z (unige-site) and 08:19:43Z (ch-unige-down); nord.gouv.fr and rhone.gouv.fr served "Maintenance en cours" at 08:19:39-40Z; edinburgh.gov.uk was up (HTTP 200, normal homepage) at 08:19:03Z and 08:19:40Z; wikimediastatus.net showed "All Systems Operational" at 08:18:50Z. These show down/up state at capture time, not the reason. story.json repeats the out-of-date statement ("has not been captured from any of those organisations").	medium	open	affected-sites
Finding-24	latvia-offline: Note "the one documented case ... from the agency itself" is contradicted by other site data and captures The claim note and story.json call Latvia the one documented case of government services pulled from the public internet by the agency itself. The site's own nl-offline claim (status confirmed, "Primary statement") rests on Rijksoverheid saying NCSC.NL was taken offline "uit voorzorg"; EPFL's own homepage (epfl-site, 08:19:13Z) says it "has temporarily suspended access to some of its websites"; nord.gouv.fr and rhone.gouv.fr served maintenance pages at 08:19Z on 22 Oct.	medium	open	latvia-offline
Finding-25	latvia-offline: "Pulled from the public internet" overstates a geo-block CERT.LV says access was restricted from abroad, selectively, and that residents accessing from Latvia should not be affected ("Paredzams, ka iedz_vot_jus, kuri valsts digit_lajiem pakalpojumiem piek__st no Latvijas, _ie ierobe_ojumi neietekm_s"). The note should say geo-blocked from abroad, not pulled from the public internet.	medium	open	latvia-offline
Finding-26	no-confirmed-compromise: Claim text lacks its as-of and scope The negative holds only "in every captured source, as of the latest capture" (newest checked 2026-10-22T11:33Z). The note says so, but the claim and status "confirmed" read as a settled fact about the world. The supporting negatives are old: Huntress as of 20:30Z on 21 Oct, Imperva pre-disclosure only, CERT.LV 20:00Z on 21 Oct, against Amazon's "broadly exploited in the wild" and Cloudflare's "millions" of attempts. Suggest status "reported" or wording "No named organisation, in any captured source as of <stamp>, ...".	medium	open	no-confirmed-compromise
Finding-27	nl-offline: "Primary statement" covers only NCSC.NL The Rijksoverheid capture names only NCSC.NL; DigiD, MijnOverheid and Overheid.nl are not in it, and dutchitleaders-websites-offline is a Cloudflare challenge (75 chars). Status "confirmed" with note "Primary statement" overstates three of the four services. Cite tpo-nl-digid-offline and insurancebusiness-uk-councils-met (DigiD, MijnOverheid) and reuters-factbox-websites-offline (Overheid.nl), and mark those parts reported.	medium	open	nl-offline
Finding-28	nl-offline: "No signs of active exploitation of those services" is narrower than any source Rijksoverheid says NCSC has not yet seen active misuse in general (13:59 on 21 Oct, before the patch); TPO quotes the minister saying there were "nog geen signalen" of active misuse. Neither speaks about those services specifically. Same wording in impact.json.	medium	open	nl-offline
Finding-29	wikimedia-precaution: CNN does not carry the quoted phrase The claim's "by" credits CNN, but CNN has only "precautionary measure" (told CNN on Thursday). The full phrase is in The Cyber Express, Newsweek (newsweek-php2shell-websites) and the Reuters factbox (reuters-factbox-websites-offline); cite those.	medium	open	wikimedia-precaution
Finding-30	oxford: Quote is not in the cited source oxfordchronicle-councils-offline (sha 35c84729...) does not contain the quoted words; only the collector's notes.md does. The words are in eadt-minister-budget-no-breach (sha 4c8556b5...), an embedded post signed "Oxford City Council (@OxfordCity) October 21, 2026". Cite that and change "via Oxford Chronicle"; impact.json also says Oxford Chronicle is "quoting" the councils' posts, which it is not.	medium	open	oxford
Finding-31	uk-list: OBR is not in either cited source Neither lbc-uk-websites-offline nor insurancebusiness-uk-councils-met mentions the Office for Budget Responsibility. It appears only in eadt-minister-budget-no-breach (PA), framing a question to the Scotland Secretary. Add that source or drop the OBR from this claim.	medium	open	uk-list
Finding-32	scale-70pc-websites: Cloudflare does cite its survey: the 70_ links to W3Techs The claim note says 'None of the three cites the survey it comes from', numbers.json n-70-websites says 'Neither page names the survey', and a sections.json page says 'None of the pages that use it says how' it was measured. Cloudflare's rendered.html (capture 20261022T081216Z) hyperlinks '70% of websites' to https://w3techs.com/technologies/details/pl-php. The text.txt drops the link, which is likely why it was missed. OpenAI and Wiz do not cite a source.	medium	open	scale-70pc-websites
Finding-33	scale-70pc-websites: The claim drops the survey's population qualifier W3Techs' figure, as relayed by Tenable (69.3%) and Imperva (over 69%), is a share of websites whose server-side language is known, not of all websites. 'used by almost 70% of websites' overstates the population. numbers.json n-70-websites 'measures' describes the population correctly; the claim text should match.	medium	open	scale-70pc-websites
Finding-34	scale-2.6m-hosts: 'of which' joins two different counters The 2.6 million is VulnCheck's count; the 1.57 million unpatched is Censys's, out of the 2.58 million hosts Censys saw on 21 October (SecurityWeek). The same 'of which' framing recurs in questions.json and readings.json. Suggested wording: 'VulnCheck counts about 2.6 million; Censys saw 2.58 million on 21 October, of which 1.57 million were unpatched.'	medium	open	scale-2.6m-hosts
Finding-35	scale-ncsc-nl: Confirmed: the inventory had 675 rows at cca173c64ec5, not 674; 4 not vulnerable, not 3 Counting table rows in raw/tree-cca173c64ec5/software/software_list_*.md gives 675 (Fix 46, Investigation 418, Vulnerable 206, Not vuln 4, blank 1). A fresh clone of raw/php2shell-cca173c64ec5.bundle (HEAD cca173c64ec5db92, 2026-10-22T10:40:58+02:00) gives the same 675 and its tree is identical to the vault's tree; the SPDX file software/spdx/PHP_Downstream_Inventory.spdx3.json has 675 software_Package elements and 4 NotAffected VEX relationships. The missing row is iBabs / iBabs bestuursportaal (Not vuln), in software_list_i.md, whose Links cell is empty, which is probably why the export parser skipped it. data/software.json (count 674, Not vuln 3) and raw/software-list-cca173c64ec5.json carry the error. This confirms BRIEF-CORRECTIONS.md v0.4.2.	medium	open	scale-ncsc-nl
Finding-36	scale-ncsc-nl: Site data disagree on the inventory count data/claims.json (scale-ncsc-nl), data/numbers.json n-674 ('674 ... 3 Not vulnerable, 1 without a status'), data/software.json (count 674), questions.json, sections.json and index.md ('reaches 674 products') say 674; data/inventory-history.json self_check says the parser 'also finds 1 row the vault missed: iBabs'. numbers.json n-674 agrees with the claim but both are wrong against the file.	medium	open	scale-ncsc-nl
Finding-37	scale-ncsc-nl: The claim's status counts do not add up to its total 206 + 46 + 418 + 3 = 673, not 674. The 674th row is 'The PHP Group / PHP core and Zend Engine', an unversioned anchor with no status. numbers.json n-674 mentions it; the claim does not. Corrected: 675 rows: 206 vulnerable, 46 fixed, 418 under investigation, 4 not vulnerable, 1 PHP-core anchor without a status.	medium	open	scale-ncsc-nl
Finding-38	disclosure-22oct: The BBC capture does not say the flaws were disclosed on 22 October The claim's 'by' is 'BBC framing (UK morning coverage)', but the captured BBC live page (080559Z, and the 07:55Z raw copy) gives no disclosure date; it says details 'leaked online this week' and the patch 'has been rushed out'. Labelling a BBC statement 'contradicted' when the BBC did not make it misattributes. The '22 October' dates in the vault come from the original schedule (Foundation: 'from October 22nd, 14:00 UTC'), Wiz's thread ('Apply the Oct 22 security release') and ACSC's local time ('22 October 2026 at 0100 AEDT').	medium	open	disclosure-22oct
Finding-39	release-time: Three of the cited sources state a schedule, not a release time php.net's pre-announcement and the oss-security relay say 'It is scheduled for ... 14:00 UTC'; CERT-FR says the publisher 'annonce la disponibilit_ des correctifs ... pour le 21 octobre 2026 _ 16h00 heure de Paris (14h00 UTC)'; the Foundation says it 'moved the release ... to October 21st, 14:00 UTC'. None of these observes the release. The 'by' line should read 'scheduled for 14:00 UTC' with Daubois as the one after-the-event statement.	medium	open	release-time
Finding-40	preannounce-time: The Foundation's post gives two times for the pre-announcement php-foundation-blog-security-release says 'published it at 19:30 UTC' and two paragraphs later 'the leak and pre-announcement around 20:00 UTC'. The note cites only the feed (20:32Z) and oss-security (20:22:51Z) against it; the source's own inconsistency should be shown.	medium	open	preannounce-time
Finding-41	fix-authored: Committer time is not the time a commit became public 3584a98bd's committer date is 2026-10-21T16:06:22+02:00 (14:06:22Z). Git records when the commit object was made, not when it was pushed; and the release tags (13:35:38 UTC, pointing at release commit 136e049 dated 2026-10-19) already shipped the fix before 14:06. Suggested wording: 'committed to the branch at 14:06 UTC'.	medium	open	fix-authored
Finding-42	offline-ncsc: LBC carried the same NCSC sentence on 21 October, before the NCSC page was modified lbc-uk-websites-offline (dated '21 Oct 2026, 15:41', written before the release: 'Full details ... have yet to be published') quotes the NCSC verbatim with the BBC's wording. The NCSC page captured at 08:09Z on 22 Oct has HTTP last-modified 07:30:02 GMT that morning. Two outlets, one of them hours earlier than the BBC, quoting the same sentence suggests an earlier NCSC version said it and was reworded. The note frames it as a BBC misquote whose opening 'matches the Canadian CCCS text'; it should mention LBC and the likely supersession. The quote is not in the NCSC capture, so A3 stands until an earlier NCSC version is captured.	medium	open	offline-ncsc
Finding-43	offline-allies: Italy's ACN does advise taking sites offline; the site says it does not acn-it-php2shell text.txt (sha 19fac2ed..., line 70): 'Qualora non fosse possibile applicare tempestivamente gli aggiornamenti di sicurezza, si raccomanda di valutare di porre offline i siti e i servizi web che utilizzano versioni vulnerabili di PHP, sospendendone l'accessibilit_ fino all'avvenuto aggiornamento.' The claim note ('Italy ... give[s] no offline advice'), data/agencies.json (IT: offline 'none', 'Update only') and the collector notes ('NO offline or isolation advice') are all wrong against the same capture. agencies.json's offline_text 'Si raccomanda di aggiornare i prodotti vulnerabili.' is also truncated: the sentence continues 'seguendo le indicazioni dei bollettini di sicurezza riportati nella sezione Riferimenti.'	high	open	offline-allies
Finding-44	offline-allies: The BBC capture does not make the claim the site marks 'contradicted' BBC (06:30 post): 'The UK's National Cyber Security Centre (NCSC), as well as its counterparts in the EU and Australia, earlier urged those who use PHP to apply the fixes.' The offline sentence is then attributed to the NCSC only; the NSA appears in a separate post. The site's claim merges these into the BBC saying all four advise offline, and then marks that 'contradicted'. A reader is told the BBC was wrong about something it did not say.	high	open	offline-allies
Finding-45	offline-allies: Australia is not-shown, not contradicted, and the EU part largely holds ACSC's page lists other actions and no offline advice, but its body text is stale (pre-patch) and absence on one page is not a contradiction. For 'the EU', CERT-EU advises isolating internet-facing applications from public networks, CERT-FR recommends isolating affected equipment, ACN advises taking sites offline, and CERT.LV says systems that cannot be updated must have internet access restricted. Only NCSC-NL, ENISA's CNW page and JPCERT give no such advice.	medium	open	offline-allies
Finding-46	waf-nine-hours: 'Hours before disclosure' is shown only for Cloudflare, and Fortinet's date is after disclosure The lead clause applies to all five vendors, but only Cloudflare states a time before the release. Imperva says protection was verified and monitoring began 'before the announcement' with no time; Akamai and Fastly posts are dated 21 October with no time; Fortinet's FortiWeb article was created 10/22/2026 07:55 AM (timezone not stated) and its signatures are 'in Alert Only mode' by default. Suggested: 'Cloudflare from 03:02 UTC on 21 October; Imperva before the announcement; Akamai and Fastly on 21 October; Fortinet signatures by 22 October.'	medium	open	waf-nine-hours
Finding-47	waf-nine-hours: The note's 'every vendor says ... patch anyway' is not carried for Fortinet Cloudflare ('Customers should patch their PHP repos even with WAF protections'), Akamai ('The most effective defense continues to be the prompt application of vendor patches'), Fastly ('assume active mitigation will only serve as partial protection') and Imperva carry it. The Fortinet KB article gives signature and custom-rule steps and does not call them a stopgap or tell readers to patch.	medium	open	waf-nine-hours
Finding-48	rce-fpm: Status 'disputed' understates a claim the PHP advisory record carries; the dispute is about which CVE, not whether GHSA-6wmf and openwall 2026/10/21/7 (PHP security team, CVE-2026-109619) both say unauthenticated RCE was demonstrated against PHP-FPM. Only the attribution to CVE-2026-109618 is in doubt. Suggest rewording to 'RCE is confirmed on PHP-FPM for CVE-2026-109619 (session upload progress path, needs a suitable application operation); for CVE-2026-109618 the advisory says no complete FPM exploit' and setting the status accordingly. Also cite openwall-oss-security-2026-10-21-7, which is in the manifest but not on this claim; the cited openwall 21/6 is the 109618 post and does not carry the claim.	medium	open	rce-fpm
Finding-49	rce-fpm: Glossary short text for PHP-FPM says 'whether a full exploit exists is disputed' data/glossary.json (id fpm) short: 'Susceptible; whether a full exploit exists is disputed.' The PHP advisory GHSA-6wmf and oss-security 21/7 say FPM RCE was validated/demonstrated for CVE-2026-109619. The long text is accurate ('for the first flaw'); the short text misleads.	medium	open	rce-fpm
Finding-50	versions-old: 'from 5 onwards' is wider than the finder's '_= 5.4', and the 5.x sources look like echoes of the leak Wiz (X post and blog) says 5.4 and later. NCSC-NL's text is the pre-patch banner ('vermoedelijk ... in ieder geval vanaf versie 5'), CERT-FR lists 'toutes versions 6.x' (PHP 6 never shipped; Daubois says watchTowr named 5, 6, 7 and 8), and The Hacker News says the HN leak claimed 'from PHP 5 onward'. These trace to one origin (A3 at most). Suggest the claim say '5.4 onwards per Wiz; PHP's backports imply 7.4 onwards'.	medium	open	versions-old
Finding-51	waf: Status 'disputed' understates: the sources agree a WAF is partial protection CISA: 'may provide some protection'; BACS: 'alone is not sufficient'; Cloudflare: 'Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation.' These are the same position at different emphasis. Suggest 'confirmed' as CISA's advice, with the BACS and Cloudflare caveats in the note.	medium	open	waf
Finding-52	pocs-wrong: Huntress is cited but does not carry the claim The Huntress capture says it had 'not built or reproduced a proof of concept' and was 'not aware of public exploit code as of this writing'; it says nothing about VulnCheck or a 200 response. The 'by' field names Huntress too. Remove it or cite what it actually says.	medium	open	pocs-wrong
Finding-53	ac-high: Status 'confirmed' on a claim whose first half is a reading 'Triggering the bug is much easier than turning it into code execution' is Imperva's characterisation (verbatim, unquoted on the site). A reading caps at A3. Split the claim: the AC:H record is confirmed; the ease comparison should be shown as Imperva's reading (with Fastly agreeing).	medium	open	ac-high
Finding-54	more-paths: Missing context: the fix removed the OOM bailout itself, not only the demonstrated paths The fix commit replaces bailout on OOM with UnwindExit and GHSA-w8hw says 'The patch removes longjmp() for OOM'. Fastly's point still applies to bailout on other fatal conditions (timeouts, uncaught errors), which GHSA-6wmf calls 'conditional', but a reader could take the claim to mean PHP only patched the demonstrated paths. Say which bailouts remain.	medium	open	more-paths
Finding-55	more-paths: Note leans on an unconfirmed report PHP reportedly rejected 'consistent with the Fediverse report of a third bug' cites the oss-security thread, which is an unnamed second-hand report, and the same thread says Canonical was told by PHP it is 'unrelated and not a real issue'. The thread does not carry Fastly's position and should not be cited as support.	medium	open	more-paths
Finding-56	ac-high: 2 smaller precision and sourcing points Fastly quote drops the quotation marks around 'safe': Capture: 'most deployments may be _safe_ from RCE.' The site drops the scare quotes, which changes the tone: Fastly is hedging the word. \| Imperva phrase used without attribution in the claim text: The claim's first clause is Imperva's sentence word for word; it should be quoted and attributed.	low	open	ac-high
Finding-57	affected-sites: 1 smaller precision and sourcing point "Online shops" rests on the BBC alone and is vague: No capture names an online shop taken offline; the BBC capture otherwise mentions online shops only as platforms PHP powers. The University of Geneva item comes from an EPA photo alt text, not reporting text.	low	open	affected-sites
Finding-58	ahead-of-attackers: 1 smaller precision and sourcing point Amazon's 17 October attempt is second-hand: The 17 October MadPot attempt is known only from CJ Moses 'in a post shared with The Hacker News'; no Amazon post is captured.	low	open	ahead-of-attackers
Finding-59	ai-found: 2 smaller precision and sourcing points 'frontier' is not Calif's word: Calif writes 'No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery' and refers to an 'LLM companion'. 'Frontier AI' is Wiz's and OpenAI's language, not Calif's. \| Calif's model is named only second-hand: That Calif used GPT-5.6 Sol rests on OpenAI's blocked blog (openai-blog-coordinated-disclosure text.txt is 0 bytes) and press relays (cybernews, wikipedia). Calif's own page names no model.	low	open	ai-found
Finding-60	amazon-honeypot: 2 smaller precision and sourcing points 'from multiple actors' is stated as fact; Amazon says 'suggesting': Amazon: 'The actual payloads and choices in anonymization infrastructure varied, suggesting these were multiple actors.' Use 'probably from multiple actors'. \| Only one capture of Amazon's post, 21 hours after its date: The post is dated 21 Oct with no time; the single capture is 11:17Z on 22 Oct. The Hacker News (captured 08:13Z) already reports 'broad exploitation in the wild', so the sentence existed by then, but whether it was in the first version cannot be shown.	low	open	amazon-honeypot
Finding-61	cf-millions: 1 smaller precision and sourcing point Name the missing method, and set against Imperva's pre-disclosure zero: Thousands of attempts in the 10 hours before announcement (Cloudflare) and no matching traffic in pre-disclosure monitoring (Imperva, claim imperva-none) are different populations and probably different signatures; the site should say so where both appear.	low	open	cf-millions
Finding-62	chainguard: 1 smaller precision and sourcing point Notification timing differs between relays: The Register: Lorenc 'notified the PHP coordinated disclosure channel about his plans' (before). Feross: 'he notified the group right after making the call'. Feross's post ID 2113043398664015878 decodes to 2026-10-21T23:02:59Z, so the source's published '2026-10-22' is off by a day in UTC.	low	open	chainguard
Finding-63	cisa-none: 1 smaller precision and sourcing point KEV fetch time is 08:16Z, and the catalog version is from 14:04Z on 21 Oct: The note says fetched 2026-10-22T08:15Z; the saved response headers say date Thu, 22 Oct 2026 08:16:01 GMT. The catalog itself (last-modified 21 Oct 14:04:39 GMT) predates the alert's likely release and is only 16 minutes after CVE publication (13:48Z), so 'not in KEV' is a check at 08:16Z on 22 Oct of a catalog last changed 14:04Z on 21 Oct. Re-check KEV on each run.	low	open	cisa-none
Finding-64	cloudflare-traffic: 1 smaller precision and sourcing point Timing 'after the leak' and exploitation.json's '2026-10-20 to 21' are inferred: Cloudflare does not date the traffic; its sentence ties it to the leak only by 'while'. Volumes do exist from the same party (claim cf-millions, Prince on X), so 'no volumes' is true only of this post; cross-link.	low	open	cloudflare-traffic
Finding-65	cvss-10: 1 smaller precision and sourcing point CVE records are the refuting primary but are not cited on this claim: The refutation rests on the PHP Foundation blog and Daubois; the CVE records cve-cve-2026-109618 and cve-cve-2026-109619 (CVSS 4.0 9.2) are the authoritative refutation and could be cited. The vault's own claim file (claude-story-site.json) records this claim as 'disputed' while the site says 'contradicted'; the site's word is the better fit.	low	open	cvss-10
Finding-66	disclosure-22oct: 1 smaller precision and sourcing point CVE records named in the note are not cited: The note gives CVE record times 13:48Z and 13:54Z; they are carried by cve-cve-2026-109618 and cve-cve-2026-109619 raw/cveawg-api.json (datePublished), which the claim does not cite.	low	open	disclosure-22oct
Finding-67	edinburgh: 2 smaller precision and sourcing points "Late on 21 October" is looser than the source: The Scotsman says the site went down "late on Wednesday afternoon"; the Edinburgh Evening News version was published 17:24 BST with the site already down, so the outage began before about 16:24Z. "Late on 21 October" suggests the evening. \| Site was back by 08:19Z on 22 Oct: The council's own homepage returned HTTP 200 with normal content at 08:19:03Z (edinburgh-council-site) and 08:19:40Z (uk-edinburgh-council). impact.json says "Website offline" with no end; the down period itself has no operator capture.	low	open	edinburgh
Finding-68	fi-offline: 2 smaller precision and sourcing points Two start times in the same sources: Helsinki Times gives 12:45 for restricting traffic but also says Naumanen told STT "the shutdown process had begun shortly after 1 pm"; Yle says the same. The timeline row (09:45Z, confidence "inferred") should note that 12:45 is the restriction start per Helsinki Times only. \| Yle and Helsinki Times are not fully independent: Yle's piece is bylined "Yle News / STT" and Helsinki Times also relies on STT for Naumanen; only Helsinki Times carries 12:45. The Valtori site capture (fi-valtori) failed ("Target page, context or browser has been closed"), so there is no operator capture.	low	open	fi-offline
Finding-69	fix-authored: 2 smaller precision and sourcing points Other sources name different fix commits: Daubois's blog gives 'final commit 01a40e89fbfc authored 2026-10-18'; the collector notes record that rjmendez's repository names 82f8f31b16a. The authored day agrees (18 October), but the hashes are not reconciled with 3584a98bd (possibly the PR head or a per-branch cherry-pick). \| raw/commit-3584a98bd.NEWS.diff is an empty file: Its SHA256SUMS entry is e3b0c442...b855, the hash of zero bytes. The NEWS entry (a34a205c2) appears only in the merge-path listing. The cited github-php-src-tag-php-8.5.12 capture carries none of the fix's times.	low	open	fix-authored
Finding-70	fix-bailout: 1 smaller precision and sourcing point ChangeLog dates the four releases 22 Oct 2026, a day after the release: php-net-changelog-8 lists 'Version 8.5.12 / 22 Oct 2026' (and the same for 8.4.27, 8.3.36, 8.2.35) although php.net and the Foundation say they shipped 21 Oct. Not a problem for this claim, but any page that dates the fix from the ChangeLog would be a day off.	low	open	fix-bailout
Finding-71	fix-engine: 3 smaller precision and sourcing points 'globals that survive a failed request' is narrower than the advisory: GHSA-6wmf: besides a fatal error, 'A warning or other nonfatal diagnostic can also repopulate error state after that state was already cleared during shutdown'. Stale state can survive a request that did not fail. \| Three different fix-commit hashes across sources: The vault reads 3584a98bd (Arnaud Le Blanc, authored 2026-10-18T17:26:39+02:00); Daubois gives 'final commit 01a40e89fbfc authored 2026-10-18'; rjmendez gives 82f8f31b16a. Probably per-branch commits, but nothing in the vault reconciles them. Daubois also says 'The fix touches 390 files' where the site counts 389. \| github-php-src-fix-commit-3584a98bd has no captures/ entry, and its NEWS.diff is empty: fc.py extract reports no text capture for this source; the evidence is raw/ git output with SHA256SUMS. raw/commit-3584a98bd.NEWS.diff has sha256 e3b0c442...b855, the hash of an empty file.	low	open	fix-engine
Finding-72	fix-incomplete: 1 smaller precision and sourcing point Note's quote drops the inner quotation marks and spans a line break: The capture (21/23) reads: was told that it's "unrelated and not a real issue". The site writes 'was told that it's unrelated and not a real issue', merging Rainbolt's words with the words he attributes to PHP. Restore the inner quotes so the reader sees which words are PHP's (as relayed).	low	open	fix-incomplete
Finding-73	four-reporters: 2 smaller precision and sourcing points CVE records credit three parties, not four: The cve.org records (CNA: PHP Group) credit 'Ryan at Calif.io', 'Wiz' and 'OpenAI' (finder on 109618, reporter on 109619) and omit tomash-areion. The site could say the advisories credit four and the CVE records three. \| Affiliations are inferred: The advisories give handles only. The bracketed affiliations are reasonable but come from other pages; tomash-areion's affiliation is unknown. The note's 'appears nowhere else on this beat' should except Daubois, who repeats the advisory credits.	low	open	four-reporters
Finding-74	gov-patch-required: 1 smaller precision and sourcing point Status 'reported' understates a statement carried by NSA's own release; the wording should keep it NSA's: The claim drops 'are serious enough to' and, read without its 'by' line, sounds like a mandate. Suggested: 'NSA says the risks are serious enough to require immediate patching across US Government departments and agencies' with status confirmed (that NSA said it).	low	open	gov-patch-required
Finding-75	imperva-none: 1 smaller precision and sourcing point Population and window should be in the claim: Imperva's negative is about its customer traffic and 'the monitored' patterns, over an undated window ending at disclosure. Cloudflare (thousands of attempts before announcement) and Amazon (17 Oct and 02:00Z attempts) saw pre-disclosure activity elsewhere; say 'Imperva customer traffic' to avoid an apparent contradiction.	low	open	imperva-none
Finding-76	kev-precedent: 1 smaller precision and sourcing point 'after one day' is about 18 hours, and the catalog checked is the 14:04Z 21 Oct version: CVE-2026-109618 published 2026-10-21T13:48Z; KEV fetched 2026-10-22T08:16Z (catalog last-modified 21 Oct 14:04Z). Say 'not in KEV at 08:16 UTC on 22 October'.	low	open	kev-precedent
Finding-77	latvia-offline: 1 smaller precision and sourcing point Translations and UTC conversion are the site's own: The source is in Latvian; "restored by 20:00 UTC" is the site's conversion of the 23:00 local update stamp. Correct, but should be marked as this site's conversion. The latvija.gov.lv capture from outside Latvia failed with net::ERR_CERT_COMMON_NAME_INVALID at 08:19:39Z on 22 Oct, consistent with, but not proof of, the foreign-access restriction.	low	open	latvia-offline
Finding-78	leak-cve-ids: 1 smaller precision and sourcing point Duplicate slugs for one page: php-foundation-blog-security-release and phpfoundation-blog-security-release-leak are the same URL captured 3 minutes apart (only the embedded Reddit vote counts differ). Citing both suggests two sources.	low	open	leak-cve-ids
Finding-79	leak-hn: 3 smaller precision and sourcing points Screenshot 'came down' not carried: Daubois: 'A screenshot of the PHP2Shell tool, credited to Calif.IO, leaked alongside the advisory, and a short exploitation video went up and came down the same way.' Only the video is said to have come down. Also Daubois writes 'Calif.IO', not 'Calif.io'. \| Note's quote of The Hacker News is not verbatim: The capture reads 'a proof-of-concept (PoC) exploit leaked ahead of time'; the note drops '(PoC)'. The Foundation's phrase is capitalised 'No technical details leaked.' in the source. \| Uncited corroboration available: Huntress, CybelAngel and Equixly (all in the manifest) independently describe the removed Hacker News post; citing them would lift this above a single personal blog.	low	open	leak-hn
Finding-80	leak-video: 1 smaller precision and sourcing point Calif has not acknowledged the video in any capture: Calif's page embeds two demo videos and its timeline omits any leak. The deleted video is not in the vault.	low	open	leak-video
Finding-81	leak-watchtowr: 1 smaller precision and sourcing point watchTowr's post is not captured: CERT-EU gives the URL (x.com/watchtowrcyber/status/2112611507749982605, decoded 2026-10-20T18:26:48Z) but the vault has no capture; watchtowr-php2shell and watchtowr-php2shell-faq are 403. CybelAngel and Huntress carry it and are not cited.	low	open	leak-watchtowr
Finding-82	lorenc-ai-found: 1 smaller precision and sourcing point Should read as Lorenc's claim: The claim text states the finding as fact; the evidence is Lorenc's account as paraphrased by The Register ('independently found' is the reporter's wording). Prefix with 'Lorenc says'. 'Independently' also sits oddly with having been told by a researcher that 'something was coming in PHP'.	low	open	lorenc-ai-found
Finding-83	most-severe: 1 smaller precision and sourcing point OpenAI's wording differs between X post and press: The note's OpenAI quote matches the X post ('vulnerabilities'); the BBC and The Hacker News quote 'one of the most impactful security issues in recent memory', presumably from the blocked blog.	low	open	most-severe
Finding-84	nl-offline: 2 smaller precision and sourcing points The phrasing mirrors Insurance Business, which does not list Overheid.nl: The claim's structure ("took its own site offline as a precaution, as did ...") matches Insurance Business, whose list is DigiD, MijnOverheid, the House of Representatives, Port of Rotterdam, KNVB and hospitals. Overheid.nl comes from Reuters (RTE, factbox; Mashable and Wikipedia cite Reuters), one origin. \| Restoration not recorded: ncsc.nl (08:19:19Z) and overheid.nl (08:19:27Z) both returned HTTP 200 with normal content on 22 Oct; BBC says the Dutch cyber agency "is now running again". impact.json gives no end time.	low	open	nl-offline
Finding-85	no-confirmed-compromise: 2 smaller precision and sourcing points CISA KEV snapshot predates the patch release: The KEV file was fetched 08:16Z on 22 Oct but its catalogVersion 2026.10.21 was released 14:04:39Z on 21 Oct, minutes after the 14:00Z PHP release, so the absence of CVE-2026-109618/109619 says little. KEV also records exploitation, not a named victim. There is no text capture: the evidence is raw/known_exploited_vulnerabilities.20261022T0816Z.json (sha ef8fffed...). \| Timeline says CERT.LV saw attempts "none successful": timeline.json (20:00Z event) says "automated attempts seen, none successful"; CERT.LV says only that there are no reports of successful attacks so far ("l_dz _im nav zi_u par sekm_giem uzbrukumiem"). Same nuance as this claim: absence of reports, not a finding of none.	low	open	no-confirmed-compromise
Finding-86	nz-active: 2 smaller precision and sourcing points 'The only agency saying so' needs a precise qualifier: Note (and agencies.json) say NCSC NZ is the only agency saying so. True for 'active exploitation', but CERT.LV, a national CERT, says automated exploitation attempts were already detected in Latvia (21 Oct, 23:00 local). Say 'the only agency to report active exploitation; CERT.LV reports attempts'. \| Cannot tell whether the sentence was in the 9:15am original or the 10:20am update: The capture (08:17Z, 22 Oct) shows the page after its 10:20am NZDT update; only the platforms paragraph is marked as updated, so the sentence is probably original, but one capture cannot show it.	low	open	nz-active
Finding-87	offline-allies: 1 smaller precision and sourcing point acn-it-php2shell is flagged primary=false: It is the Italian national cyber agency's own alert (AL07/261021/CSIRT-ITA) on acn.gov.it, which makes it a primary source for Italy's advice.	low	open	offline-allies
Finding-88	offline-cisa: 1 smaller precision and sourcing point The paraphrase drops 'until they can be patched or updated': CISA's advice is time-bound ('offline until they can be patched or updated'). Without it, the claim reads as permanent removal.	low	open	offline-cisa
Finding-89	offline-ncsc: 1 smaller precision and sourcing point CyberExpress is a copy of the BBC paragraph, not a third witness: cyberexpress-php2shell-gov-sites reproduces the BBC's sentence about the NCSC and its EU and Australian counterparts almost word for word, with US spelling ('organizations').	low	open	offline-ncsc
Finding-90	openai-same-day: 1 smaller precision and sourcing point OpenAI's own framing differs from 'independently, same day': Cybernews relays OpenAI: 'Calif used GPT-5.6 Sol to investigate the flaw. OpenAI's own researcher subsequently identified additional flaws'. The Foundation says OpenAI independently reported the same root cause on 11 August. Both may be true (same root cause on day one, more vectors on 18 September), but the site should show OpenAI's own framing.	low	open	openai-same-day
Finding-91	pocs-wrong: 2 smaller precision and sourcing points Note overstates The Hacker News: THN says 'the public exploit code going around has not been shown to work', not that it has the wrong mechanism. \| Fastly implies existing PoCs can yield code execution: Fastly: 'the existing PoCs require knowledge of the specific, running PHP binary and address space layout on the server for an attack to yield code execution on x86_64'. This reads as PoCs that work given layout knowledge, in tension with 'none has the correct mechanism' unless the populations differ (researcher PoCs vs leaked public ones). The note should say which.	low	open	pocs-wrong
Finding-92	preannounce-time: 1 smaller precision and sourcing point The feed's 20:32Z is not a competing publication time: Alan Coopersmith's oss-security message quoting the php.net archive URL is dated 20:22:51Z, ten minutes before the feed's <published>2026-10-20T20:32:00+00:00>, so the feed timestamp is an authoring or rebuild time. The dispute is between 19:30 and 'around 20:00', both earlier than 20:22:51Z.	low	open	preannounce-time
Finding-93	probing: 1 smaller precision and sourcing point 'Both companies have since said so' gets the order wrong: Both posts are dated 21 October; Woodward spoke on Radio 4 at 06:44 UTC on 22 October (post datePublished 06:44:49Z). The companies said it first.	low	open	probing
Finding-94	quarkslab-2024: 1 smaller precision and sourcing point Note: Cloudflare is not alone in listing Quarkslab: The note says 'Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does'. Imperva's capture (in the manifest) also says 'Reported by: Calif, Wiz, OpenAI, and Quarkslab.'	low	open	quarkslab-2024
Finding-95	quarkslab-redacted: 1 smaller precision and sourcing point Status 'reported' understates a counted record: The count is checkable on Quarkslab's own page (A6). Status could be 'confirmed'. Note that 'does not describe' cannot rule out that a redacted item (HIGH-1, CVE-2024-8928, or MED-2) relates to the OOM issue.	low	open	quarkslab-redacted
Finding-96	rce-fpm: 1 smaller precision and sourcing point Claim omits that the validated FPM path is application-dependent: GHSA-6wmf: 'It works with a normal dynamic FPM pool, although it depends on a suitable application operation.' The bare claim reads as if FPM is exploitable as generically as mod_php.	low	open	rce-fpm
Finding-97	rce-modphp: 1 smaller precision and sourcing point 'default settings' is broader than the advisory's wording, and the claim does not name the CVE: GHSA-w8hw says 'default PHP input and memory limits and normal prefork configurations with multiple workers', and adds that 'Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout'. The before-application-code path is CVE-2026-109618 specifically; naming it would stop readers transferring it to CVE-2026-109619, whose confirmed mod_php case needs fatal_error_backtraces (PHP 8.5).	low	open	rce-modphp
Finding-98	release-moved: 1 smaller precision and sourcing point Release actually shipped before 14:00 UTC; story.json says 'at 14:00 UTC': The schedule was 14:00 UTC, but the GHSAs show 13:34Z, Wiz posted at 13:32:25Z (decoded), CERT-EU says '13:30 UTC' and CybelAngel 'about 13:35 UTC'. story.json's lead says 'On 21 October 2026 at 14:00 UTC the PHP project released fixes'. The claim (schedule moved) is right; the lead sentence is not.	low	open	release-moved
Finding-99	release-time: 1 smaller precision and sourcing point CERT-EU's 13:30 UTC matches no captured artifact: The earliest public artifacts are GHSA-6wmf at 13:34:13Z and GHSA-w8hw at 13:34:25Z, tags at 13:35:38 UTC. CERT-EU's 13:30 may be a rounding; its own publication time '15:20:18' has no timezone.	low	open	release-time
Finding-100	scale-2.6m-hosts: 1 smaller precision and sourcing point No scanner's own publication is captured; methods are not stated: VulnCheck, Censys, VirusTotal and Unit 42 figures all come through news outlets. numbers.json n-censys 'measures' ('Hosts whose HTTP response announces a PHP version below the fixed one') is a reasonable inference but no capture states Censys's method. gist-silascutler-censys-query holds only a Censys search URL.	low	open	scale-2.6m-hosts
Finding-101	scale-30m: 1 smaller precision and sourcing point Only one outlet, no basis, no original audio: No other vault capture repeats the 30 million figure. The BBC summary paraphrases it as 'around 30 million websites ... one expert tells the BBC'. Woodward's own words are from a Radio 4 interview that is not captured.	low	open	scale-30m
Finding-102	scale-70pc-internet: 1 smaller precision and sourcing point The BBC's quoted Wiz words 'roughly 70%' are not in either Wiz capture: The BBC puts "roughly 70%" in quotation marks as Wiz's estimate. Wiz's blog says 'affecting 70% of the Internet' (headline) and 'powers 70% of all websites in the world' (body); the X post says 'impacting 70% of the Internet'. The word 'roughly' is the BBC's. The claim text adopts 'Roughly' and attributes it to Wiz; it should either drop 'Roughly' or attribute the hedge to the BBC.	low	open	scale-70pc-internet
Finding-103	scale-70pc-websites: 1 smaller precision and sourcing point Outlets disagree on the W3Techs figure: about 69-70% versus about 75%: Tenable (69.3%), Imperva (over 69%) and Insurance Business (around 70%, 'W3Techs (August 2026)') against Reuters via RTE and ABC Australia ('roughly 75%' / 'about 75 per cent' of websites whose programming language can be identified). RTE and ABC are vault captures outside the site manifest. The difference may be a date or a different W3Techs measure; capturing W3Techs would settle it.	low	open	scale-70pc-websites
Finding-104	scale-latvia: 1 smaller precision and sourcing point Quoted 'potentially' is the site's translation, and 'public sector' renders 'valsts sektor_' (state sector): The note puts 'potentially' in quotation marks, but the capture is Latvian ('potenci_li'). Quoting a translation should be marked as a translation. 'valsts sektor_' is 'state sector'; 'public sector' is a fair gloss but not exact. numbers.json n-6000-lv also says this is 'the only one that says potentially', yet NCSC-NL's inventory title says 'potentially affected' too.	low	open	scale-latvia
Finding-105	scale-ncsc-nl: 1 smaller precision and sourcing point The cited capture carries no counts: ncsc-nl-php2shell-software-list text.txt (sha 83f3aa60...) is the index page with letter links only. The counts rest on files under sources/ncsc-nl-php2shell/raw/, a source the claim does not cite (numbers.json n-674 does). The tree files are not listed in raw/SHA256SUMS; this desk verified them against the bundle, which is.	low	open	scale-ncsc-nl
Finding-106	uk-list: 1 smaller precision and sourcing point LBC and Insurance Business likely share an origin: The Bristol, Lambeth and Barnet sentence is almost word for word in both, and neither names its source for the list. Treat them as one origin. LBC was published 15:41 BST on 21 Oct, before the fix shipped.	low	open	uk-list
Finding-107	versions-old: 1 smaller precision and sourcing point openwall-oss-security-109619-thread supports only 7.4+, not 5.x: The Greenbone reply carries 'at least versions down to 7.4'; it is cited as if it supports the 5.x statement.	low	open	versions-old
Finding-108	vibe-code: 1 smaller precision and sourcing point The unnamed 'researchers' may be watchTowr; capture The Record and cite it: therecord-php-warnings (in the vault, not in data/sources.json) has watchTowr's Knott on AI-vibecoded PoC tools seen in the wild. Citing it would name a party; it still would not show the tool authors are criminals rather than researchers posting PoCs.	low	open	vibe-code
Finding-109	waf: 1 smaller precision and sourcing point Note says Cloudflare's rules 'blocked the traffic it saw'; the capture does not say that: Cloudflare says it 'successfully deployed multiple mitigations' and 'observed attack traffic targeting our customers', and that attackers mutated payloads to bypass. It does not state that all observed traffic was blocked.	low	open	waf
Finding-110	waf-nine-hours: 2 smaller precision and sourcing points Cloudflare's 'about 9 hours ahead' does not match its own 03:02 UTC: From 03:02 UTC to the first public artifacts (13:34Z) or the scheduled 14:00 UTC is about 10.5 to 11 hours. The claim id says nine hours; the claim text does not. \| Vendors differ on pre-disclosure attack traffic: Cloudflare says it 'observed attack traffic targeting our customers' before the release; Imperva says that during pre-disclosure monitoring it 'observed no traffic matching the monitored PHP2Shell exploit patterns'. Different networks and patterns, so this is probably measures-differently, but the site should not cite either as general.	low	open	waf-nine-hours
Finding-111	watchtowr-itw: 1 smaller precision and sourcing point 'Lists the flaws as exploited in the wild' rests only on search summaries: No capture shows a watchTowr listing; Equixly's pre-advisory page says the opposite at that time. Drop that half until a capture of watchTowr's page carries it.	low	open	watchtowr-itw
Finding-112	weirdgloop-13h: 2 smaller precision and sourcing points 94% is the operator's unaudited figure: No method is given for the 94% (it is "about" and credited to caching). Mark it as Weird Gloop's own figure. numbers.json carries it as a plain value "94%". \| "From cache" and "page views" are paraphrase: The blog says "about 94% of wiki pageviews serving correctly, even with no database or PHP running" and credits "very aggressive caching"; it does not say all of them were served from cache. Also, impact.json's quote uses a straight apostrophe where the capture has U+2019 ("we_ve"): typographic only.	low	open	weirdgloop-13h
Finding-113	who-first: 2 smaller precision and sourcing points 'the flaws' (plural) not shown: Calif reported its first bug on 11 August and 'the second bug' on 21 August; Wiz reported on 24 August and is listed first in the credits of GHSA-6wmf-4rv5-p3rp. Nothing captured shows which party first found CVE-2026-109619. \| Hash pre-image unpublished: The tweet carries only a hex string. Its date is verified by the post ID decode (2026-08-05T15:54:24Z, matching the displayed '15:54 _ 5 Aug 2026'), but what it commits to cannot be checked.	low	open	who-first
Finding-114	wikimedia-precaution: 2 smaller precision and sourcing points "other" dropped from the paraphrase: The statement says "a number of other systems", after saying all Foundation-supported and volunteer-run PHP systems are affected; Mashable describes them as "supporting tools". The claim's "a number of systems" loses that nuance. \| Restoration not recorded: wikimediastatus.net at 08:18:50Z on 22 Oct shows "All Systems Operational" (reading and editing). Insider Paper (via Mashable) says the status page had listed "Emergency Maintenance" on 21 Oct.	low	open	wikimedia-precaution
Finding-115	wiz-independent: 2 smaller precision and sourcing points Note's quote of the Wiz X post is not verbatim: The note quotes 'Wiz Research uncovers'; the capture reads '@wiz_io Research uncovers'. The note also says 'no credit to Calif or OpenAI': true of the lead post, but the same thread says 'Kudos to @GeminiApp, @php_net Core, @OpenAI, @calif_io'. Post ID 2112899813264277528 decodes to 2026-10-21T13:32:25Z, matching the displayed time. \| 'the first flaw' is ambiguous: Wiz's 'the first PHP vulnerability' is Wiz's own first finding. Read on the site, 'the first flaw' can suggest Wiz found CVE-2026-109618 first, which the Calif and Foundation captures contradict. Use 'its first flaw'.	low	open	wiz-independent
Finding-116	wordpress-drupal: 2 smaller precision and sourcing points 'by' says Wiz for WordPress and Drupal; Wiz also confirms Joomla: Wiz's blog: 'achieved unauthenticated remote code execution on WordPress, Drupal and Joomla'. Joomla therefore also has two parties. \| Eight of the eleven applications rest on Calif alone, and its demo video is not captured: MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS appear only in Calif's list; Calif gives versions (e.g. WordPress 7.1.2, Drupal 11.4.3) the claim omits.	low	open	wordpress-drupal
Finding-117	The site is 40 sources behind the evidence vault, and the missing ones change what it can say The vault head is 31ccc515c29f with 184 source folders; data/sources.json has 144, exported at 200d08971937 (11:35 UTC), which is an ancestor of the head through the 12:06 UTC merge of the collectors' branches. The 40 not exported are 35 captures and 5 failed fetches, mostly by collector-news: Reuters (via RTE, Boursorama and a factbox), The Record, Global News, ABC Australia, BleepingComputer, Tagesspiegel/dpa, and captures of operators' own sites (UNIGE and EPFL, two French prefectures, ANTS, Edinburgh council, NCSC.nl, Overheid.nl, Wikimedia status). The impact checker used them: several operators the site does not list were down, and several it lists as down were back up by 08:19 UTC. Board 039 has asked for this re-export since v0.2; it is still not done. Every page footer names vault 200d08971937 as if it were the vault.	high	open
Finding-118	data_vault.json lists five writing agents; the vault has a sixth, collector-news collector-news wrote most of the 40 unexported sources (their source.json says added_by collector-news). The site's agent list and team page do not know it exists.	low	open
Finding-119	Front page: 'Websites on PHP 8.1 or older have no ready-made fix' is contradicted by the source it cites data/plain.json, facts. The php.net advisory (php-net-advisory, cited) says: 'Some distributions and LTS vendors provide backported fixes, so contact your vendor for details'. The PHP project itself ships no release for 8.1 and older, and its minimal source backports for 7.4 to 8.1 are not packages; but distributions and LTS vendors do ship ready-made packages. Say: 'PHP itself has no release for 8.1 or older; your Linux distribution or LTS vendor may have one'.	medium	open
Finding-120	Front page 'latest' still says the NCSC-NL list 'reaches 674 products' BRIEF-CORRECTIONS.md (v0.4.2) records 675 rows at cca173c64ec5 (iBabs dropped by the vault's export). The front page's latest strip, from data/plain.json, still says 674. The correction says the data/software.json counts stay until the export is fixed (board 052); plain.json is hand-written and could carry 675 now.	low	open	scale-ncsc-nl
Finding-121	NVD's CVSS 3.1 score of 9.8 is in the vault and nowhere on the site The vault's raw NVD API captures (nvd-cve-2026-109618 and nvd-cve-2026-109619, raw/nvd-api-2.0.json) carry NIST's own CVSS 3.1 base score 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) beside the vendor's CVSS 4.0 9.2; a fetch of the NVD API at 18:27 UTC on 22 October shows the same. No claim, number, glossary entry or page mentions 9.8. A reader or a scanner using CVSS 3.1 sees 9.8 and finds no explanation here. See K-007.	medium	open
Finding-122	Front page 'Has anyone been hacked?' gives Amazon's honeypot hit but not Amazon's 'broadly exploited in the wild' data/plain.json cards and facts say Amazon reports 'a decoy server was hit four days before the announcement'. Amazon's own post, in the vault (aws-security-blog-madpot), also says 'PHP2Shell is now being broadly exploited in the wild.' The front page is the most-read page and understates the strongest exploitation statement by a named party; it should carry Amazon's words and say what they rest on (its sensors) beside 'no confirmed break-in'. The coverage review flagged this; it is not yet done.	medium	open	amazon-honeypot
Finding-123	The scheduled-capture brief attributes the Censys count to The Hacker News; the vault has it from SecurityWeek admin/content/briefs/2026-10-22__brief__scheduled-capture-json-and-analysis.md, contradiction table: '1.57 million of about 2.6 million hosts unpatched on 21 October (Censys via The Hacker News)'. No Hacker News capture in the vault carries 1.57 million; securityweek-exploitation-days-before does, with a different denominator (K-004). The brief is the editor's and is not edited; this is a note for whoever builds on it.	low	open
Finding-124	The BBC's 'roughly 70_' is not Wiz's wording The BBC live page (bbc-live-ckgel5xp2xv9t, 08:05 UTC capture) puts 'roughly 70%' in quotation marks as Wiz's estimate. Wiz's blog and X post say '70% of all websites' and '70% of the Internet'; neither says 'roughly'. Anything on the site that quotes the BBC's phrase as Wiz's would be a quote of a quote.	low	open	scale-70pc-internet
Finding-125	Front page: 'the PHP project has not answered it publicly yet' has been out of date since 09:11 UTC on 22 October data/plain.json, unknown: 'Whether the fix is complete. A report on 21 October suggested it may not be; the PHP project has not answered it publicly yet.' PHP's security team answered on oss-security at 09:11 UTC (2026/10/22/15): an unrelated crash bug of minimal impact, nothing to do with the RCE. It was true of the vault's capture, which stops before the reply; it is not true of the world. Capture the reply, then close or reword the question, and re-grade fix-incomplete (whose note says 'Nothing from PHP on the list at capture').	high	open	fix-incomplete

Contradictions between sources (11)

Ticket	What	Severity	Status	About
Contradiction-1	K-001: How much of the web: 70_ of websites, or 70_ of the Internet? One origin, Wiz, restated: a share of websites using PHP became a share of 'the Internet' affected, inside Wiz's own post. Every outlet in the vault that carries the figure traces to Wiz, so it is one source, not several (restates, not corroborates). None of them says how the 70% was measured; it matches the usual web-technology survey figure for sites whose server-side language is known, which is a share of websites, not of hosts, traffic or 'the Internet', and not a count of vulnerable installations. The BBC's 'roughly 70%' puts a word in Wiz's mouth that its post does not use.	medium	explained	scale-70pc-internet, scale-70pc-websites
Contradiction-2	K-002: Is php2shell being exploited? They measure different things at different times. Amazon counts attempts against its own sensors and honeypots; CISA and KEV record exploitation it has evidence of against real systems. Both can be true at once: attempts in volume, and no confirmed compromise of a named organisation. The site should never write 'exploited' without saying which of the two it means. Amazon's 'broadly exploited' is the stronger word, sourced to Amazon's own post in the vault; a KEV entry would be the first official signal that attempts have become compromises.	medium	explained	no-exploitation, cisa-none, amazon-honeypot, probing, watchtowr-itw, no-confirmed-compromise
Contradiction-3	K-003: Which PHP versions are affected? Affected, supported and patched are three different lists. The CVE record lists only the supported branches the PHP project fixed; the backports reach down to 7.4; Cloudflare and NVD describe what is vulnerable, which goes back further. They are compatible, but read as a contradiction unless the site says so where it shows the version table.	medium	explained	versions-old, two-cves-9.2
Contradiction-4	K-004: How many systems are still unpatched? The site's claim reads as 1.57 million unpatched out of about 2.6 million hosts (about 60%). The source says 1.57 million out of the 1.58 million whose version could be read (about 99%, on the day the fix shipped); the 2.58 million is all hosts seen, most of which do not announce a version. The two framings give very different pictures. The BBC's 90% has no named counter or method and is not captured. Open, because the site states one framing as fact.	medium	open	scale-2.6m-hosts
Contradiction-5	K-005: How many UK government services went down? Probably the same count, described loosely by The Register. The BBC's line is verified in a fetch by this desk; it says 'a minister' without naming one or the House, so the coverage review's 'in the House of Lords' is not yet carried by any source this desk has read. Neither is captured into the vault: this record is a request to capture.	medium	open	uk-list
Contradiction-6	K-006: How many sites were taken offline? Breadth of collection, and an export lag. The site requires a captured source per row; the tracker accepts aggregator reports and says so per row. Part of the gap is not collection at all: the vault already holds captures of more offline operators than the site shows, because the site's export stopped at 144 sources.	medium	explained	affected-sites
Contradiction-7	K-007: How severe: CVSS 10.0, 9.2 or 9.8? 10.0 was wrong. 9.2 and 9.8 are both right, on two different scales scored by two different parties, and they disagree on one input: the vendor says attack complexity is high, NIST says low. The site explains 10.0 against 9.2 but never mentions 9.8, which is what a reader checking NVD, or a scanner reporting CVSS 3.1, will see.	medium	explained	cvss-10, two-cves-9.2
Contradiction-8	K-008: Which flaw was shown to give code execution on PHP-FPM? The advisories, written by the PHP security team per CVE, put the demonstrated FPM exploit under CVE-2026-109619, and say none was demonstrated for CVE-2026-109618. The Foundation's blog places FPM confirmation under CVE-2026-109618. The blog appears to have swapped the attribution. That RCE was shown on FPM is not in doubt; which flaw does it is.	medium	open	rce-fpm, rce-modphp
Contradiction-9	K-009: Did any technical detail leak on 20 October? Probably different meanings of 'technical detail'. A screenshot of a tool banner and a demonstration video show that an exploit exists, not how it works; the Foundation may mean that no root cause or code leaked. The Hacker News's 'proof-of-concept exploit leaked' is stronger than anything else in the vault carries, and no capture shows a leaked PoC. Open until the Foundation or Daubois says what the Foundation meant.	medium	open	leak-cve-ids, leak-hn, leak-video
Contradiction-10	K-010: When was the release planned, and when did it ship? The original embargo time has two values, 14:00 UTC (the Foundation, echoed by The Hacker News) and 11:00 ET, which is 15:00 UTC (watchTowr, echoed by CybelAngel and others). The release itself is stamped 13:34 UTC on the GitHub advisories, ahead of the announced 14:00. The ChangeLog still carries the original date. The site should say 'about 14:00 UTC, advisories at 13:34' and give both original times.	medium	open	release-moved, release-time
Contradiction-11	K-011: Is the fix in PHP 8.5.12 incomplete? The report and the answer are about different things: the Fediverse post describes some flaw in 8.5.12; the PHP security team says it is a separate crash bug of minimal impact, not a way around the RCE fix. The answer came at 09:11 UTC on 22 October, after the vault's copy of the thread (which stops at 22/2), so the site still says PHP has not answered. Open only until the reply is captured; then it should be marked explained and the claim re-graded.	medium	open	fix-incomplete, more-paths

Evidence gaps (3)

Ticket	What	Severity	Status	About
Gap-1	affected-sites: Operators shown offline in the vault but absent from impact.json EPFL own homepage at 08:19:13Z: "Some EPFL websites are unavailable" after a security alert (epfl-site). Canada: "Some Government of Canada websites have been temporarily taken offline as a precaution" (globalnews-ottawa-sites, AI Minister Evan Solomon). Australia: government sites including the ACSC pulled offline (abc-au-gov-sites-exposed, abc-au-politics-live; cyber.gov.au capture failed ERR_ABORTED). Switzerland: universities of Geneva and Fribourg, EPFL, Basel-Stadt canton (20min-fr-suisse-romande, letemps-php-sites-debranches). Germany: Laender, hospitals, universities still offline Thursday (tagesspiegel-dpa-noch-offline). Czech government site offline 17:00 GMT and Internet Archive (reuters-factbox-websites-offline). None of these are rows in impact.json.	medium	open	affected-sites
Gap-2	fix-incomplete: The Fediverse posts (fedi.katze.sh__elise) are not captured; the thread has no text capture The source openwall-oss-security-109619-thread has only raw/ curl copies (no captures/ entry, no text.txt, no manifest sha for a text file). The origin posts 117479383739450605 and 117478655339557825 are not in the vault, so the claim rests on a relay of an unnamed person.	medium	open	fix-incomplete
Gap-3	pocs-wrong: VulnCheck's review is not captured; the claim rests on a relay Only rjmendez's README reports VulnCheck's finding. None of the five vault captures that mention VulnCheck carries a PoC-mechanism review.	medium	open	pocs-wrong

New evidence found outside the vault (11)

Ticket	What	Severity	Status	About
Evidence-1	CISA KEV, 18:27 UTC on 22 October: neither CVE is listed (catalog 2026.10.21, released 14:04 UTC on 21 October, 1,754 entries) Fetched by the desk. The catalog has not been updated since 21 October 14:04 UTC, before CISA's own alert; so 'not in KEV' is as of that catalog version. Supports the front page's 'did not include these two when last checked' and board 010. Capture into the source watch on every run. Found at www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities, 2026-10-22T18:27Z, sha256 `ef8fffede5c47200`. Not cited until captured.	medium	proposed	cisa-none, no-confirmed-compromise, kev-precedent
Evidence-2	BBC live page, 18:30 UTC: '32 government services were unavailable and four partially unavailable'; 'globally 90_ of systems at risk are yet to do so' Fetched by the desk; the vault's three BBC captures end at 08:05 UTC and carry neither line. The minister is not named on the page, and 'House of Lords' (in the coverage review) is not on it. The 90% is attributed only to 'researchers'. Capture the page as it stands. Found at www.bbc.co.uk/news/live/ckgel5xp2xv9t, 2026-10-22T18:30Z, sha256 `3842343a8de23fc9`. Not cited until captured. a minister said just after midday that 32 government services were unavailable and four partially unavailable because they were being fixed	medium	proposed	uk-list
Evidence-3	The Next Web: 'Officials in Germany, the Netherlands and Japan say they have not seen one succeed'; Mizuho and Shizuoka Bank halted services Fetched by the desk; not in the vault. Bears on no-confirmed-compromise (a dated negative from three governments) and on impact (Japanese banks, via Bloomberg). Capture it, then chase the officials' own statements. Found at thenextweb.com/news/php2shell-millions-exploit-attempts-no-confirmed-b, 2026-10-22T18:30Z, sha256 `c51dfb0561b1bdb2`. Not cited until captured. Officials in Germany, the Netherlands and Japan say they have not seen one succeed.	medium	proposed	no-confirmed-compromise, affected-sites
Evidence-4	PHPocalypse Tracker sites.csv: 50 sites, 2 with no back-up time, each with dark and back times and a source Fetched by the desk at 18:27 UTC. Row-level provenance, and recovery times this site does not record. Its own header warns that aggregator reports are not confirmed at the original source, so each row is a lead, not a fact. Capture the CSV on a schedule (board 057). Found at allixsenos.github.io/phpocalypse-tracker/sites.csv, 2026-10-22T18:27Z, sha256 `8109506bc8026488`. Not cited until captured.	medium	proposed	affected-sites
Evidence-5	php.net releases feed, 18:27 UTC: no PHP release after 21 October Fetched by the desk: the newest releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, dated 21 Oct 2026. Bears on fix-incomplete and the front page's open question 'Whether the fix is complete': no follow-up release as of this check. Found at www.php.net/releases/index.php?json&max=8&version=8, 2026-10-22T18:27Z, sha256 `06f7ddd8254f8298`. Not cited until captured.	low	proposed	fix-incomplete
Evidence-6	CVE records unchanged since the vault's capture; CISA's SSVC still says Exploitation: none Fetched by the desk from the CVE API at 18:27 UTC. CVE-2026-109618 last updated 21 Oct 16:07 UTC, CVE-2026-109619 22 Oct 08:09 UTC, both before the vault's 08:12 UTC captures. CISA ADP SSVC, scored 21 Oct 14:34 UTC, still 'Exploitation: none'. Nothing to re-capture; recorded so the next run can tell if it changes. Found at cveawg.mitre.org/api/cve/CVE-2026-109618, 2026-10-22T18:27Z, sha256 `f856138e139c216e`. Not cited until captured.	low	proposed	two-cves-9.2, cisa-none
Evidence-7	PHP security team on oss-security, 22 October 09:11 UTC: the 'incomplete fix' report is 'unrelated' and 'has nothing to do with the RCE' Jakub Zelenka (who published both advisories) answering Rainbolt's relay of the Fediverse report. This is PHP's public answer that the site's front page says does not exist. High priority to capture: once captured, fix-incomplete should be re-graded and the front page's open question closed or reworded. Found at www.openwall.com/lists/oss-security/2026/10/22/15, 2026-10-22T20:54Z, sha256 `94c69d8f1c07e67d`. Not cited until captured. This is unrelated issue with minimal impact (crash in one component in slightly unlikely scenario). It has nothing to do with the RCE.	high	proposed	fix-incomplete, more-paths
Evidence-8	oss-security 22_14: the deb.sury.org tracker quotes the PHP team, 'aware of that report and there are no new plans as of now' Nicolas Vigier relays a comment on the Debian/Ubuntu PHP packager's issue tracker. Third-hand, but consistent with PHP's own answer in 22/15. Found at www.openwall.com/lists/oss-security/2026/10/22/14, 2026-10-22T20:54Z, sha256 `7f8f85193e75133f`. Not cited until captured. The PHP team is aware of that report and there are no new plans as of now.	low	proposed	fix-incomplete
Evidence-9	oss-security 22_16, 22_19, 22_20: list members say every version from PHP 5.4 is affected, each citing Wiz Three replies to Greenbone's question about versions older than 8.2. All three trace to Wiz's write-up (restates, not corroborates); no reply from the PHP project on versions. Adds echoes to K-003, not evidence. Found at www.openwall.com/lists/oss-security/2026/10/22/16, 2026-10-22T20:54Z, sha256 `04f109cae98defca`. Not cited until captured. It's pubblically document in the writeup that everything from PHP 5.4 is affected	low	proposed	versions-old
Evidence-10	Primary feeds at 20:53 UTC: KEV unchanged (neither CVE), no PHP release after 21 October, NVD now 'Analyzed', CVE-2026-109619 updated 20:08 UTC with five oss-security references KEV is byte-identical to run 1 (catalog 2026.10.21). php.net releases unchanged. NVD moved CVE-2026-109618 from Modified to Analyzed at 20:45 UTC (scores unchanged). The CVE-2026-109619 record's ADP container added oss-security 22/14, 15, 16, 19 and 20 as references. The NCSC-NL repository head is unchanged at 94b4b16db9e5. Found at www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities, 2026-10-22T20:53Z, sha256 `ef8fffede5c47200`. Not cited until captured.	low	proposed	cisa-none, no-confirmed-compromise, two-cves-9.2
Evidence-11	PHPocalypse Tracker, 20:53 UTC: the Dutch data protection authority back at 19:25 UTC; one site still dark (French prefecture websites) Was 2 still dark at 18:27 UTC. Of 50 rows, 49 now have a back-up time. Found at allixsenos.github.io/phpocalypse-tracker/sites.csv, 2026-10-22T20:53Z, sha256 `1534d904219babed`. Not cited until captured.	low	proposed	affected-sites

Runs

Each run is checked against a stated site version and vault commit, so its grades can be repeated by anyone with the vault's read key.

Run	Against	Checked	Opened	Summary
Run-2	site v0.5.7, vault `31ccc515c29f`	fc.py changed (no claim changed since run 1, no source or agencies, exploitation, impact or front-page data changed, vault head unchanged); every open ticket against the current data (none fixed); mode 2: CISA KEV, the CVE and NVD records, php.net releases, the NCSC-NL repository head, the PHPocalypse Tracker, and the five oss-security posts newly referenced by the CVE-2026-109619 record	1 high finding; 1 contradiction (K-011); 5 new evidence (1 high); 0 tickets closed	Nothing on the site changed and none of run 1's 143 tickets can close yet. The world moved: the PHP security team answered the 'incomplete fix' report publicly at 09:11 UTC on 22 October (an unrelated crash bug, 'nothing to do with the RCE'), so the front page's 'PHP has not answered it publicly yet' is out of date; capture the reply (Evidence-7). KEV still lists neither CVE; no PHP release after 21 October; NVD now 'Analyzed'; the PHPocalypse Tracker has one site still dark.
Run-1	site v0.4.7, vault `31ccc515c29f`	all 70 claims against the evidence vault (mode 1); the front page's plain-English facts; 10 contradictions; mode 2: CISA KEV, the CVE and NVD records, php.net releases, the NCSC-NL repository, the BBC live page, The Next Web, the PHPocalypse Tracker	3 high, 56 medium and 65 low findings; 3 evidence gaps; 10 contradictions; 6 new evidence	First run. 10 of 70 claims can be relied on without reservation; 11 carry a status word stronger than their evidence, 6 a weaker one; 2 are refuted as worded (the CVSS 10.0 and 'disclosed on 22 October', which is true only in Australian time). Five quotes on the site are not in the captures they are attributed to. Highest: Italy's ACN does advise taking sites offline, which the agencies table says it does not; the 'contradicted' mark on the allies' offline advice rests on something the BBC did not say; and the site is 40 sources behind the vault. KEV still lists neither CVE at 18:27 UTC.

How the desk works

The desk is factcheck@php.newsroom. Its role, the full model and the runbook a scheduled run follows are in admin/factcheck/README.md; its tickets are an Issues-FS graph in admin/factcheck/.issues/, typed nodes and typed edges in plain JSON files; its grades are data/factcheck.json. Mode one checks every claim against the evidence vault. Mode two goes outside for the weak and the contested, and records what it finds as a request to capture, never as a citation.