LH037 checkpoint: Monday read, 9 November 2026, 14:29 UTC

In short. Cisco now says a fix is available for every product it lists as affected by the October PHP flaws: its wireless backhaul software, which had a fix promised for November, was marked available on 6 November. No other vendor's statement changed in what we could read, and 6 of the 20 vendors still have a statement our reads reach. Two pages could not be read this time: Oracle's security-alerts feed and alert answered with an error page, and Fortinet's advisory page was not requested because its site's robots.txt could not be reached, so for both we don't know whether anything changed there. No vendor says its own products were exploited, and none newly names a PHP branch.

Protocol 0.1 with amendment 1 (2 November; Google's, Ivanti's and Citrix's routes replaced). Read data/read-2026-11-09T1429Z/: 34 log rows, 23 routes and the 11 statements recorded by 5 November, 14:29:30 to 14:30:05 UTC (read_log.json); 33 were requested and one was not (Fortinet's advisory page, below). This is the first read under the keeper's robots.txt rule of 8 November: collect.py now asks scripts/robots_gate.py through scripts/lh_fetch.py before each GET, sends the User-Agent "Mozilla/5.0 (compatible; Lighthouse-research/1.0; +https://lighthouse.harbour.cat)" (until 5 November, "Mozilla/5.0 (compatible; Lighthouse research observation)"), and withholds email addresses from the bodies it keeps. At the time of writing brief.md carries no dated amendment for this change; the run's robots sweep owns that. Every body with a CVE or PHP mention was opened and its text compared with the same body at the read of 5 November, 14:14 UTC (the three Google release-notes pages with their copies fetched by --found that day); bodies without a mention were compared too. "Identical bytes" below means the same SHA-256 of the bytes received. Nothing was added to panel.json and nothing was fetched by hand. Every statement below is the vendor's own, as read; nothing was checked against a product. Writer: a Claude Code subagent of the scheduled run of 9 November 2026 (run 2026-11-09T1417Z, Claude Opus 5.5); unreviewed.

Rule panel (20 vendors)

⚑ partly known before the brief (brief, "What is already known"): Cisco, Fortinet and Palo Alto Networks are also in the named stratum.

At this read: 6 of the 20 vendors had a statement naming the CVEs that their routes reached (Cisco, Fortinet, Google, Oracle, Palo Alto Networks, Zyxel). 7 had none found (Apple, Ivanti, D-Link, Synacor, Android, Samsung, Roundcube). 5 were unavailable (Microsoft by the size rule, Adobe by refusal, Citrix, SonicWall and VMware by script-rendered pages). 2 have no route (Linux, Apache). The counts are the same as on 2 and 5 November. Fortinet and Oracle each count as reached through the routes that did answer (Fortinet's feed and CSAF, Oracle's Linux pages); for each, one or two recorded bodies are a missing reading at this read. The one change of class is Cisco's.

Changes, measure 3

Cisco (rule panel and named stratum; class changed)

cisco-sa-php-october26-Jj384Daq, "Vulnerabilities in PHP Affecting Cisco Products: October 2026", Critical, first published 2026-10-21 19:12 GMT, now "Last Updated: 2026 November 6 14:21 GMT", "Version 1.11: Final". The revision history adds: "1.11 | Updated Ultra-Reliable Wireless Backhaul (URWB) and Unified Industrial Wireless Software as being available. | Affected Products | Final | 2026-NOV-06". The feed's item carries the same date and time (2026-11-06 14:21:13) and its text is unchanged.

• Affected, with the fixed release the table gives: Ultra-Reliable Wireless Backhaul and Unified Industrial Wireless Software (CSCwx37073): "26.2.1.9", where on 5 November it read "26.2.1.9 (Nov 2026)", an estimate. Expressway and Expressway Select (CSCwx37062): 15.5.21. Duo Access Gateway: 3.2.0. ISE Portal Builder: "Fix deployed, no customer action required." These three are unchanged. No date is given for when 26.2.1.9 was released, only the revision's date.
• Other changes: the page header now lists both CVEs and a "Download CSAF" link (not opened; a link from a recorded advisory, not from a route), and the action links add "Snort Rule 1:67375". The list of products confirmed not vulnerable is unchanged.
• Exploitation: unchanged: "The Cisco PSIRT is not aware of any malicious use of these vulnerabilities against any Cisco product."
• PHP branch: not stated.

