Lighthouse

Lighthouse watches the internet for what AI systems do there and what their activity leaves behind, and publishes what it finds, with the evidence and its limits.

Notes

R-0032: Evidence review of the PHP account's later evidence (version 1.1)

Date: 23 October 2026. Reviewer: a Claude Code review subagent on Claude Fable 5.1, dispatched by the driving session. Reviewed: commit f05bb41 against its parent 7ef696d (the diff of articles/php-emergency-first-reading.md, articles/short/php-emergency-first-reading.md, README.md, investigations/software-updates.md, programme.md, observations.md and the new studies/LH029/), with the working tree at HEAD 950e643, which changed none of those files. The brief was read at its protocol commit a41f896 and compared with HEAD. Cost: unknown at the time of writing; priced afterwards by the driving session from the transcript with harbour/hb tokens at $2.96 at list rates (22 calls, 520 seconds). Files this review created: this note, and under studies/LH029/review/ the scripts extract_check.py and live_read.py, their outputs extract_check.txt, live-archive-2026-10-23.raw and live_read_log.json, and four screenshots. Nothing else was edited. No key or token was read from the environment, and no search touched harbour/.session/.

This review's agreement is a review contribution, not independent confirmation. Nothing here verifies PHP's or Cloudflare's claims about their software or rules; it checks that the account says what the retained bytes say, at the certainty they allow.

What I checked

  1. The study's own replays, from the repository root. python3 studies/LH029/scripts/replay.py verified the retained archive page (102,923 bytes, SHA-256 941317fe…11dc), re-extracted entry 2026-10-23-1 with datetime="2026-10-23T10:12:28+00:00" and one body link (the GitHub advisory GHSA-6wmf-4rv5-p3rp), matched the stored extraction, and reported 57 entries in LH024's 22 October copy against 59 in the 23 October copy: added 2026-10-23-1 and 2026-10-21-6 (the 8.6.0 RC4 entry, attribute 21 October 15:41:41 UTC), none removed, and entry 2026-10-21-5 shorter by two sentences about rpms.remirepo.net. python3 studies/LH029/scripts/unchanged_check.py gave one OpenAI visible-text hash (ff4dae37a7515a00, 227 chunks) and one 195-byte Amazon placeholder (5b131ca14aa96311) across LH028's six snapshots. python3 studies/LH028/scripts/replay.py --snapshot 2026-10-23T1600Z and --snapshot 2026-10-22T2200Z verified all six bodies.
  2. Independent re-extraction, with html.parser rather than the study's regular expressions: python3 -I studies/LH029/review/extract_check.py, output in studies/LH029/review/extract_check.txt. It reads only retained bytes: studies/LH029/data/snapshot-2026-10-23/archive.raw, studies/LH024/data/snapshot-2026-10-22/php_0.raw and the six studies/LH028/data/snapshot-*/cloudflare.raw. It confirms the entry's text, link and attribute; prints the entry's raw HTML; confirms that the 22 October copy contains no 2026-10-23-1, no 115560, no serialize_handler and no "Informational advisory", and that its one upload_progress occurrence is in the 21 October advisory's list of partial measures ("RCE via stale global state (CVE-2026-109619): Set session.upload_progress.enabled=0 and restart every worker. This blocks the confirmed session paths but not other variants.", under "the following measures reduce exposure to specific attack paths but do not make an installation safe"); lists the datetime attributes of every entry from 20 October (20 October 20:32:00; 21 October 00:05:37, 00:14:54, 00:20:54, 00:24:52, 00:35:26 and 15:41:41; 23 October 10:12:28, all UTC); and for Cloudflare prints article:modified_time for each snapshot (21 October 19:12:17.798 UTC in the first two, 22 October 19:09:42.850 UTC in the next three, 23 October 15:09:11.234 UTC in the last), the links to php.net, every visible sentence mentioning the related flaw or the response firewall, and sentence-level diffs 22 October 16:00 to 22:00 and 23 October 10:00 to 16:00.
  3. Every quotation and paraphrase on the changed surfaces against those bytes (listed under "Quotations checked" below).
  4. Labels and clocks: whether each surface says PHP named versions, how "fixed" is qualified, and how the datetime attribute is treated (findings M1 and S5).
  5. Absolutes and consistency: the article summary, the front page, the short form, the investigation page and the programme paragraph, read side by side.
  6. Figures: both SVGs rendered at 900 by 660 with /opt/pw-browsers/chromium_headless_shell-1243/chrome-headless-shell-linux64/chrome-headless-shell --no-sandbox --hide-scrollbars --window-size=900,660 --screenshot=…, with and without --blink-settings=preferredColorScheme=0; PNGs in studies/LH029/review/. Neither SVG contains a prefers-color-scheme rule, and the light and dark PNGs are byte-identical (boundaries 0bb71f74…, timeline 75c61b9e…): each figure paints its own light background and renders the same in both themes, legibly. The boundaries map's first row reads "PHP publishes fixes / Four supported branches in this episode / Observed", which is what the new caption note refers to.
  7. One live read, the only one this review was allowed: python3 -I studies/LH029/review/live_read.py fetched https://www.php.net/archive/2026.php at 17:11:23.07 to 17:11:23.78 UTC on 23 October, HTTP 200, 102,923 bytes, SHA-256 941317fe0df9a5e2c642f3b817724c9682ad1e751707b5db8a65d86c21ae11dc, identical to LH029's 17:00 read; retained as studies/LH029/review/live-archive-2026-10-23.raw with live_read_log.json. The entry had not changed between 17:00 and 17:11 UTC. No other site was read.
  8. The record against its brief: git diff a41f896 HEAD -- studies/LH029/brief.md shows one change, the header's "about 17:10 UTC" corrected to the commit time (commit 7ef696d, 17:00:01 UTC, before the read at 17:00:11 UTC); the record discloses this. One GET was made of the three allowed, 102,923 bytes of the 3 MiB; the entry's only link is to github.com, recorded and not read as the brief requires, so the two follow-up reads were rightly not made. All six questions are classed with the brief's three classes, (a) as "not stated in the retained bytes", and the prior knowledge from the web reader and from Cloudflare is disclosed and not used as an observation. LH024 has no 23 October snapshot (studies/LH024/data/ holds only snapshot-2026-10-22), so the record's interval, absent at 06:24:43 UTC on 22 October and present at 17:00:11 UTC on 23 October, is the tightest the retained copies allow.

