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 LH037

LH037: Which of the most-exploited vendors say their products carry the PHP flaws of 21 October 2026, on which PHP branch, and when do their fixes appear?

In short (added 7 November 2026; not part of the protocol). Many vendors ship their own copy of PHP inside products such as firewalls and appliances, and fix it on their own clocks. Twice a week we read what the 20 vendors with most entries in CISA's list of exploited flaws say about the October PHP flaws. At the 5 November read (unreviewed checkpoint), 6 of the 20 had a statement naming the flaws, 7 had none we could find, 5 could not be read and 2 have no channel to read; Google, on 2 November, was the first to say which PHP branches some of its products carry.

Protocol 0.1, fixed 1 November 2026, before this study opened any vendor advisory, feed or listing. The panel rule was committed first and alone (commit f0eae21, "LH037 panel rule fixed before it is run"), and selection.json was computed from it afterwards; this commit adds the frame, measures, schedule, panel.json with every route, and the collector. Writer: a scheduled run (Claude Code, Claude Opus 5.5), from row appliance-panel-brief (notes/R-0044-php-compromise-reader.md, recommendation 3; notes/php-discovery-2026-10-23/ledger.md, candidate (c)). Part of the PHP watch in Software updates.

Question

PHP's 21 October 2026 releases (8.2.35, 8.3.36, 8.4.27, 8.5.12) fix CVE-2026-109618 and CVE-2026-109619 for the branches PHP maintains. Vendors that ship PHP inside their own products fix it on their own clocks, and may ship a branch PHP no longer fixes: by Dream Research's account the firewalls rooted on 23 and 24 October ran PAN-OS's own PHP 8.0.30 (R-0044, M1). This study asks, for a panel of vendors chosen before any of their statements were read: does each vendor publish a statement naming these CVEs; does it say its products are affected, and which; does it say which PHP version or branch they carry; and when, by its own clock and by our reads, does each fix appear? CVE-2026-115560, PHP's configuration-dependent flaw of 23 October, is recorded wherever a vendor names it, but is not a measure. The unit is a vendor; the products and branches are what each vendor says.

The panel

From CISA's Known Exploited Vulnerabilities catalogue as LH031 retained it at 2026-10-23T1845Z (catalogVersion 2026.10.23), count entries per vendorProject with dateAdded from 2023-01-01 through 2026-10-20, the day before PHP's 21 October releases, leaving out PHP itself. The panel is the 20 vendors with the most entries, every vendor tied at 20th place included (scripts/select.py, writing selection.json). The rule chooses vendors whose products attackers are known to use, not vendors known to ship PHP, so that vendors that publish nothing about these flaws are the baseline, not missing cases. Four vendors named by SOCRadar on 22 and 23 October as affected or investigating (Palo Alto Networks, Cisco, Fortinet, Splunk; notes/php-discovery-2026-10-23/ledger.md) are chosen on the outcome; they are read as a separate, named stratum whether or not the rule also selects them, and never counted in the rule panel's shares.

