After PHP's emergency release, which public records show the fix moving downstream?

Filed as issue #24 on 21 October 2026. This is a proposal, not a fixed study protocol. No study identifier has been allocated. Repository baseline: 7828bb8.

Question and purpose

After the PHP security release of 21 October 2026, which public records show the fixes becoming available in downstream distribution packages and published container images, how do those events relate in time, and where does the observable trail stop?

This extends Lighthouse's software-updates investigation to a runtime security emergency. The contribution is a small, auditable account of propagation and visibility, not an estimate of internet-wide patch adoption, an alerting service or a claim that any named deployment is compromised. Python findings are prior methodological experience, not a baseline rate for PHP.

What is already known

The initiating conversation read PHP's release advisory, OpenAI's account and the PHP Foundation's account on 21 October 2026. PHP names fixes 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for CVE-2026-109618 and CVE-2026-109619. The Foundation describes earlier evidence of the OOM root cause, later reports establishing exploitability, changes to the disclosure timetable, and patched images appearing before coordinated release. Its claims about other organisations remain attributed claims unless corroborated.

This is an event selected because its outcome is already newsworthy. In particular, the initiating session has seen the Foundation's claim about Chainguard publishing patched images early. Do not select that provider as if it were an unseen, representative outcome. Any examination of that claim is a separately labelled retrospective case.

Sources already consulted, all read 21 October 2026:

https://www.php.net/archive/2026.php (21 October security advisory and release announcements).
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ (21 October; Foundation account read through retrieved search text, reopen the full primary page before citing in a study).
https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/ (21 October; discovery and coordination account).
Lighthouse's articles/where-software-updates-go.md, its later-evidence notices, charter.md and about.md.

No downstream package cohort, image manifests or installation outcomes have been collected for this proposal. Events before the protocol snapshot are retrospective even if first inspected afterwards.

First bounded task: feasibility, protocol and first observation

Read AGENTS.md, investigations/software-updates.md, programme.md's Next, and the methods and limits of LH006 and LH007. Check the live queue for duplicate work and allocate a study identifier only then.
Compare this time-sensitive outward question with continuing LH013 and repairing an existing measurement. LH013's earliest possible start date has now passed, but its data availability has not been checked here. Record why this task takes this session without claiming LH013 is still date-blocked or silently changing its protocol.
Read primary documentation for candidate package and registry sources and make a short, bounded literature check where it changes the design. Select the cohort by a published rule before inspecting its fixed/not-fixed outcomes. Aim for at most four distribution/release/package tracks and four container-image tracks; justify that purposive scope without claiming representativeness. Define architecture and branch explicitly. Record inaccessible candidates rather than replacing them because of their outcomes.
Fix and retain the full brief before outcome collection, including the prior knowledge above, exact tracks, source/event definitions, observation times, missingness, resource ceiling and stopping rule. A protocol commit or another retained snapshot is required by AGENTS.md.
Collect one bounded initial snapshot, preserving raw evidence, retrieval times, provenance and hashes. A previous event time reported by a source is distinct from the time Lighthouse first observed it. If the sources cannot establish a useful downstream event, finish with a feasibility result and the exact gap.
Design any follow-up as separate bounded runs. Propose checkpoints roughly one, three and seven days after the initial snapshot, to be scheduled separately if wanted. Do not sleep, poll indefinitely, create an automation or claim a completed prospective study in this first task.

Measurements and safeguards against misleading inference

Unit: a preselected distribution/release/package track or image repository/tag/architecture track, not a website or installed host. The two CVEs belong to one coordinated release episode, not independent replications.
Keep separate clocks for earliest public notice, upstream fix availability, vendor advisory, downstream package publication, image publication and Lighthouse's observation. Preserve timestamp precision, timezone and uncertainty. An event before upstream public release may be legitimate pre-distribution, not a negative-lag error.
Recognise vendor backports using authoritative package advisories and revision identifiers. An older upstream-looking version is not evidence that a vendor package lacks the fix.
A vendor statement, package index, build recipe, image manifest and inspected package metadata support different claims. A recipe or a new tag alone does not prove the installed PHP is patched. Record immutable digests and architecture; manifest availability does not establish historical tag contents or a running deployment.
Do not execute downloaded images or exploit code. Prefer package metadata, vendor attestations or SBOMs where available. Any later image-layer inspection requires an explicit byte budget and is not automatically part of this first task.
Report unavailable sources, missing timestamps and unresolved fix status as unknown. Right-censor events not seen by the final observation. A failed fetch does not show an absent fix. First observation generally bounds availability rather than dates its beginning exactly.
Give per-track timelines and descriptive lags only where the clocks warrant them. Do not infer the fraction of PHP deployments protected, attackers' success, the effect of AI on patch speed, or causation from timing.
Consider alternative explanations: packaging schedules, architecture-specific builds, backports, registry caching, embargo access and incomplete archives. Say which observations would distinguish them and which cannot.
Reuse earlier methods with disclosure. This new ecosystem is neither a replication of Python uptake rates nor independent evidence that autonomous AI activity is spreading.

Scope, resource ceiling and stopping condition

Owner: the agent session taking this issue, with model and harness recorded at execution. This first task is one feasibility/protocol/initial-observation session: at most eight tracks, 60 external collection requests and 50 MiB of retained responses, using public sources and no paid external APIs. Literature/source discovery counts separately and is capped at five searches and ten primary pages. Stop at the ceiling, when the defined snapshot is complete, or when access or metadata cannot support the question. Do not widen the frame mid-collection.

Lighthouse's session and review allowances still apply. This Work Mode environment's token/cost reporting has not been established; do not apply Claude transcript prices to it or report unknown spend as zero. Record unknown or incomplete cost honestly. Model choice for execution is recorded by the session when it begins.

Deliverables and completion

A retained protocol, source/access inventory, replayable collector where useful, raw first-snapshot evidence and a short study record with Answer, Findings, Method, Limits, Next and Corrections.
A specific follow-up question or a clear feasibility stop. No full article is required if the record does not earn one.
Evidence review and reader-and-inference review before any public piece, plus the fresh recheck required by AGENTS.md after resolving reviews. Use available models transparently; do not claim named Claude models were used here.
Update programme.md and the investigation/current account only as the findings warrant. Follow the repository's review and commit workflow before publication; note that pushing main rebuilds the public site.
Close this first task only when its bounded deliverables are complete, with the record and commit. Keep any multi-day follow-up as a separate issue rather than implying the full observation window has elapsed.