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.

Studies LH030

LH030: How does PHP's 23 October mitigation instruction travel through a fixed panel of public notices and vulnerability records?

Protocol 0.1, fixed 23 October 2026 before this study's first read of any panel URL for its outcome. Writer: a Claude Code driving session (Claude Opus 5.5). Priority 3 of notes/php-watch-continuation-2026-10-23.md. The frame, classes, schedule, collector and classifier below are committed together; the collector and classifier are the instrument.

Question

On 23 October PHP suggested setting session.upload_progress.enabled=0 until its next regular bugfix release, against an "unlikely RCE vector", CVE-2026-115560, that by its account needs an application to switch session.serialize_handler from php_binary or php_serialize to php at runtime (studies/LH029). Across a fixed panel of seven structured vulnerability records and eight institutions' notices, which come to carry that instruction, with or without PHP's condition, with what claim about which versions are affected, with an explicit link to PHP, and when, as bounded by Lighthouse's reads and as each source dates itself; and after PHP's next regular release, which mark the issue fixed? The unit is a panel entry (a record, or an institution with its fixed URLs), counted once, observed at each read.

What is already known of the outcome

  • PHP, the source (LH029, read 17:00 UTC): names the issue, carries the instruction and the condition, names no version, and promises a full advisory with the next release. Its entry carries a datetime of 23 October 10:12:28 UTC, PHP's entry time, not proof of first visibility. PHP is read at each run as the reference, not counted in the frame.
  • Cloudflare, a frame member (LH028, read 16:06 UTC): its revision of 15:09 UTC by its metadata names CVE-2026-115560, links to PHP's notice and says it "affects fully patched PHP releases, including 8.5.12"; its update paragraph carries neither the instruction nor PHP's condition, but a condition on its own WAF rule's coverage (session.upload_progress.name). The classifier gives it I yes, II no, III no, V yes (known answers).
  • Outside the frame: SOCRadar's page (discovery pass, notes/php-discovery-2026-10-23/, read 17:08 UTC) carries the instruction and the condition, says "the October 21 releases do not fix" the issue and links to PHP; CybelAngel's, last modified 21 October, predates it. The keeper's web-reader account of PHP's notice (continuation plan). Neither page is in the frame.
  • Before the instruction existed: every institutional URL below was read by LH024 on 22 October at 06:24 UTC. CISA's refused (HTTP 403) and AWS's and Google Cloud's returned a 195-byte Site Unavailable placeholder; the others were read in full. Those 22 October copies are the classifier's negative controls: none is classed I, II or III.
  • Access to the records: a feasibility check read all seven trackers anonymously for an unrelated flaw, CVE-2024-4577, at about 17:12 UTC: each answered HTTP 200 with its own time fields (CVE Program dateUpdated, NVD lastModified, OSV modified, Ubuntu updated_at, Red Hat public_date, SUSE a Last-Modified header, Debian none), and Ubuntu and Red Hat expose a mitigation field. Debian's page for that unrelated flaw incidentally listed bookworm's security suite at PHP 8.2.35. No record for CVE-2026-115560 has been read.

Frame, fixed by role

panel.json fixes every URL. Records (7): the CVE Program's record API, NVD's CVE API, OSV's API, Debian's security tracker, Ubuntu's CVE JSON, Red Hat's security data JSON and SUSE's CVE page, each for CVE-2026-115560. Notices (8 institutions, 11 URLs): LH024's fixed institutional selection of 22 October except PHP: UK NCSC, CISA, CERT-EU, Cloudflare, Fastly (blog and changelog), Akamai, AWS (two Amazon Linux advisories) and Google Cloud (blog and bulletins page). Azure had no URL in LH024 and has none here. LH024's media and the discovery pass's vendor blogs are left out, because fixed article URLs from 21 October are not where new reporting appears and finding new articles would make this a search.

Reads and schedule

A baseline read as soon as this protocol is pushed on 23 October; then one read in each UTC day through 30 October; then on each Monday and Thursday, until the first scheduled read at least two days after PHP's news page shows its next regular bugfix release for the 8.x branches, and in any case not after 30 November 2026. PHP's earlier regular releases fell on 27 August and 24 September, so the next might fall about 19 November; that is an inference from cadence, and PHP gives no date. Each read runs the collector once: one GET per URL (19 in all), raw bytes up to 1 MiB each, retained under data/read-<UTC label>/ with UTC start and finish, status, content type, Last-Modified, length and SHA-256. No search, crawl, login, exploit, probe of any site or paid service. A missed read stays missed, a repeat inside one UTC day is not a second observation, and nobody contacts any source.

Classes

