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-0030: PHP emergency account, reader-and-inference review

22 October 2026. Produced by a separate Codex reader-review agent. Read the latest draft long account, short form, README lead, both SVG sources and their rendered images after R-0029. This agent also supplies the fresh reading of the clock and AI wording introduced to resolve R-0029. No public piece was edited; no commit or push was made.

Dispatch limitation: this was not a blind stage 1 under notes/reader-review.md. The driving session explicitly supplied R-0029 and asked this reviewer to read it and recheck its resolutions. That note was read before the pieces. The reader assessment below is therefore an informed fresh reading, not an uncontaminated test of what an unbriefed reader would infer. Agreement is a review contribution, not independent confirmation of the publishers' observations.

What a reader would believe

A PHP security emergency produced several different kinds of public evidence. Amazon reports an attempted exploit against a decoy on 17 October, before the 21 October public disclosure and fixes. This is a retrospective account, not a Lighthouse sensor observation, and neither success on a real website nor the attacker's source of knowledge is established. AI helped a researcher discover a flaw; people and organisations coordinated fixes and protection. The attack reports do not identify AI use by attackers.

Some providers say they deployed firewall protection; this is different from updating PHP at a website. Selected official and derivative registry images already declared fixed versions when Lighthouse first checked them, and a selected Drupal image contains matching base-layer digests. Those facts show publication boundaries crossed, not the speed or proportion of deployment. The sources do not establish global attack volume, successful intrusions or how many sites are fixed. The Amazon article was readable through one instrument but could not be archived as article bytes by the direct collector. The account promises further dated readings rather than presenting these first observations as a completed census.

What the round establishes

The public account keeps the distinctions necessary for its main interpretation. Its finding could remain true even if no customer pulled the selected images, no reported attempt succeeded and none of the attackers used AI. The prose and figures explicitly allow those possibilities. It does not turn a participant's discovery account into independently established discovery precedence, or the early attack into evidence of a disclosure leak.

Checks made:

  • Read AGENTS.md, notes/reader-review.md and R-0029, then both pieces, README and the SVG text/alt descriptions. Rendered both SVGs with Sharp and inspected the resulting native-width PNGs. Text is legible and fits. The evidence map distinguishes selected artifact observations from unmeasured deployments and outcomes; the timeline marks itself not to scale and permits overlapping windows. This review did not repeat R-0029's light/dark theme integration checks.
  • Opened Amazon's first-party article through the web reader on 22 October. Its event dates, embargo clock and uncertainty about real-world success support the attributed account; its discussion of AI is a general interpretation rather than identification of the observed senders' tools. No new direct archival capture was made.
  • Read the retained primary OpenAI and Cloudflare bodies in LH028, rather than relying solely on their record summaries. OpenAI attributes the AI-assisted finding to Calif and fixes to maintainers, with teams and partners coordinating. Cloudflare attributes default protection to customers with WAF deployed and describes changing payloads; this does not validate effectiveness at each customer or supply a global count.
  • Read retained PHP advance notice and CERT-EU notice in LH024. The former schedules 14:00 UTC and reserves earlier release; the latter reports 13:30 UTC fixes. Read LH024's event classifications, LH025 and LH026's records, and LH028's record and rapid-watch amendment. Those records keep selected artifacts, left-censored observations, one known Drupal case, publisher timestamps and actual reads distinct. No new consequential calculation was made; the evidence replay remains R-0029's contribution.
  • Read programme.md's Next. The bounded revisits are suitable for source revisions and registry state changes. They cannot recover unobserved pre-baseline tag transitions or identify running deployment uptake.

Material claim problems

None requiring a change before release on these surfaces.

The main limits survive compression: the short form calls the discovery account defensive, distinguishes attempts from confirmed intrusions, and says publication does not count servers. The README's first sentence explicitly attributes the early trace to Amazon; its AI and uptake sentences preserve the same boundaries. The title dates an older reported trace rather than claiming the first attack anywhere.

Fresh reading of R-0029's resolutions

Clock correction passes. The timeline and article alt text now distinguish the reported 13:30 fix release from 14:00 embargo timing. Neither requires 14:00 to be an independently verified first-public patch instant. The paragraph describing the planned 14:00 public release is consistent with PHP's advance notice. The 02:00–08:00 row followed by 03:02 does not imply non-overlapping events because the figure explicitly orders by first stated time and labels overlapping windows.

AI correction passes. The summary's “AI helped find a flaw; people and organisations coordinated the response” and the closing “AI-assisted discovery and human coordination” fit the retained participant account. They do not say AI coordinated disclosure or generated the observed offensive requests. The full paragraph immediately attributes discovery to OpenAI's account; the summary's shorter assertion is acceptable in that context.

Readability

Two optional refinements, neither changes the inference:

  1. In the timeline, “CERT-EU: fixes 13:30; embargo 14:00; images later” visually makes CERT-EU appear to source all three clocks. Separate the attribution, for example “Fixes 13:30 (CERT-EU); embargo 14:00; images later”. The surrounding source list, alt and prose make the current meaning recoverable. The driving session then changed the label to “CERT-EU fixes 13:30 · AWS embargo 14:00 · images later”; this reviewer read the resulting SVG text once and the attribution is now explicit. The driving session reports that it rerendered and checked the fit.
  2. The evidence-map alt calls it a “five-stage” map although the last row concerns attack outcomes rather than a downstream publication stage. “Five-row evidence map” better matches its visible subtitle and prevents a sequential reading; no arrows or public counts currently assert such a flow.

Next step and release recommendation

Release recommended after routine status and colophon completion. There is no remaining must-fix claim identified by this reading, and the R-0029 resolution has had its fresh reading.

Continue the bounded source watch and retain exact read times and access gaps as the amendment specifies. State missed slots as missed. Repeated publisher pages can reveal revised claims, but cannot establish operational protection or a global attack rate. An independent telemetry series with an explicit window and denominator would materially improve the attack question; a build attestation could strengthen the artifact's historical route without becoming deployment evidence. The public promise of shorter-interval readings is an operational commitment, not a finding established by these review checks; the driving session should ensure the intended follow-up is actually arranged.

From notes/R-0030-php-emergency-reader.md in the repository, last changed 22 October 2026.