2026-08-22T0410Z-intel

Verification & coverage notes

This run was overtaken, and eight of its sixteen verified entries were stood down at publish time rather than published. That is the single most important fact in this record, and everything below is scoped by it.

The fire opened at 2026-08-22T04:10Z, composed sixteen entries from twenty candidates across four surfacing passes, four scoped deep reads and one scoped recovery pass, took them through the mechanical gate and three verifier iterations, and reached its publishing chain — where the pre-push sync found that origin/main had advanced by three fires while this one sat unpublished. Wall clock from open to that discovery: about 53 hours. The container survived across two calendar days, which is why every file mtime and the composition timestamps in this record read 2026-08-22 while the publish actually happened on 2026-08-24.

By the time the merge was finished the count had risen to five: 2026-08-23T0409Z-intel, 2026-08-23T2311Z-weekly, 2026-08-24T0110Z-weekly, and then — landing while this record was being rewritten — 2026-08-21T0410Z-intel and 2026-08-24T0906Z-intel. Two of those need naming. The 2026-08-21 fire did run. This run's window was computed on the premise that it had not (hence gap_hours: 48 against a 2026-08-20 predecessor), and that premise was wrong: the 08-21 fire was itself stalled, published five entries today, and none of them overlaps the eight published here — checked on CVE ids and entity keys. The window figures in this frontmatter are left as the run computed them, because they are what it actually used; the true gap to the preceding fire was 24 h, not 48. And 2026-08-24T0906Z-intel stood itself down to zero entries for a stale clock, which is the same family of fault as this run's, caught earlier and handled better. The first of them matters most: it computed a 74 h window precisely because this fire had never published, so its window fully contained this one, and it covered eleven entries of the same ground. The W34 weekly then covered more of it again. The pipeline's own guard for this case is explicit — the overtaken run publishes only the delta the newer fires did not surface — so that is what happened here, mechanically rather than by judgement.

The dedup, and what it cost. Every one of the sixteen entries was checked against all twenty-five entries the three overtaking fires published, on CVE identifiers and on entity-registry keys, and then read where the keys were absent. Eight were duplicates and are gone:

• trueconf-server-preauth-sandbox-escape-kev-installer → both CVEs and both entities already on 2026-08-23/trueconf-server-kev-head-mare-trojanized-installer
• gtig-three-russian-clusters-authentication-flow-abuse → six shared entities with 2026-08-23/gtig-russia-clusters-app-passwords-whatsapp-linking. This was the run's deep_dive, so the run now ships without one
• misp-stix-trust-decision-bypass-no-released-fix → all three CVEs on 2026-08-23/misp-stix-import-trust-boundary-dos-parser-state
• uat-10147-spectre-callback-unlinking-linux-rootkit → both CVEs and the actor on 2026-08-23/spectre-uat-10147-byovd-edr-callback-unlink, with a companion entry covering the AI half
• crates-io-build-script-dropper-yank-lure-arrayref → 2026-08-23/rust-crates-arrayref-build-script-backdoor-dprk. This is the entry the verification loop recovered as a coverage gap inside this run, and a later fire found it independently
• cve-2026-69836-entra-id-exploited-flag-retracted-feeds-stale → same CVE on 2026-08-23/cve-2026-69836-entra-id-exploited-flag-corrected
• btr-defender-remediation-driver-ring0-primitive-absence-tell → same research, same finding, on 2026-08-23/btr-sys-defender-remediation-driver-kernel-primitive. Neither entry carried a CVE and this run's carried no entity either, so no structured key caught it; it was caught by reading both
• martigny-combe-valais-secretariat-mailbox-contact-fan-out → same incident, same dates, same contact count, on 2026-08-23/martigny-combe-valais-communal-mailbox-compromise. Again no key overlap: this run had registered incident:martigny-combe-email-compromise-2026-08 and the overtaking fire registered nothing, so the registry key this run created has been dropped with the entry rather than left orphaned

