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 LH031

LH031: When, if ever, does CISA's catalogue of known exploited vulnerabilities list the October 2026 PHP flaws?

Protocol 0.1, fixed 23 October 2026, before this study's first read of the catalogue. Writer: a Claude Code driving session (Claude Opus 5.5). A candidate from the PHP discovery pass (notes/php-discovery-2026-10-23/ledger.md).

Question and unit

For CVE-2026-109618, CVE-2026-109619 and CVE-2026-115560, does CISA's Known Exploited Vulnerabilities catalogue list each, and if so with what dateAdded, dueDate, knownRansomwareCampaignUse, requiredAction and notes? The unit is one CVE at one read. The catalogue is an agency's classification: an entry says CISA judged there to be reliable evidence of exploitation, by its own criteria; it is not a count of attacks, a measure of compromise or a statement about any named system, and an absence is not evidence that no exploitation occurred.

What is already known of the outcome

SOCRadar's page, read on 23 October at 17:08 UTC (notes/php-discovery-2026-10-23/pages/socradar.raw), says that as of 23 October neither of the first two CVEs is in the catalogue and that CISA said on 21 October it had not observed exploitation. Two search-tool summaries on 23 October said the same, without a source opened. No read of the catalogue itself has been made. CISA's alert page refused this container's direct reader on 22 and 23 October (HTTP 403, LH024).

Reads

One GET per read of CISA's published feed, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. If it refuses or returns something that is not the catalogue, one GET of CISA's own mirror of the same data, https://raw.githubusercontent.com/cisagov/kev-data/main/known_exploited_vulnerabilities.json, recorded as the mirror, never merged with the first as if they were one source. Retain the raw body up to 16 MiB with UTC times, status and SHA-256, and extract the feed's catalogVersion, dateReleased, count and the three CVEs' entries if present. Schedule: a first read on 23 October, then once a UTC day through 30 October alongside LH030, then on LH030's Monday and Thursday reads until 30 November 2026. A missed read stays missed. No search, login, paid service or contact.

Clocks and comparison

An entry's dateAdded is CISA's date (a day, not a time); the feed's dateReleased is its own clock; Lighthouse's first read showing an entry bounds its appearance from our side. Never substitute one for another. The comparison: which of the three is added, on which date relative to PHP's notices (20, 21 and 23 October) and to the first public exploitation claims (Amazon, Cloudflare; LH028), stated as a sequence of differently sourced clocks, not as a delay to be generalised.

Stopping and inconclusive

Stop at 30 November 2026. Inconclusive if both addresses refuse at most reads. Spend: about two requests a read; model spend in the close-out.

Amendment 1, 24 October 2026, 07:44 UTC, after two reads 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 3, 30 October 2026, 11:48 UTC (commit 7a5dbc4), fixed before the read it describes. From notes/R-0036-php-cisa-reader.md (its "next step"), carried as a candidate by the continuation plan and scheduled as row LH031-criteria. The writer knows the entries' notes cite CISA's 21 October alert and two BOD 26-04 pages, and that the reviewer recalled, from background knowledge and no retained source, that CISA's criteria as published before June 2026 counted attempted exploitation, honeypot hits included; neither page below has been read by Lighthouse. Question: what does CISA publish as the condition for an entry, and does its 21 October alert state whether exploitation had been observed? Reads: one direct GET each, no retry, raw bytes up to 2 MiB with UTC times, status and SHA-256, by scripts/criteria.py, of (1) CISA's catalogue page, https://www.cisa.gov/known-exploited-vulnerabilities, which has carried the published criteria; (2) the alert the entries cite, https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching; (3) the BOD 26-04 implementation guidance the entries cite, https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk, in case the criteria have moved there. If a page refuses (cisa.gov's pages refused this container on 22 and 23 October, LH024, LH030), one request through the session's web-fetch tool, recorded as a different reader whose text is a model's rendering of the page, not its bytes, and never merged with a direct read. Classes: for the criteria, the stated condition quoted, and whether it names attempted exploitation or honeypots, classed stated, not stated on the page read, or unread; for the alert, its date and any sentence on observed exploitation, quoted, classed the same way. Use: a stated criterion describes what an entry may rest on; it does not say what these two entries rest on, which the feed does not state. If every reader refuses, the wording of R-0036 M1 stands and the read is recorded as failed. No search, login or contact. Ceiling: three direct GETs and at most three web-fetch requests.