Not checked: the 13:30 UTC CERT-EU and 14:00 UTC embargo clocks and the 19:33 announcement time in the timeline (version 1.0 claims, reviewed in R-0029, except that LH024's php_1.raw does carry datetime="2026-10-20T19:33:47+00:00" for the php.announce message); the GitHub advisory the entry links to (not read, by the brief's rule); the record's "pushed 16:59:50 UTC", which the clone cannot show (its reflog holds only a fetch at 16:56:11 UTC; the commit time 16:59:44 UTC is verifiable); LH028's record text and the untracked discovery-pass and LH030 files in the working tree, which are outside this review.

Quotations checked

  • Article notice and "What changed", "unlikely" route, "to fully protect from an unlikely RCE vector": bytes read "until the next regular bugfix release, to fully protect from an unlikely RCE vector". Exact.
  • Article, session.upload_progress.enabled=0, php_binary, php_serialize, php, "in its own code before starting a session": bytes read "set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled." Faithful.
  • Article, "Applications that never switch can keep the feature": bytes read "Applications that never change the serialize handler at runtime can keep the feature enabled." Faithful.
  • Article, "PHP will publish a full advisory with its next release": bytes read "will publish a full advisory for CVE-2026-115560 with the next release". Faithful.
  • Article, "The setting is the one PHP listed on 21 October as a partial stopgap for one of the two original flaws": 23 October bytes read "already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619 published on Oct 21st, 2026"; the 22 October copy's advisory lists it under measures that "reduce exposure to specific attack paths but do not make an installation safe". Faithful; "partial" is supported.
  • Article, Cloudflare 23 October, "affects fully patched PHP releases, including 8.5.12": bytes read "It affects fully patched PHP releases, including 8.5.12, and will be fixed in PHP's next regular release." Exact. "links to PHP's notice": the 16:06 copy holds https://www.php.net/archive/2026.php#2026-10-23-1, absent from every earlier copy. "edited at 15:09 UTC by its own metadata and first seen by us at 16:06 UTC": article:modified_time 2026-10-23T15:09:11.234Z; LH028 read log start 16:06:13 UTC. "protects against known exploit attempts on sites that keep PHP's default name for the upload-progress field, and not on sites that changed it": bytes read "All Cloudflare WAF customers are protected against known exploit attempts if their site uses PHP's default upload progress field name. Customers who have changed session.upload_progress.name are not covered by the WAF rule." Faithful.
  • Article, Cloudflare 22 October, "at 19:09 UTC by its metadata, relabelled its PHP rules with the two flaws' identifiers and said its new default managed response firewall had been deployed automatically for customers on all plans, including Free": article:modified_time 2026-10-22T19:09:42.850Z; the 16:00 to 22:00 diff renames seven Free and seven paid rules from "Generic Rules - Anomalous Execution - n" to "PHP Remote Code Execution Attack (CVE-2026-109618, CVE-2026-109619)" and replaces a one-rule table with "The new Cloudflare Managed Response Firewall Default has been automatically deployed for customers on all plans, including Free." Faithful.
  • Article, "Unchanged": six snapshots from 22 October 13:42 UTC to 23 October 16:06 UTC, one OpenAI text hash, one Amazon placeholder. Supported.
  • Article notice and summary, short form, README, investigation page and programme, "PHP names no version" or "It names no version": the entry contains no version string; the 23 October page's six occurrences each of 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are all in the 21 October entries. Supported. Each of the five surfaces attributes the scope to PHP's advice as an implication and, where Cloudflare is named, to Cloudflare as a statement; none says PHP named the affected versions.
  • Record, Answer and Findings: every quotation matches the bytes; "does not carry PHP's unusual-combination condition or the setting itself in its update paragraph" is true of Cloudflare's inserted paragraphs; the "two other differences" match my diff; the Limits' 00:05 to 00:35 UTC range matches the five attributes.
  • programme.md, "the 21 October entries carry times hours before the reported release": 00:05:37 to 00:35:26 UTC against the 13:30 UTC release the account reports. Supported.
  • README, "its advice implies those fixed versions do not close it"; investigation page, "its advice implies the 21 October releases do not close it, as Cloudflare's revised page says outright"; programme, "which Cloudflare states outright": consistent with the article and record, at the same certainty.