Two of the eight had no structured overlap at all. A CVE-and-entity dedup pass would have shipped both as duplicates; what caught them was reading the candidate against the store. That is worth carrying into the prompt, because the mechanical index is exactly what a rushed run leans on.

The eight that ship are the delta, and one of them is the reason this record is worth reading. Six are first coverage that no overtaking fire carried, and two are updates:

• spip-two-unconditional-preauth-rce-releases-three-days-apart — untouched by any of the three fires, and the strongest item here. SPIP shipped two critical releases three days apart, each fixing an unconditional pre-authentication RCE the vendor describes in identical language, each explicitly outside the coverage of its own request-filtering layer, and each with exploitation attempts the vendor states are already being seen. Only the first has a CVE. A vulnerability-management process keyed on CVE identifiers reports the estate clean at 4.4.20 while the newer flaw is open — and 4.4.20 is precisely the release the vendor names as affected. For a French-language public-administration CMS in this constituency's region, this sitting uncovered for two days is the real cost of the stall
• ptc-windchill-three-new-cves-unauth-rce-no-fixed-version — the W34 weekly covers the exploited older Windchill flaw and the Cl0p campaign around it; these are three new CVEs, all three requiring no privileges, with no obtainable fixed version for two of them. No overlap
• cve-2026-19586-tp-link-omada-openvpn-preauth-injection — untouched. Pre-authentication OS command injection on an internet-facing SMB and branch-office edge line, with the vendor's own nineteen-row per-hardware-revision firmware table that no CVE record reproduces
• zoomsday-cve-2026-53415-higher-patch-floor-than-siblings — untouched, and the finding is the patch floor: the third flaw needs a higher fixed version than the two beside it, so patching to the obvious floor leaves it open
• ftp-banner-dead-drop-resolver-e4del-pinhole — untouched by any entry, and it was sitting on the coverage backlog, queued there by the 2026-08-24 weekly. Publishing it discharges that row, which is now annotated as such
• kairos-velilla-san-antonio-second-madrid-municipality — untouched
• cve-2026-19478-gitlab-honeypot-exploitation-confirmed — ships as an update_of on 2026-08-19/cve-2026-19478-gitlab-graphql-unauth-data-destruction, which is the shape it was composed in
• 2026-08-24/cisco-crosswork-secure-workload-nine-cwe-grouped-cves — the one entry that does not live in this run's own date folder, because its discovered_at is the day the stand-down happened rather than the day the advisories were read. Reshaped during the stand-down from first coverage into an update_of on 2026-08-23/weekly-w34-vuln-status-rollup, because the weekly reached the same two advisories from a national-CERT relay and covered them CVE by CVE while this fire was unpublished. It still ships because three things in that account need correcting from the vendor's own CSAF data: the set is nine CVEs and not eight (CVE-2026-20319 is absent from the rollup's enumeration), the characterisation of the whole set as unauthenticated holds for six of the nine and not for the three carrying PR:L, and the rollup records exploitation status as unknown where Cisco states it is not aware of malicious use. The per-CVE affected and fixed release strings appear in neither the rollup nor the relay

What the verification loop is worth here, and what it is not. All three iterations ran against the full sixteen, so the eight that ship carry the same scrutiny the run recorded: three iterations across two models, twenty-eight defects found and every one remediated. What the loop cannot vouch for is the stand-down itself, which happened after the last verifier returned — no verifier read the reshaped Cisco entry in its update_of form, and no verifier checked the dedup that dropped the other eight. Both are this agent's work alone, and both are on the weekly quality audit's surface.

The publish gate was not met, and the honest version is worth stating plainly. Iteration 3 ran on Opus, re-derived iteration 2's fix independently against the entry files and the two prior run records, took a fresh read of the entries, and returned the run's first CLEAN — no truth defects, no editorial defects, three advisory items, all three of which were applied rather than left. A confirmed CLEAN needs that verdict repeated on the other model, which would have been a fourth iteration. By then the run was already hours past its guard, and the guard's instruction at that point is to land rather than spend more clock proving a verdict. So confirmation_waived is set and this run publishes without a two-model agreement on its final verdict.

The rotation pass, and an operational mistake worth writing down. Iteration 2 ran on the other model and did the two jobs the rotation exists for: it gave the recovered crates.io entry its first cold read — iteration 1 had never seen that entry, because it was composed in answer to iteration 1's own coverage finding — and it re-checked all twenty-five iteration-1 remediations against primaries it fetched again itself rather than trusting the run directory's saved copies. No remediation had regressed. It found one defect, in this record: the priority-calibration paragraph enumerated seven high entries and eight notable against an entries_published of sixteen, because it was written before the recovery and never revisited.

The mistake is mine and it belongs here. While iteration 2 was finishing I checked the run directory for its report, found a stub transcript and no findings file, concluded from that filesystem evidence that the spawn had been blocked the way the alternate verifier has been blocked on two earlier fires, and started a retry on the rotation-recovery ladder. The check had raced the agent's final writes by under a minute: iteration 2 was healthy and delivered a full report. The retry was stopped as soon as that was clear, but it had already spent several minutes of the run's clock re-verifying material iteration 2 had just verified, and it was pinned to the same model, so it could not have served as the second half of a two-model agreement even if it had finished. Two lessons: absence of output files is not evidence of a dead sub-agent while its wall-clock cap has not expired, and a recovery spawn must be checked against the rotation it is meant to preserve before it is worth starting.

The deep reads earned their cost, and two of the three findings that survive the stand-down are in entries that ship. Every published item was re-read against its primary before composition, and the four follow-up passes returned thirty-five corrections between them. The SPIP item was surfaced as one emergency release fixing one unnumbered flaw; the deep read established there were two critical releases three days apart, with the earlier one carrying CVE-2026-77647 and the later one carrying no identifier at all. The Zoom item was surfaced with a single combined patch table; the deep read found the vendor publishes one bulletin per identifier and that the third flaw needs a higher fixed version than its two siblings, so the entry's whole point became that the obvious patch floor is the wrong one. The Cisco item was surfaced as a uniformly unauthenticated set; the vendor's own CSAF vectors show six of nine unauthenticated and three requiring low privilege, and that correction is now the reason that entry ships at all.

Sourcing and single-source items (for the eight that ship):

• Single-source, and corrected in the direction that costs a rating rather than gains one: 2026-08-22/ftp-banner-dead-drop-resolver-e4del-pinhole. The surfacing pass had this as multi-source with the relaying outlet as the researcher and the researcher as corroboration. The deep read established the opposite — the research unit did the original hunting, reverse engineering and naming, and the outlet says in its own text it is working from a report shared with it and adds no independent analysis. Two publishers of one assessment is not two sources, so the entry is single-source with the relaying outlet cited as such, and reliability follows the registry's C rating for that publisher rather than the quality of this one output.
• 2026-08-22/ptc-windchill-three-new-cves-unauth-rce-no-fixed-version ships with an empty evidence block, deliberately and with the reason stated in the entry. The advisory records could only be read through a transport that summarises rather than returning raw text, so no quotation could be literal-checked as a contiguous substring; the entry paraphrases instead of quoting.
• Contradictions carried rather than resolved: the Zoom flaws' provenance is contradicted three ways between the vendor's credit and two passages of the researcher's own write-up, so the entry attributes that flaw to nobody, and the vendor's own CVSS vector records user interaction as required while the national advisory's title and the researcher's framing both say zero-click — the entry states the tension rather than picking a side. For the Spanish municipal item the outlet's May reporting describes the same actor's earlier case as ransomware while its own background material describes the actor as encryption-free, and the entry says so.
• One quote failed its own check during this run's main-agent read and is recorded because the failure mode is the pipeline's most persistent: a French quotation that looked correct had been retyped with an ordinary space where the page carries a non-breaking one, so it was not a verbatim substring. It was shortened to the fragment that literally matches. A deep-read pass independently found four more of the same class in the surfacing returns — two ellipsis splices, one tense change and one paraphrase inside quotation marks — none of which reached an entry.

Borderline drops. Each was researched and verified; each is dropped for a stated reason, not for space.

• borderline-drop: Unit 42 identity abuse through trusted communication channels — the mechanism families it documents are ground this store already holds, and its headline content is vendor-telemetry share-of-alerts percentages of the kind this pipeline does not publish. What remains is standing hardening advice rather than something that changes a decision in the next seven days.
• borderline-drop: leak-site claim against a Swiss datacenter naming a Zurich university of applied sciences — no victim statement, no high-reliability journalism, and every corroborating hit is another aggregator mirroring the same post. Held as a watch item rather than published on an extortion claim alone. Note for the operator: an overtaking fire published 2026-08-23/payload-zurich-it-provider-hwz-student-data, so this item did get coverage two days later from a fire that reached what this one could not.
• out-of-window: SSD Secure Disclosure Unisoc baseband-to-application-processor chain — freshest source 2026-08-17 against a 50 h window. The transport problem that blocked it on three previous fires was solved in substance, with two outlets identified that read the advisory directly, and that is recorded in the source's notes.

Priority calibration. Of the eight that ship, four are high — SPIP's two exploited unconditional pre-auth RCEs, GitLab's move from disclosed to exploited inside two days, the PTC set with no obtainable fixed version for two of three, and the pre-authentication command injection on the internet-facing edge line — and four are notable. No entry is critical; nothing here meets that bar. The high count is not a judgement about a quieter window: it is what survived a dedup against three later fires, and the twelve-entry difference between what this fire verified and what it published is a publishing artefact, not an editorial one.

Action items. Fourteen actions across seven of the eight entries; the Spanish municipal claim ships none, carried for the pattern rather than a task. Several of them exist only because the deep reads found the obvious answer was wrong: the Zoom floor is 7.1.5 rather than 7.1.0, the SPIP floor is 4.4.21 rather than 4.4.20, and the TP-Link table is keyed on hardware revision rather than model name.

Backlog. Five rows were open when this run started and all five were worked; three overtaking fires have since added their own, and this run's late landing has been reconciled against them rather than overwriting them. The FTP-banner row the 2026-08-24 weekly opened is discharged by this run's entry and annotated in place. The two rows this run added — an npm wave whose implant triggers on module load rather than on install, and a sandbox-escape advisory in the isolation library that AI-agent platforms use to run untrusted code — stay open; both needed a primary this run never reached. The Siemens S7 row is partly discharged: this run added the standard-library PDF text-extraction path that was the row's second instruction, so re-reading that advisory's own text is now a one-command operation. On merge, entities/registry.yaml, state/cves_seen.json, state/source_health.json and sources/sources.json were taken from main rather than from this run, and only this run's genuinely-new records were re-applied on top — three registry records, eleven CVE index records and one candidate source. Resolving those files the usual way would have discarded three fires of accumulated work.

Sub-agent loss and recovery. One deep-read pass was terminated by the content-safety classifier mid-read on kernel-driver abuse material and wrote no findings. Rather than composing from surfacing summaries, it was re-spawned as two smaller passes with an explicit model override to the other model and with the defensive framing declared in the tasking before the first fetch — observability and discriminators only, no offensive procedure, no indicators. Both completed and returned 131 literal-verified quotes between them. This is a recurring rather than exceptional condition: the same class of block has cost this pipeline four research spawns on 2026-08-03 and every alternate verifier spawn on two earlier fires. The model-override ladder worked again.

Tooling: this run shipped nothing, and that is the finding. Every tooling and prompt change it made was discarded at merge time as a rediscovery of work main already carried — better, in both cases, and published while this fire sat unpublished.

It had added a standard-library PDF text-extraction path to the fetch bridge, discharging a standing backlog instruction, and bumped all three prompt banners plus a changelog entry to v3.32 for it. main's own v3.32, dated 2026-08-21 and titled for the same problem, already had one — selected on content type rather than as a fallback after failure, with ToUnicode CMap handling, extraction scoring, mirror counting, a --json mode, and explicit reporting that an image-only PDF has no text objects (which is not extractable, never says nothing). main's version was kept and this run's discarded, along with its banner bumps and its changelog entry.

The auto-merge of those two implementations produced a completely broken tools/fetch_source.py, and it looked clean. Git merged both without a single conflict marker, and the file still parsed — but it now defined pdf_text twice and registered a pdf subparser twice, so argparse raised on setup and every subcommand of the fetch bridge crashed before doing anything. Had this landed, the next fire would have had no bridge at all: no KEV, no CSAF, no PDF, no url. It was caught by running fetch_source.py pdf --help after the merge rather than by reading the diff. A clean auto-merge of two independent implementations of the same feature is not a merge, and a Python file that parses is not a working one — run the CLI.

The same pattern, one file over: this run had also fixed tools/source_health.py, where a bridge recipe's health was judged by output byte count so a valid zero-result JSON envelope read as a dead source. main already carried a fix for that defect too, from the same sec-disclosures-edgar case, published 2026-08-23 and handling three more list keys than this one. Kept main's, discarded ours.

What this run did contribute to the repo, after all that: two .gitignore rules, added when the staging review found roughly 10 MB of raw fetched bodies about to be committed under names the existing rules did not match — work/**/*.clean and work/**/kev*.json. Both names were this run's own invention, so both were its own leak to close. Plus one candidate source (tp-link-omada-psirt, with the reusable recipe for reaching a vendor SPA's per-advisory path through a national-CERT CSAF record's external-reference field), three registry records, eleven CVE-index records, and its memory notes.

Two fires independently building the same PDF transport, and two fires independently fixing the same probe defect, inside three days, is not luck — it is the backlog and the source-health sweep each describing a problem well enough that any run picks it up, with nothing anywhere saying it is already being worked. A claim mechanism on backlog rows would have saved both.

Watchlist. The profile configures no product or supplier watchlist, so both sweeps are documented no-ops and the parseable line is omitted. The region and sector lens was applied throughout, and it is what carried the SPIP disclosure and both municipal items — one of which was then stood down as a duplicate.

For the operator, two questions this run cannot answer for itself. A 53-hour container lifetime on a fire budgeted for about three is not a scope problem, and the run's own watchdog fired correctly and was obeyed; something outside the run's control kept the container alive across two days. Whether that is a scheduler condition, a container stall or a session-resume artefact is visible in infrastructure this run cannot see. And the overtake was discovered only at the pre-push sync, by which point sixteen entries had been composed, gated and verified three times — twelve of those entry-verifications were spent on material that could not publish. A cheap gap check against origin/main at each phase boundary, rather than only at Phase 6, would have caught it hours earlier.

Coverage gaps: cisa-advisories (HTTP 403, eighth consecutive run; the KEV feed covered the exploited-vulnerability surface, the advisory surface again not); cisa-directives (HTTP 403, seventh consecutive run); ncsc-uk (essential-tier source not reached — the home-region pass spent its clock on the Berlin chase and its three composed items); ccn-cert-es (rotation-priority source not attempted, and a Spanish municipal incident published this run, so the gap had a cost); siemens-productcert-csaf (HTTP 403, fifth consecutive run; CSAF mirror checked, nothing in-window lost); ssd-disclosure (anti-bot shell, fifth consecutive failure, resolved in substance via substitute primaries); github-advisories (anti-bot on both the HTML and API paths); ptc-support-portal (login-gated, and it holds the fixed builds for two published CVEs); acronis-tru, ahnlab-asec (HTTP 403); paradigm-shift-research (client-rendered shell, reader-dependent); cnil-fr (listing renders stale rather than quiet — flagged for a recipe check).

Essential-coverage: missed=cisa-advisories (HTTP 403 on every transport), cisa-directives (HTTP 403 on every transport), ncsc-uk (not attempted — sub-agent clock).