Cisco's class: affected, fixed for all listed: every product the advisory lists as vulnerable now has a fixed release marked available or a deployed fix. Clocks. Vendor's clock: the last estimated fix marked available on 6 November (16 days after PHP's releases); the advisory first published 21 October (0 days). Lighthouse's clock: the change appeared after 2026-11-05T14:14Z (the read without it) and at or before 2026-11-09T14:29Z.

Oracle (rule panel; two bodies unreadable, class carried)

Both www.oracle.com routes answered HTTP 403 with 3,987 bytes: an HTML page titled "Technical Difficulties" that says "This site is experiencing a technical difficulty. We are aware of the issue and are working as quickly as possible to correct the problem", with an incident number. The two bodies differ only in that number. On 2 and 5 November both URLs answered 200 under the old User-Agent. The Oracle Linux pages, on linux.oracle.com, answered 200 under the new one, with text unchanged.

Why www.oracle.com answered this way is unknown. The changed User-Agent is one possible cause, as are an outage or an edge rule unrelated to this reader; the body names none of these, and a status 403 with a "technical difficulty" message does not settle it. The robots gate let both URLs through, which under scripts/robots_gate.py means that host's robots.txt answered with a status below 500 and did not disallow them; which status it gave is not in the read log. Under the brief this is a refusal at two bodies, not an absence: the alert said on 5 November that it "will continue to be updated as additional product patches become available", so a revision between the reads would not be seen. Oracle's class: affected, fixed for all listed, carried from its statements as last read (the alert at Rev 2, 26 October, read on 5 November; the Oracle Linux errata of 21 and 22 October, read today).

Fortinet (rule panel and named stratum; advisory page not requested, class carried)

The log row for fortinet__FG-IR-26-186 reads "NotFetched: not fetched: robots.txt unreachable; not fetched in this run (robots https://fortiguard.fortinet.com/robots.txt, status error ...)". "Status error" is the gate's word for a request for robots.txt that failed before any HTTP status came back; the underlying error is not recorded. Under the keeper's rule the page was therefore not requested, and its reading at this read is missing, never a negative. The CSAF (on filestore.fortinet.com, whose robots.txt the gate could read) is identical bytes to 5 November (current_release_date 2026-11-05, FortiSOAR and FortiSOAR PaaS versions as known_affected, 8.0.1, "upcoming 7.6.8" and "upcoming 7.5.5" as known_not_affected). The feed's PHP item is unchanged, including its sentence on CVE-2026-115560 ("No Fortinet product meets the conditions required for exploitation. Therefore, CVE-2026-115560 does not affect any Fortinet products."). That sentence was already in the feed item on 5 November, though the checkpoint of that day quoted it from the advisory page; it is not new. The feed's item still says "Revised on 2026-11-05", which suggests, but cannot show, that the page was not revised. Fortinet's class: affected, fixed for some, carried. If fortiguard.fortinet.com's robots.txt can be read at the next read, the page is read then as usual; no extra fetch is needed or made.

Named stratum

Flags

• Vendor statement of exploitation: none new at this read. No vendor read through LH037's routes says a product of its own was exploited. Cisco still says it "is not aware of any malicious use" against any Cisco product; Fortinet's feed and CSAF say no more than on 5 November, and its advisory page, with its "Known Exploited: No" field, was not read; Splunk's advisory is identical bytes. Palo Alto Networks' statement that "active exploitation has been observed" stays in LH031's record, which reads its advisory as unchanged on 9 November.
• Newly stated PHP branch: none.
• Class change: Cisco, affected, fixed for some → affected, fixed for all listed.
• Missing readings caused by the new rules or the new reader: Fortinet's advisory page (robots.txt unreachable) and Oracle's security-alerts feed and alert (HTTP 403, "Technical Difficulties"; cause unknown, possibly but not shown to be the changed User-Agent). Neither changes a class, and neither is read as "no change".
• For the run, not a finding: the gate's own requests for each host's robots.txt are GETs that do not appear in read_log.json, so the read's request count and the robots.txt status for each host are not in the record. A reviewer may want the collector to log them beside the read.
• Not checked: Cisco's CSAF and bug pages, and when 26.2.1.9 was released; Oracle's alert and its Patch Availability Documents; Fortinet's advisory page and its FortiSOAR patch pages; which PHP version any Cisco, Fortinet or Oracle product carries; Ivanti's community advisory portal; Palo Alto Networks' advisory, taken from LH031's checkpoint without re-reading.

For the commit message

LH037 read of 9 November, the first under the robots.txt rule: 6 of 20 vendors have a statement naming the CVEs, as on 2 and 5 November. One class changed: Cisco moved from affected, fixed for some to affected, fixed for all listed, its advisory version 1.11 of 6 November marking the wireless backhaul fix (26.2.1.9, an estimate "Nov 2026" until then) as available. Fortinet's advisory page was not requested because fortiguard.fortinet.com's robots.txt was unreachable, and Oracle's security-alerts feed and alert answered HTTP 403 with a "Technical Difficulties" page (cause unknown, the changed User-Agent among the possibilities): both are missing readings, and both vendors keep their classes from what was read. No vendor statement of exploitation and no newly stated PHP branch at this read; panel.json unchanged. Nothing found changes a claim in a public account: no released piece names Cisco, Fortinet or Oracle, so nothing is flagged for review.