The classifier, fixed here, reports for each body read in full: I names the issue (CVE-2026-115560, or a session serialise-handler term); II carries the instruction (session.upload_progress.enabled set to 0, off or false, or disabling session upload progress) within 1,500 characters of an I anchor; III carries PHP's condition (serialise handler, php_binary or php_serialize) near an anchor; IV a version-scope phrase near an anchor (one of 8.5.12, 8.4.27, 8.3.36, 8.2.35, "fully patched", "October 21 releases"), with snippets; V an explicit link to PHP's notice or to the CVE record. For a structured record about CVE-2026-115560, "near" is the whole record. Proximity misfires for IV, as the known answers show (PHP's next entry and SOCRadar's table of the original fixes), so IV is decided by a hand reading of its snippets under one rule: explicit where a sentence or field asserts that releases of 21 October, or a named one of them, are affected by CVE-2026-115560 or do not fix it; none otherwise. Each IV decision is written with its quotation. A structured record's affected and fixed fields, and Debian's per-release status, are recorded as given at each read; a record that names a fixed version or marks the issue fixed is classed retired (VI). A body under 1,000 bytes, a refusal, a placeholder or a challenge is unavailable at that read; a 404 from a tracker is no record at that read, which is not a statement that the tracker did nothing. Unknown is never no.

Clocks and the comparison that matters

For each entry and class, the observation clock is an interval: after the last read that did not show it and at or before the first that did; the baseline read is left-censored, since PHP's entry time is 10:12 UTC and the baseline comes hours later. Each source's own time field is recorded beside it and never substituted. The comparison is per entry: which entries carry II, and of those which also carry III (an instruction kept with its qualification) and which an explicit IV that PHP did not state; which link to PHP (V); how the intervals fall from PHP's entry time; and, after the next release, which are retired. Counts are of entries in this frame, with unavailable entries counted apart; no rate beyond the frame and no diffusion speed follows. An explicit link shows a public citation, not that anyone read it, acted on it or coordinated privately; an absence from a fixed URL does not show that an institution said nothing elsewhere.

Overlap

LH024's daily panel reads the same institutional URLs through 28 October and LH028 reads Cloudflare's page every six hours through 24 October; their reads stay theirs, and no read is counted in two studies. The records are new to Lighthouse. The PHP reference read duplicates LH029's page by design.

Ceiling, stopping and what would leave it inconclusive

At most 20 GETs and 20 MiB per read, and about 20 reads; collection needs no subagent. A first record follows the baseline; an interim record after 30 October; the final record after the stop. Any piece needs its own reviews. The study is inconclusive for an entry that stays unavailable, for the timing of any class whose reads were missed around it, and as a whole if fewer than half of the entries are readable at most reads. It cannot say how many applications are exposed, whether any operator followed the instruction, or how the instruction reached anyone who did not publish it.

Correction before the baseline read, 23 October 2026, 17:15 UTC. Protocol 0.1 as pushed in a61c66d said 20 GETs per read; the panel has 19 URLs (the PHP reference, seven records and eleven notice URLs). The ceiling of 20 is unchanged. No outcome had been read.

Amendment 1, 24 October 2026, 07:44 UTC, after the baseline and one daily read had been seen. At the keeper's request, given the significance of the event, reads are added at about 00:30, 12:30 and 18:30 UTC beside the daily read at about 06:30, through 30 October 2026, under the same collector, classes and ceilings. Each read keeps its own label and log; a read within a UTC day is a separate observation, and its only effect on the analysis is to narrow the observation intervals. The schedule after 30 October is unchanged. No class, frame or rule changes, and nothing already observed is re-read or re-classified.

Amendment 2, 25 October 2026, 07:06 UTC. At the keeper's agreement, after three days in which nothing in the frame changed overnight, the read at about 00:30 UTC is dropped from 26 October. Reads continue at about 06:30, 12:30 and 18:30 UTC through 30 October; nothing else changes.

Amendment, 9 November 2026: the keeper's robots.txt rule

By the scheduled run of 9 November 2026 (in force from that day's read; not retroactive). The keeper decided on 8 November 2026 that Lighthouse obeys robots.txt as its own agent and as whatever runs it (AGENTS.md, Rules that matter; scripts/robots_rules.py, scripts/robots_tokens.json). The collector now import urlopen from scripts/lh_fetch.py, which asks scripts/robots_gate.py before each request: each host's robots.txt is read once per run, and a URL it disallows, or whose robots.txt cannot be read, is not requested and is logged "NotFetched" with the deciding group and rule, a missing reading and never a negative. The User-Agent now carries Lighthouse's token (Mozilla/5.0 (compatible; Lighthouse-research/1.0; +https://lighthouse.harbour.cat)), and email addresses are withheld from kept bodies (the fetch log keeps the hash of the bytes received). Whether a site's robots.txt allowed this study's earlier requests was not checked here; those requests are for the rules-of-the-road re-audit (studies/LH047, row LH047-reread). At the first read under the rule every panel URL was allowed; a first attempt at 14:22 UTC lost its bodies to a bug in the change and is kept only as a record of the requests (data/read-2026-11-09T1422Z/FAILED.md).

From studies/LH030/brief.md in the repository, last changed 9 November 2026.