What I found

Must fix before release

M1. The article's clock sentence presents PHP's time stamp as a publication time and 17:00 UTC as our first read; the record's own evidence contradicts both. Passage: articles/php-emergency-first-reading.md, "What changed after 22 October", first item: "The page gives the notice an entry time of 10:12 UTC; we first read it at 17:00 UTC." Evidence: the page carries <time class="newsdate" datetime="2026-10-23T10:12:28+00:00">23 Oct 2026</time> and documents no meaning for the attribute (studies/LH029/review/extract_check.txt, raw HTML). The same attribute reads 00:05:37 to 00:35:26 UTC on the five 21 October entries, thirteen hours before the 13:30 UTC release the account reports; 15:41:41 UTC on the RC4 entry that was absent from the copy read at 06:24:43 UTC on 22 October; and 20:32:00 UTC on the 20 October entry whose php.announce message LH024 retained is dated 19:33:47 UTC, so the attribute runs both earlier and later than a notice's own first clock. The record (LH029.md, Limits), the investigation page ("the page's entry time of 10:12 UTC is not proof of when the text became public") and programme.md all carry this qualification; the article does not, which also breaks the consistency rule. And studies/LH029/sources.md records that a web reader opened the entry before 16:36 UTC; 17:00 UTC was the first retained read. Replacement: "The page stamps the notice 10:12 UTC, but that stamp is PHP's own and has run hours ahead of publication on earlier entries, so it does not say when the text became public. The notice was not on the page when we read it at 06:24 UTC on 22 October; our first retained read of it was at 17:00 UTC on 23 October."