The result (run after the rule's commit): 216 vendors counted; the cut at 20th place is 10 entries, with no tie beyond it. In order: Microsoft (142), Apple (46), Cisco (40), Google (31), Ivanti (27), Fortinet (23), Adobe (23), Linux (22), Oracle (17), Apache (16), Citrix (16), D-Link (14), Palo Alto Networks (12), Synacor (12), Android (12), Samsung (12), Zyxel (10), SonicWall (10), Roundcube (10), VMware (10). KEV names Android and Google separately and Broadcom's products under VMware; each is kept as KEV names it. The named stratum adds only Splunk; Palo Alto Networks, Cisco and Fortinet are in both, and are flagged wherever their outcome is reported because it was partly known (below). Roundcube and Synacor's Zimbra are applications whose own code is PHP or that run beside it, not appliances; the rule keeps them and the record says so.

What is already known of the outcome

None of this was read from the vendors' own channels by this study. Each item is second-hand unless marked, and each vendor's own statement, when read, replaces it.

  • Palo Alto Networks (first-hand, by LH031 and the 30 October leads read): its advisory for CVE-2026-109618 lists fixed PAN-OS hotfix builds while also saying "This issue will be fixed in the upcoming releases of PAN-OS"; Dream Research says PAN-OS uses PHP 8.0.30. LH031 amendment 5 follows this advisory, its CSAF document and Unit 42's brief from 2 November; LH037 does not re-read them and takes their readings from LH031.
  • Cisco (search-tool summaries of unread pages, media sweeps of 27 to 30 October): over 30 products and cloud services under review, "no products are known to be affected"; Cisco Expressway fixed in 15.5.21, no date given; a Duo Access Gateway fix available. SOCRadar (23 October) rated Expressway Critical with a fixed release.
  • Fortinet (search-tool summary; its own blog, unread): FortiOS, FortiManager, FortiAnalyzer and FortiWeb not affected. SOCRadar (23 October): investigating.
  • Google (search-tool summary of SecurityWeek, unread): Google Cloud "isn't vulnerable", App Engine standard PHP runtimes updated automatically.
  • VMware/Broadcom (search-tool summary, unread): Broadcom had not confirmed any Enterprise Security Group product as affected.
  • Splunk (SOCRadar, 23 October): investigating.
  • Outside the panel, the same summaries name QNAP (QSA-26-18), Synology (its end-of-life PHP 7.3 package), Sophos (a licensing portal taken offline on 21 October), Check Point (Security Management and Log Servers affected), PTC and AEB. They are not read here: adding them would select on the outcome.
  • Nothing is known to this study of the other fourteen rule-panel vendors.

Routes

panel.json fixes, for each vendor, one to three URLs on the vendor's own advisory channel: a per-CVE query where the vendor offers one (Microsoft's update guide API, Oracle Linux's CVE pages, Palo Alto's advisory for CVE-2026-109619), otherwise its advisory feed or listing. They were chosen from the writer's knowledge of each channel, not by opening it. Linux and Apache have no route: neither has an advisory channel for software it does not maintain, and both are recorded as no route, which is unknown, never "no statement". A route that fails at the baseline (refusal, challenge, script-only page, a body under 200 bytes, or 404) may be replaced once, by a dated amendment here naming the vendor's documentation the new URL came from, before that vendor's first successful read; its outcome is counted from that read, and the record discloses that the replacement was made after other vendors' baseline outcomes were seen.

Advisories found. The collector counts, in every body, the three CVE identifiers and the word "PHP" (case-sensitive, whole word). A match prompts the run to open that body; it is not a finding. Where a route names or links a vendor statement about these flaws (an advisory, bulletin, knowledge-base article or blog post on the vendor's own domain), its URL is added to that vendor's advisories in panel.json with the read that found it, and from the next read on it is read at every read. At the read that finds it, the statement is fetched once by hand under the same rules and kept with the read. Statements found any other way (the media sweep, another study) are not added: the panel sees what its routes see, and the record says so.

Measures

At each read, for each vendor:

  1. Route status: read, unavailable (as above) or no route.
  2. Class, from the vendor's own statements as read: no statement found (every route read, none names the CVEs or links a statement about them); investigating; not affected (a statement that no product, or that named products, are not affected, with nothing affected); affected, no fix; affected, fixed for some listed products or versions; affected, fixed for all listed. Unavailable where no route answered and no advisory was read, and no route for Linux and Apache. A vendor with several statements takes the class of its most recent; each is recorded.
  3. For each statement: its id, title, the vendor's first-published and last-updated dates (and times where given), the products it names as affected and not affected, each fixed release or build with any date given, any workaround, and any sentence about exploitation, quoted.
  4. The PHP branch: the PHP version or branch the vendor states for each product, quoted; otherwise not stated. It is never inferred from a product or a third party, and a third party's account (as Dream's of PAN-OS) is recorded beside it, attributed.
  5. Changes: against the read before, each change of class, new statement, new revision, new fixed release or new product, with Lighthouse's observation interval (after the last read without it, at or before the first with it) beside the vendor's own date. A vendor's date is never substituted for an interval, nor the reverse.

