2026-09-30T0634Z-audit

Verification & coverage notes

Operator-directed follow-up to the 2026-09-29 audit (2026-09-30): use WebFetch where it makes sense for the sources the container cannot read, change CLAUDE.md to match, cover the missing Apple CVE-2026-86950 entry, and repoint the four entries whose NCSC-CH citations had gone dead. Report: docs/audits/2026-09-30-quality-audit.md.

Fetch policy (v4.18). CLAUDE.md, both agent definitions, cti-run.md and quality-audit.md now sanction WebFetch for hosts the container is walled out of, as the fetch ladder's fourth rung ahead of the metered reader. cisa-kev, cisa csaf-recent and ncsc-csh stay on the bridge. v4.17's setup review, which landed on main during this run, had already moved the three records to fetch_method: webfetch, so this release aligns the rules and the health check with them. Tested before the change: WebFetch read the cisa.gov news listing and the cybersecurity-advisories listing with dates and item URLs, and the directives list with item URLs, and read an ssd-disclosure.com advisory page. An independent source-recipe pass (SR1) confirmed the three CISA recipes down to drilled pages. ssd-disclosure.com did not hold up: WebFetch read one of its advisory pages once, then SR1's 26 calls over 18 URLs returned 24 empty bodies and 2 replays of that cached read, and once the reader pool was refilled (about 07:40Z) the funded reader got the same SiteGround captcha on every try, so no transport reads SSD and it goes to fetch_method: blocked, a documented coverage gap served by WebSearch leads. source_health.py gives such records, when the container is actually walled out, the verdict webfetch-only (handled) instead of unreadable or needs-bridge, retries a walled, undated or failed-feed read up to twice before flagging it, and the Ops panel lists the webfetch-only records separately. A 404 or parked page is not a wall, so it still surfaces. Most of the 83 fetch_method: webfetch records predate extract and read cleanly with it, so the agents try extract first there.

Apple CVE-2026-86950. This run composed an entry from Apple's three security notes, the KEV record and three outlets, then found on syncing that the 2026-09-30T0404Z intel fire, which landed on main at about 06:45Z, had already published one (entries/2026-09-30/cve-2026-86950-apple-coregraphics-zero-day-kev.md) carrying the same facts plus CVSS and EPSS. This run's draft was dropped as a duplicate, with its registry and state rows, so the item is closed by the intel fire.

Repointed citations. Four June entries cited ncsc.admin.ch pages that now answer 404 after the agency's move to bacs.admin.ch. Each now cites the same page on bacs.admin.ch. Re-reading each page against its entry also found wording the page does not support (a "coordinated surge" of three reported cases, both scam variants tied to the Booking.com leak, mailbox forwarding rules the page never mentions, hardened hedges, a misnamed ZENDATA vector), so each change is a correction record with its own section. The week 22 and week 25 entries move from high to notable priority, since NCSC names no sector and no constituency exposure for either. Each record also adds the ATT&CK mapping, limited to what the page supports, and the Admiralty rating those pre-v3.18 entries lacked. The week 25 entry's spliced evidence quote is now verbatim quotations.

Registry. The names and summaries of campaign:ncsc-ch-jobseeker-targeting-2026 and incident:ncsc-ch-booking-hotel-phishing-2026 and the summaries of report:g7-evian-2026 and campaign:ncsc-ch-m365-voicemail-phishing-week25 follow the corrected entries, and the G7 and week 25 entries now link report:g7-evian-2026 and campaign:ncsc-ch-m365-voicemail-phishing-week25.

Sub-agent models. Recorded per sub-agent and verifier iteration above.