Amendment 4, 30 October 2026, about 11:58 UTC, after the reads of 28 and 29 October had been seen. The 28 and 29 October log called two additions "unrelated" when one, CVE-2026-46300, names the PHP CVEs in its description (correction in checkpoints/2026-10-30.md). From the next read, collect.py also writes to result.json a mentions list: each entry outside the three whose text contains "PHP" or one of the three CVE IDs, with its cveID, dateAdded and shortDescription. Each checkpoint names them. This is an addition to what is reported. No class, frame or schedule changes, and no earlier read is re-classified.

Amendment 5, 30 October 2026, about 14:40 UTC, fixed before the first read it describes. From notes/R-0044-php-compromise-reader.md (its "next step", recommendation 2), scheduled as row PANW-reread-amendment. The writer has read Palo Alto Networks' advisory for CVE-2026-109618 and Unit 42's threat brief as kept by the php-leads read of 30 October (the advisory at 11:51:11 UTC, the brief at 11:50:54 UTC; notes/php-leads-2026-10-30/pages/panw-advisory.raw and unit42.raw); those copies are this amendment's baseline and are not re-read. The advisory's CSAF document has not been read. Question: on the Monday and Thursday reads, does Palo Alto Networks change what it says about fixed PAN-OS builds or about exploitation, and when? R-0044 M1 found the 29 October advisory both lists fixed hotfix builds ("Upgrade to 12.2.4-h1 or later", and so on) and says "This issue will be fixed in the upcoming releases of PAN-OS", while Unit 42 says "Customers who have applied the available patches are not affected"; whether fixed builds existed when Dream Research says the firewalls were rooted (23 and 24 October) is unsettled. Reads: on each LH031 Monday and Thursday read from 2 November through 30 November 2026, scripts/vendor.py --read <label> makes one direct GET each, no retry, raw bytes up to 2 MiB with UTC times, status and SHA-256, of (1) the advisory, https://security.paloaltonetworks.com/CVE-2026-109618; (2) its CSAF document, https://security.paloaltonetworks.com/csaf/CVE-2026-109618, linked from the advisory page; (3) Unit 42's brief, https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/. Each read is kept in data/vendor-<label>/, separate from the catalogue read. Extracted (result.json): from the advisory, its "Published" and "Updated" dates, "Exploit Maturity", the set of fixed builds in its product table (>= entries) and in its solution table ("Upgrade to"), any "previously impacted" sentence, and the presence of three sentences (the "will be fixed in the upcoming releases" sentence, "Until PAN-OS fix versions are available", "Active exploitation has been observed"); from the CSAF, its tracking version, initial and current release dates, revision history, fixed product IDs and remediations with their dates; from Unit 42, its title, "Published" date, its "Update <date>" headings and the presence of four sentences (actively exploited, independently verified, patched customers not affected, approximately .02 per cent impacted). Classes, per read and against the read before (the baseline for the first): for fixed builds, unchanged, added, removed; for the "will be fixed" sentence, present or absent, and its first read absent dates its removal from our side; for each exploitation sentence, unchanged, added, removed or reworded (a sentence absent with its topic still discussed is quoted in the checkpoint); a new update heading or revision entry is quoted with its date. A CSAF revision date is the vendor's clock; our first read showing a change bounds it from our side; never substitute one for the other. Use: these readings date the vendor's own statements; they do not show when a build was released to customers, whether any system was patched, or that any system was compromised, and Lighthouse makes no claim of compromise from them. A change to what the vendor says about exploitation or fixes is flagged for review, since it bears on the PHP account's version 1.3. A refusal is recorded as a failed read of that source and nothing else. No search, login or contact. Ceiling: three GETs a read. The appliance-vendor panel from notes/php-discovery-2026-10-23/ is not part of this study (a different unit: which PHP branch each vendor ships and when each fix appears); it is weighed in row appliance-panel-brief of schedule/due.csv.

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 collectors (collect.py, criteria.py, vendor.py) 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 URL was allowed.

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