LH038: When was CVE-2026-98432 reported, fixed, numbered, shipped and described, and how do those dates sit beside the disclosure policies each party states?
In short (added 7 November 2026; not part of the protocol). When an AI model finds a serious flaw, how do the dates of its public life line up with the disclosure rules the parties say they follow? For the same kernel flaw, we'll build a dated timeline from public sources (report, fix, CVE, distribution advisories, Anthropic's post) and set it beside six published disclosure policies. One read from 17 November; the record by 30 November.
Protocol 0.1, fixed 4 November 2026, before this study read any source about the timeline of CVE-2026-98432. Writer: a scheduled run (Claude Code, Claude Opus 5.5), from row disclosure-timeline-brief, question 2 of the investigation When a model finds the bug. The disclosure policies the comparison uses were read first, on 4 November between 14:15 and 14:17 UTC, and are kept under data/ with their read script and list; they say nothing about this CVE. The frame, the panel of fixed URLs and the collector are committed with this brief.
Question
CVE-2026-98432 is a use-after-free in the Linux kernel's handling of IPv4 TCP connection requests, published by the kernel's CVE team on 15 October 2026 with fixes in every maintained stable branch. On 27 October Anthropic described an exploit its model wrote for it. From public primary sources only: on what date, by each source's own clock, did each step of the flaw's public life happen (report, fix, CVE, stable releases, distribution advisories, Anthropic's post, downstream notices), and how many days separate those dates from the intervals each party's published disclosure policy states? The unit is a dated event, each with its source; the case is one CVE, and nothing here generalises to other flaws or other finders.
Model disclosure
The exploit and the post are Anthropic's, and every agent that writes or reviews for Lighthouse in this study runs on an Anthropic model. The keeper chose disclosure over a reviewer from another provider, for now (1 November 2026). Every record and piece from this study states this beside its model line, and its reviews are asked to look specifically for wording that is easier on Anthropic, or harder on it, than the sources allow. This study lays dates beside policies; it does not judge whether anyone kept to a policy or acted rightly (the investigation's rule), and a reading of that kind belongs in an essay, argued openly.
What is already known of the outcome
The writer had read LH036's brief, which lists what a driving session read on 1 November 2026 before that study existed, and nothing of LH036's later reads or checkpoints. From that list: the CVE record shows the identifier reserved on 2026-09-25 and published 2026-10-15T12:08:22Z by the Linux CNA, with a CNA container updated 2026-10-24T14:08:46Z carrying CVSS 3.1 9.8; its references are eight kernel commits; fixed versions 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Anthropic's post gives datePublished 2026-10-27 and dateModified 2026-10-30T15:24:16Z and says the bug "was patched upstream and backported to all maintained stable kernel branches". Go's security team posted on 29 October (16:34 PDT); AlmaLinux posted on 30 October; three oss-security posts are dated 30 and 31 October. Debian lists DSA-6568-1, DLA-4841-1 and DLA-4850-1 as fixing advisories, without dates in that list. No source read so far gives the date the flaw was reported to anyone. The writer has not read the fix commits, the stable changelogs, the oss-security or linux-cve-announce archives, any advisory's text, or any archive of the post.
The policies, as read on 4 November 2026
Each policy is quoted from the retained page; a policy's text on the date it would have applied is known only where the page or an archive dates it, and the record will say which.
- P1, Anthropic, "Coordinated vulnerability disclosure for Claude-discovered vulnerabilities" (page "Last updated Mar 6, 2026"; read 14:15 UTC). Aims "to share details publicly with defenders after 90 days, or after a patch is released, whichever comes first"; a 14-day extension "may" be granted; for actively exploited critical flaws a 7-day target. "Once a patch is available, we would generally wait 45 days before publishing full technical details", a buffer that may be shortened "if the details are already publicly known through other channels, or if earlier publication would materially help defenders", or extended. Reports from AI-powered discovery "are clearly labeled as such". The post of 27 October words the same policy differently: "gives developers 90 days to patch and a further 45 days before we discuss details beyond what is already included in a public advisory". Both wordings are recorded; this study does not choose between them.
- P2, the Linux kernel's "Security bugs" (docs.kernel.org rendering,
Last-Modified1 November 2026; read 14:16 UTC; git.kernel.org's plain text answered with a bot challenge at 14:15 and is unavailable). Fixes for publicly known bugs "are released immediately"; for undisclosed bugs, release "may be postponed at the request of the reporter or an affected party for up to 7 calendar days from the start of the release process", exceptionally 14. "If you resorted to AI assistance to identify a bug, you must treat it as public", and a reproducer is not shared publicly. Reporters should not contact linux-distros until a fix is accepted. The security team does not assign CVEs. Working exploits "will not be released without consent from the reporter". The page as read is the current mainline text; its text on the report date is not known until its history is read (panel,kernel_security_bugs_history). - P3, the kernel's "CVEs" (same read). CVEs are assigned "after a fix is available and applied to a stable kernel tree" and announced on linux-cve-announce; an identifier can be reserved earlier on request to cve@kernel.org.
- P4, the linux-distros list (Openwall wiki; read 14:15 UTC). For kernel issues, "notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security"; a maximum embargo of 14 days from the post to the list, under 7 preferred; a fix in a public repository generally makes an issue public, with an exception granted for kernel issues the kernel security team is handling; the reporter must post to oss-security when the issue is public, and may delay exploits by 1 to 30 days.
- P5, Ubuntu's disclosure and embargo policy (read 14:15 UTC). Canonical would "like exploits and proof of concept exploits to be held private for at least one week after fixes are published".
- P6, Debian's vulnerability disclosure policy (
Last-Modified2 November 2026; read 14:17 UTC). Notes the distros list's two-week limit on embargoes.
Not read: Red Hat's, SUSE's and Go's policies, Google's and others' policies for the other four chains (question 3's), and the kernel's "embargoed hardware issues" page beyond retaining it (it concerns hardware flaws).
Events and how each is dated
Each event is recorded with its source's own date and time zone, the URL and the read that showed it. Where several clocks exist they are all kept and none substituted.
- T0, report. Unknown unless a public primary source states a date (a post, an advisory, a commit trailer that carries a date, an oss-security message). A commit's author date is not a report date, and no bound on the report is inferred from it; the CVE reservation (T2) is not a report date either.
- T1, fix. The upstream commit's author date and committer date; the first mainline release that contains it, by its changelog.
- T2, CVE reserved, 2026-09-25, from the CVE record (already known; recorded, not interpreted).
- T3, CVE published, 2026-10-15T12:08:22Z (CVE record), and the linux-cve-announce message's date where readable.
- T4, stable releases. For each of the eight fixed versions: the release date its kernel.org changelog gives, and the stable commit's dates.
- T5, distribution advisories. Each advisory named by Debian, Ubuntu, Red Hat or SUSE for this CVE: its own date. The trackers themselves are read by LH036, and this study takes their advisory lists from LH036's read of 16 November (reuse, disclosed below), following each advisory URL once.
- T6, Anthropic's post. datePublished 27 October (a day without a time), dateModified, and the earliest Wayback Machine capture as an outside bound on when it was public.
- T7, list and downstream notices. Every oss-security message for September to November 2026 whose subject names the CVE or the flaw (the month indexes are read whole and their subjects matched by the rule below); Go's and AlmaLinux's notices; and whether Openwall's linux-distros statistics list the issue, which would show the list was used and when.
Comparison
For every pair that a policy speaks to, the record gives the elapsed days, computed in UTC calendar days and shown as code and output: T1 and T4 (each clock) to T6, against P1's 45 days in both its wordings, and against 90 days; T0 to T1 and T0 to T6, where T0 is known; T1 to T3; the first stable release to each T5; any linux-distros embargo against P4's 14 days; T6 against P5's one week from fixes, noting whether the post carries an exploit or proof of concept (as read, it carries neither, by LH036's brief). Where a policy's clock is ambiguous (P1's "a patch is available" could be T1, the first stable release or a distribution's fix; "full technical details" is not defined), the record computes against each candidate and does not pick one, and quotes the post's technical content without classing it as "full" or not. The comparison is a description of dates; it makes no claim about intent, compliance, harm or exploitation, and none in Lighthouse's voice that the flaw is exploited.
Sources and reads
One timeline read with scripts/collect.py, in the window 17 to 23 November 2026, after LH036's read of 16 November, labelled with the UTC minute it starts. panel.json fixes 28 URLs: the eight commits, through GitHub's commit API (torvalds/linux for the upstream commit, gregkh/linux for the stable ones); the eight kernel.org changelogs; the oss-security month indexes for September, October and November 2026; Openwall's distros statistics page; a linux-cve-announce search on lore.kernel.org for the identifier; the three Debian advisories already named; Wayback Machine CDX listings for the post and for P1's page; the commit history of the kernel's security-bugs file; and the post itself. The follow rule, applied once before the read and kept as follow.json: every advisory URL named for this CVE in LH036's retained read of 16 November (Debian, Ubuntu, Red Hat, SUSE trackers; the CVE record's and OSV's references not already in the panel), and every oss-security message linked from the three month indexes whose subject contains CVE-2026-98432, MPTCP or multipath, up to 80 GETs in all. Raw bytes up to 4 MiB each, gzipped, with status, Last-Modified, length and SHA-256. No search engine, crawl beyond this rule, login, exploit or probe; nobody is contacted. A body under 200 bytes, a refusal or a bot challenge is unavailable; a 404 is no record; unknown is never no. If GitHub's API refuses, the commit dates are taken from the changelogs and the stable trees' commit pages are left unavailable; if lore.kernel.org refuses, T3's announcement time rests on the CVE record alone.
Overlap
LH036 reads the CVE record, NVD, OSV, EPSS, KEV, the four distribution trackers, the post, AlmaLinux's post and the kernel's announcement mbox twice a week; this study does not re-read those URLs except the post, once, and takes from LH036's 16 November read only the advisory lists, citing the read. No read is counted in both studies. The policies were read for this brief only.
Ceiling, stopping and what would leave it inconclusive
At most 80 GETs and 100 MiB in the one read, plus the policy reads already made; no subagent is needed for collection. The record follows the read, by 30 November 2026. It is revised once after LH036's stop (on or before 13 January 2027), by re-reading the follow rule's advisory lists from LH036's last read, so that later advisories join the timeline; that re-read follows advisory URLs not followed before and nothing else. Any piece needs its own reviews, including the model disclosure check.
The timeline is inconclusive for T0 if no public source dates the report, which is the expected outcome and is recorded as unknown, not as absent; for any event whose source is unavailable; and for P2's and P1's texts on the dates they would have applied, if no history dates them. It cannot say what was said privately between reporter, kernel and distributions, why any date fell where it did, or whether any party kept to its policy.
- Amendment, 8 November 2026, by the driving session of the keeper's review (in force from the next read; not retroactive). The keeper decided 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 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 is unreachable, is not fetched and is logged "not fetched" with the deciding group and rule, a missing reading and never a negative. git.kernel.org's robots.txt, as read on 8 November 2026 (studies/LH044, F01), disallows every path to
*and to ClaudeBot, so this study's git.kernel.org URLs are no longer fetched; whether that file said the same on this study's earlier read days was not checked, and those earlier requests are listed in the rules-of-the-road audit (studies/LH047). 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.
From studies/LH038/brief.md in the repository, last changed 8 November 2026.