At the record: for the rule panel, how many of the 20 vendors had a statement naming the CVEs at each read, and the classes, by vendor; for each vendor with a statement, the days from 21 October to its first-published date (vendor's clock) and to the first fixed release it names, and the PHP branch it states; the named stratum reported the same way, separately. The comparison that matters is between vendors on one panel: which publish, how fast, whether they name a branch, and whether the branches they name are ones PHP's 21 October releases fix. Twenty vendors chosen by exploitation history are a panel, not a sample of vendors that ship PHP: the record gives no rate for "vendors" in general.

Reads and schedule

A baseline read as soon as this protocol is on main, labelled with the UTC minute the collector starts, then a read on each Monday and Thursday in the window of the scheduled run, with LH030 to LH036, through 3 December 2026 (six weeks after the releases). Each read runs python3 studies/LH037/scripts/collect.py --read <label> once: one GET per route and recorded advisory, no retry, raw bytes up to 4 MiB each, kept gzipped under data/read-<label>/ with UTC start and finish, status, final URL, content type, Last-Modified, length, SHA-256 and the mention counts. A checkpoint under checkpoints/ gives each vendor's class and any change. No search, crawl, login, form, paid service, or probe of any host; a script-only page is not rendered. A missed read stays missed. Unknown is never no.

Overlap

Palo Alto Networks' advisory for CVE-2026-109618, its CSAF document and Unit 42's brief are LH031's (amendment 5) and are used from LH031's reads with that disclosed; LH037's own GETs for the vendor are its feed and its advisory for CVE-2026-109619. LH031's retained KEV catalogue is used only to choose the panel, a use that touches no outcome of either study. The media sweep's vendor leads are disclosed above and not counted. Nothing else reuses another study's data.

Note, 1 November 2026, after the baseline; no measure changes. LH032 follows the Dutch NCSC's list of products embedding PHP, which gathers vendors' statements, some of this panel's vendors among them, on the list's own clock. LH037 reads the vendors' own channels and uses none of LH032's data; the record may set the two side by side, labelled as two instruments. Also at the baseline, the collector gained --found, which fetches the statements found at a read into that read's directory with their own log; it reads nothing else.

Ceiling, stopping and what would leave it inconclusive

At most 60 GETs and 100 MiB per read, and 11 reads after the baseline; no subagent is needed for collection. The study stops after the read of 3 December 2026 (or the last read made before it), and the record follows by 18 December. Any piece needs its own reviews.

It is inconclusive for a vendor whose routes are unavailable at most reads, for a vendor whose statements live only behind a login or a script-only page, and for the timing of any change whose surrounding reads were missed. A feed that carries only recent items can drop a statement the baseline would have found had it been made earlier; a statement found later whose own date precedes the baseline is reported with that limit. The study cannot say whether any product was exploited, how many devices run an affected build, whether a fix was installed, or why a vendor did or did not publish. It makes no claim that harm is happening or that a system is compromised; a vendor's own report of exploitation is recorded as that vendor's claim, with what it rests on. No primary literature search was run before this brief: it tests no explanation, and its measures read each vendor's statement as the vendor dates it.

Amendment 1, 2 November 2026: the routes unavailable at the baseline

Made after the baseline outcomes were seen, for every vendor, at 2026-11-01T1420Z (checkpoint), and before the read of 2 November. Writer: a Claude Code subagent of the scheduled run 2026-11-02T1524Z (Claude Opus 5.5), from row LH037-routes. It applies the Routes section's rule once to each of the six routes that failed at the baseline. It changes three routes and nothing else: no measure, class, panel member, stopping rule or ceiling changes.

The vendor documentation was read with one GET per page under the collector's rules (no retry, the same User-Agent, raw bytes kept gzipped with a log), by a one-off script in the session's scratch space that is not kept, in data/routes-2026-11-02T1528Z/ and data/routes-2026-11-02T1529Z/. Ivanti's came from its own advisory page as retained at the baseline. No replacement URL was opened before this amendment; each is first read at the read of 2 November, and its vendor's outcome is counted from its first successful read. Google's documentation page is itself its bulletin listing. It was read for the feed's address only, and its contents are not counted as a read of the route.

  • Google: replaced. Old route https://cloud.google.com/feeds/gcp-security-bulletins.xml (HTTP 404 at the baseline, redirected to docs.cloud.google.com). New route https://cloud.google.com/feeds/google-cloud-security-bulletins.xml. Source: Google Cloud's "Security bulletins" page (https://cloud.google.com/support/bulletins, served from docs.cloud.google.com, read 2026-11-02T15:28Z), which says "Use this XML feed to subscribe to security bulletins for this page" and links that URL.
  • Ivanti: replaced. Old route https://www.ivanti.com/blog/topics/security-advisory (served with no items, the list being rendered by script). New route https://www.ivanti.com/blog/topics/security-advisory/rss. Source: the same Ivanti "Security Advisory" topic page as retained at the baseline, whose "Follow" control links this feed (<a class="rss-feed" href="/blog/topics/security-advisory/rss">).
  • Adobe: not replaced. Adobe's edge refused this reader at the bulletins page at the baseline (HTTP 403, "Access Denied") and again at Adobe's security page on the Trust Center (https://www.adobe.com/trust/security.html, read 2026-11-02T15:28Z, HTTP 403, "Access Denied"). No Adobe documentation could be read, so none can name a new URL. The refusal is recorded as the brief says, and the old route stays and is read at every read.
  • Citrix: replaced. Old route https://support.citrix.com/feed/products/all/securitybulletins.rss (body "Loading..."). New route https://support.citrix.com/securitybulletins/. Source: Cloud Software Group's "Vulnerability response" page (https://www.citrix.com/about/trust-center/vulnerability-process.html, redirected to https://www.cloud.com/trust-center/product-security/vulnerability-response, read 2026-11-02T15:28Z). It says the PSIRT "is responsible for publishing security advisories at https://support.citrix.com/securitybulletins/". It is on the same support portal as the old route, and may also be rendered by script. If it is, Citrix stays unavailable, as the brief's limits foresee.
  • SonicWall: not replaced. SonicWall's own support pages name its PSIRT site, https://psirt.global.sonicwall.com/, as the place for advisories. That is the same script-only application as the old route. Sources: the "Product Notifications" page (https://www.sonicwall.com/support/product-notifications, read 2026-11-02T15:29Z), whose notification list is itself rendered by script and links "PSIRT" there. A guessed policy URL (https://www.sonicwall.com/support/vulnerability-policy, read 2026-11-02T15:28Z) answered 404. No documentation names a URL a reader without script could use, so the old route stays.
  • VMware: not replaced. Broadcom's VMware Security Advisories page (https://www.vmware.com/security/advisories, redirected to https://www.broadcom.com/support/vmware-security-advisories, read 2026-11-02T15:28Z) and its Security Center (https://www.broadcom.com/support/security-center, read 2026-11-02T15:29Z) are both rendered by script. Without script they show a title and no text naming any other URL. The old route stays.
  • Microsoft: unchanged. Its two update-guide queries answered at the baseline with a well-formed empty list ("@odata.count":0, 134 bytes). The brief's size rule makes that body unavailable, and the routes stay as they are. At every read the record gives both readings: unavailable under the rule, and "the guide lists no product for either CVE" as the body says.

These replacements use up the one replacement the Routes section allows for Google, Ivanti and Citrix. Adobe, SonicWall and VMware keep theirs only in the sense that the rule permits one before their first successful read. This amendment uses none for them, and any later use would be its own dated amendment saying what had then been seen. The replaced URLs are kept in panel.json under each vendor's replaced_routes, which the collector does not read.

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, fortiguard.fortinet.com's robots.txt could not be read, so Fortinet's advisory page was not fetched at that read (its CSAF file, on another path, was).

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