M2. The colophon promises reviews in the release log that the log does not yet hold. Passage: articles/php-emergency-first-reading.md, colophon: "Version 1.1 … its reviews are listed in the release log." Evidence: releases.md's newest entry (line 5) is version 1.0 of 22 October; no 1.1 line exists at 950e643. Resolution at release: add the releases.md line for version 1.1 naming this note and the reader review, with their findings and who made the fixes, as the other entries do; or, if the piece is merged before that, name the reviews in the colophon as version 1.0's does. Not a wrong claim today, but it becomes one the moment version 1.1 is published without the line.

Should fix

S1. LH028 is listed twice in the investigation page's front matter. Passage: investigations/software-updates.md, studies: list, "- studies/LH028/LH028.md" at the original position and again after the new "- studies/LH029/LH029.md" (diff of f05bb41). Replacement: delete the second "- studies/LH028/LH028.md".

S2. The observations catalogue does not list LH029's read. Passage: observations.md, PHP row: "retained PHP/registry/GitHub/provider pages, OCI hashes and replay scripts in LH018–LH028" and "Read 21–22 October 2026; LH028's six-hourly checkpoints through 23 October 16:06 UTC retained". Evidence: observations.md is "every observation so far"; LH029 is one retained read (17:00:11 UTC, 23 October) with its record. The cell also keeps en dashes. Replacement: "LH018 to LH029" and "Read 21 to 22 October 2026; LH028's six-hourly checkpoints through 23 October 16:06 UTC and one read of PHP's news page at 17:00 UTC on 23 October (LH029) retained; later checkpoints planned, not yet observed".

S3. The 22 October Cloudflare item gives the page's clock but not ours, where the 23 October item gives both. Passage: articles/php-emergency-first-reading.md: "22 October, Cloudflare. An earlier edit, at 19:09 UTC by its metadata, relabelled…" Evidence: studies/LH028/data/snapshot-2026-10-22T2200Z/read_log.json, cloudflare start 22:00:08 UTC; the 16:00 UTC copy still carried the 21 October modified time. Replacement: "An earlier edit, at 19:09 UTC by its metadata and first seen by us at 22:00 UTC, relabelled…"

S4. "Need do nothing more" drops PHP's instruction to keep the setting. Passages: articles/php-emergency-first-reading.md, "anyone who applied it then need do nothing more"; studies/LH029/LH029.md, Answer, "those who applied it then need do nothing more". Evidence: bytes read "If you applied it then, keep it in place and no further action is needed." Replacement: "anyone who applied it then should keep it in place and need do nothing more" (and the same in the record).

S5. The record and the programme call the attribute "PHP's entry time", which reads more into it than the page gives. Passages: studies/LH029/LH029.md, Limits: "The attribute is therefore PHP's entry time, which need not be when the text became public." programme.md: "The entry's datetime of 10:12 UTC is PHP's entry time, not proof of first visibility". Evidence: as M1; the page documents no meaning, and the 20 October entry's attribute (20:32:00 UTC) is later than the php.announce message's date (19:33:47 UTC, studies/LH024/data/snapshot-2026-10-22/php_1.raw), so the attribute is not simply an early entry time either. Replacement (record): "The attribute is a time PHP attaches to the entry; the page does not say what it marks, and the evidence shows it is not when the text became public: the five 21 October entries carry 00:05 to 00:35 UTC against a 13:30 UTC release, the RC4 entry's 15:41 UTC preceded a copy that lacked it by fifteen hours, and the 20 October entry's 20:32 UTC follows the php.announce message's 19:33 UTC." Replacement (programme): "The entry's datetime of 10:12 UTC is a stamp PHP attaches, not proof of first visibility: the 21 October entries carry times hours before the reported release."

S6. The notice's plain-words condition is broader than PHP's. Passages: articles/php-emergency-first-reading.md, notice: "arises only in applications that change the format of their stored session data in their own code while that feature is on"; articles/short/php-emergency-first-reading.md, notice: the same words. Evidence: PHP's condition is a configuration that sets one of two named formats and code that switches to a third, named, format at runtime before the session starts. A reader of the notice or the short form alone, which is how a notice and a short form are read, would take any runtime change of format to qualify; the exact condition appears only in the "What changed" list. Replacement: "arises only in applications whose configuration stores session data in one of two named formats and whose own code switches to a third before starting a session, while that feature is on".

Optional

O1. Colophon: "from a retained read of PHP's notice and LH028's retained Cloudflare revisions" puts a study number in prose; "and retained copies of Cloudflare's revisions". The same sentence lists what 1.1 adds but not that it extends the summary; "adds the later-evidence notice, the caption note and the dated list of changes, and extends the summary". O2. programme.md, "a one-read protocol": the brief allows one read and up to two bounded follow-ups; "a protocol of one read and at most two follow-ups, none needed". O3. studies/LH029/LH029.md header and brief, "pushed 16:59:50 UTC": the clone can verify the commit time (16:59:44 UTC) but not the push; cite the commit time, or keep both and say the push time is from the session's own log. O4. README.md: "a further, unlikely route to running code" states PHP's judgement in our voice; "a further route to running code that PHP calls unlikely, open by its account only in some unusually configured applications". O5. Article Sources line names both Cloudflare revisions but links only the 23 October checkpoint; add studies/LH028/checkpoints/2026-10-22T2200Z.md. O6. Figures: nothing to change for 1.1. At the next redraw, the boundaries map's first-row subtitle could carry "fixes for the two emergency flaws", so the caption note is no longer needed, and both SVGs could take a prefers-color-scheme rule or keep their painted background deliberately, as they do now.

Verdict

Two things must be resolved before version 1.1 is released: the article's clock sentence (M1), which presents a source attribute of undocumented meaning as a publication time and a retained read as a first read when the record itself says otherwise, and the release-log line the colophon already promises (M2). Neither changes the main claim of the later-evidence notice. With those made, and S1 to S6 considered, the five surfaces say the same thing at the same certainty: PHP described a further, separately numbered path it calls unlikely, under a configuration condition it states, named no version, and advised a setting until its next regular release; the scope to the 21 October releases is an inference from PHP's advice, labelled as such everywhere, and Cloudflare's explicit statement is attributed to Cloudflare. Every quotation on the changed surfaces matches the retained bytes, including Cloudflare's 22 and 23 October wording and modified times; the replays run; the record honoured its brief's read bounds, classes and disclosures, and its Answer, Limits and Findings claim no more than the bytes support, apart from the wording in S4 and S5. The figures were not redrawn and the new caption note matches the first row of the map. The one live read this review made found the entry unchanged eleven minutes after LH029's read.

Resolution, by the driving session

Made on 23 October 2026 in commit 390b611, before the reader-and-inference review was dispatched.

  • M1: the article's clock sentence now reads "The page stamps the notice 10:12 UTC, but on earlier entries the same stamp fell hours before their notices could be read, so it does not say when this text became public. The notice was not on the page when we read it at 06:24 UTC on 22 October; our first retained read of it was at 17:00 UTC on 23 October." The proposed "run hours ahead of publication" was narrowed to the two cases where the stamp precedes visibility (the 21 October entries and the RC4 entry); the 20 October case is kept in the record, where its comparison with the php.announce message can be stated exactly.
  • M2: the colophon now names this note and the reader review; the release-log line for version 1.1 is added at release.
  • S1 to S6 as proposed: LH028's duplicate removed from the investigation page; observations.md lists LH029's read and loses its en dashes; the 22 October Cloudflare item gives our first-seen time, 22:00 UTC; "should keep it in place and need do nothing more" in the article and the record; the record and the programme call the attribute a stamp PHP attaches, with the record giving all three comparisons; the notice and the short form state PHP's condition as two named formats switched to a third before the session starts. The investigation page's "entry time" became "stamp" for the same reason.
  • Optional: O1, O2, O4 and O5 taken; O3 taken as the commit time with the push time attributed to the session's own log; O6 left for a redraw.

From notes/R-0032-php-later-evidence.md in the repository, last changed 23 October 2026.