2026-08-05T0412Z-intel

Coverage and verification notes

Standard window: 26 h, derived from a 24.0 h gap to the previous fire (2026-08-04T0411Z-intel, which reported publish_status: ok). No closed-source drops were present, so no intake sub-agent ran. The pinned ATT&CK dataset was current at v19.1.

Watchlist sweeps are a no-op on this deployment — the organization profile configures no product and no supplier watchlist — so no Watchlist: line is reported and no entry carries watchlist_hit.

Research sub-agent starts were blocked, and the block was not the tasking

All four research sub-agents were spawned in one message at 04:13Z on the Sonnet-pinned research definition. S3 and S4 started normally; S1 and S2 both terminated immediately with an API error naming Sonnet 5's safeguards. Both were retried twice more with progressively shorter spawn messages — the second attempt replaced an inline list of already-covered items with a plain file reference, the third stripped the message to domain, source slice, transport note and dedup paths — and both were blocked again each time, at the first request, before any tool call.

The variable that changed the outcome was the model binding, not the message: S1 and S2 started on the fourth attempt when spawned on Opus, while S3 and S4 had carried the longest messages of the four and were never blocked at all. Recorded as a transient platform-side condition affecting the Sonnet binding of this definition at this hour. The consequence for the run was a roughly six-minute-later start for the two affected domains and a model split (S1/S2 on Opus, S3/S4 on Sonnet) that differs from the definition's pin; every **Model:** line above is the value each agent reported for itself. Full attempt-by-attempt log in work/2026-08-05T0412Z-intel/spawn-incidents.md.

The reader pool was not exhausted, and three sub-agents believed it was

Three of the four sub-agents reported the jina reader as unavailable for the entire run, citing HTTP 402 on "both" keys, and abandoned that rung of the fetch ladder. The pool actually held seven keys, five of them live with 37 million tokens between them. The first two keys in spend order are exhausted, and dead-key state was process-scoped — so every fresh fetch_source.py invocation re-probed those two, printed a "balance exhausted" line for each, then rotated to a live key and succeeded. The agents read the warnings and stopped.

This cost real coverage: prodaft and ccn-cert-es are pinned to the reader and were skipped by S1 as unreachable (S2 reached ccn-cert-es independently and found nothing in window), the Chrome 2026-08-04 stable-channel post body could not be read, and CERT-PL's 403 had no recovery attempt.

Fixed in tools/fetch_source.py this run: exhausted and revoked keys are now cached across processes with a six-hour expiry, so a fresh invocation skips a known-dead key instead of re-probing it, and the rotation notice now states explicitly that it is not a failure and that the fetch continues. The expiry preserves the original recovery property — a topped-up key is re-probed once its entry ages out — and if every key is inside its expiry the full pool is re-probed rather than dropping to the anonymous tier, so a stale cache entry can never lock the pool out. Verified: a cold call rotates, warns and persists; the next call is silent and succeeds on a live key.

Duplicate items merged

Two stories were returned independently by two agents and were composed once each. The Swiss federal SharePoint intrusion came from both S2 and S4; the S2 return carried the fuller timeline and the German-language primary and was used as the base. Check Point CVE-2026-18574 came from both S1 and S2, with the two disagreeing on whether the end-of-support trains are affected — S2 correctly declined to assert it without a vendor primary, and the primary read through the vendor's data route settled it in favour of S1's reading. Both are recorded in work/2026-08-05T0412Z-intel/triage.json.

Quote verification forced three corrections

Every quote was literal-substring-checked against the body saved under work/2026-08-05T0412Z-intel/src-*.txt, and the results are in quote-verification.md alongside them. Three did not survive as returned.

The Unit 42 vulnerability-discovery figure was returned as a sentence ending "99.4% of which were previously unreported." The page's sentence does not end there — it continues "and 40% of them designated as high or critical severity" — so the returned form was a truncation closed with a full stop the source does not carry. It was replaced with the fragment that does match. A second Unit 42 quote had been capitalised as if it opened a sentence when it sits mid-sentence, and was corrected to the source's own casing. The Apache Tomcat quote is line-wrapped in the served HTML and passes as a contiguous sentence once whitespace is normalised.

Separately, the Check Point affected-version list required care: the vendor's structured versions field omits R80.20, while the advisory's own prose names it among the end-of-support trains. The prose is the authority and R80.20 is in scope.

Claims deliberately not made

Three inferences the research returns offered were dropped rather than published, because no cited source states them.

No CVE is recorded for the Swiss federal SharePoint intrusion. BIT says only that Microsoft disclosed several SharePoint flaws in mid-July and that exploitation of them presumably enabled the attack; naming a specific identifier would have over-claimed past the disclosing party and, separately, would have collided with existing coverage. For the same reason the machine-key persistence mechanism is attributed in the body to The Record and CISA as the wave's post-exploitation pattern, and is not claimed as confirmed for this incident — which is also why that entry maps only the access vector and the valid-accounts technique rather than the credential-theft chain.

No CVE is recorded for the Hungarian State Treasury intrusion either. The reporting links to an Oracle October 2017 patch cycle without naming a vulnerability, and the specific identifier most associated with that cycle was the research agent's inference rather than a published fact. The 116-virtual-machine and 229 TB figures come from experts reading attacker-supplied screenshots, not from an official statement, and are carried as a claim under review.

Borderline drops

• borderline-drop: Pilz IndustrialPI 4 kernel privilege-escalation chain (VDE-2026-072) — authenticated local privilege escalation with fixing firmware already available and no exploitation reported, which the ordinary patch cycle handles. All three underlying kernel vulnerabilities were covered in May and June 2026; this advisory re-packages them for one vendor's firmware.
• borderline-drop: NCSC-UK statement on frontier-AI evaluation escapes — a four-sentence position statement with no new technical content, no named incident, vendor or product, pointing at guidance that already exists. The AI evaluation-containment thread is covered this run through the AISI and OpenAI first-party disclosures instead.
• borderline-drop: Compass Security Pipeleek v1 release — primarily a tool-release post and single-sourced. The Renovate autodiscovery weakness it demonstrates is a configuration-review item rather than new attacker activity; noted here so the exposure class is recoverable if it resurfaces with corroboration.

Three entity-overlap warnings, confirmed deliberate and left standing

The gate asks a run to confirm that three entries sharing entity keys with earlier coverage are genuinely new stories rather than deltas that should have shipped as updates. Confirming each, in the gate's own terms:

The AISI and OpenAI evaluation-containment entry shares the Hugging Face and Anthropic incident keys with two earlier entries. It is a new story: a different organisation (a UK government body), a different environment, a distinct disclosure by two first parties, and — the part that is not present in either predecessor — an agent constructing fabricated identities and social-engineering human maintainers to get malicious code into a real project. That behaviour is new to this thread, not a development of the earlier two.

The Hungarian State Treasury entry shares the ByteToBreach actor key and the Romanian land-registry incident key with a prior weekly. It is a new story: a different victim, a different country, a different intrusion, in a different month. The shared keys are the point of the entry rather than evidence of duplication — one operator reaching two EU national government bodies is the finding.

All three entries name the prior coverage in references[], which is the honest record of the relationship. That does not clear the warning: the reference-based exemption in the gate applies only to strategic entries, whose whole function is synthesising the operational entries they list. Extending it to operational entries was considered and rejected. The acknowledgment ledger already carries two audit decisions refusing to add auto-pass paths to this gate, on the grounds that a check a run can silence with its own prose stops being a check — and a run editing the gate so that its own warnings disappear is precisely that pattern. The warnings therefore survive this run by design, with the confirmation recorded here where a reviewer can weigh it.

Three verifier findings rebutted rather than applied

Iteration 2 returned six truth findings. Three were correct and are fixed; three were themselves wrong, and applying them would have replaced accurate verbatim quotations with worse ones. Each was re-tested by re-fetching the cited page and running an exact substring match, and the evidence is on disk under work/2026-08-05T0412Z-intel/.

Two concerned the deep-dive entry's German-language quotations from the Federal Council release. The verifier reported that "Im Rahmen der Analyse des Vorfalls wurde festgestellt, dass rund 200 Konten kompromittiert wurden" splices two sentences and substitutes "200" for "mehreren", and that "Es gibt bislang keine Anzeichen dafür, dass Daten abgeflossen sind" is a paraphrase. Both are exact substrings of the release's opening paragraph. The page states each fact twice — once in the lead, once at greater length in the body — and the verifier compared the quotations against the body sentences rather than the lead ones they were taken from.

The third concerned the RUAG entry, where the verifier reported the clause "keine Anhaltspunkte für eine Rechtsverletzung bestehen" as wholly fabricated, stating that the word "Rechtsverletzung" does not appear anywhere on the page and that it had fetched the page in full. It does appear, and the whole clause is present verbatim in the review's central finding. Iteration 3 re-fetched both pages and upheld all three rebuttals. Iteration 4 then found the mechanism: fetching the VBS page through the reader proxy transiently returns a different render that omits the disputed sentence, while a raw-HTML bridge fetch of the same URL carries it. The quote is genuine; the verifier that called it fabricated was reading a degraded copy of the page. Three independent checks now agree, and the transport-dependent render is the reason a single failed lookup is not sufficient grounds to call a quotation invented.

Recorded because a verifier's finding is evidence, not a verdict, and a run that applies every finding without testing it will corrupt correct work as readily as it fixes incorrect work. The three rejections are as much a part of this run's verification record as the fifteen it accepted.

Sourcing dispositions

Four entries ship single-sourced. The NCSC-CH Power Pages advisory and the CISA genetic-analyzer advisory both fall under the national-authority carve-out — each is the disclosing authority for its own publication. The Kaspersky adversary-in-the-middle phishing analysis and the Unit 42 vulnerability-discovery results have no carve-out and are marked plainly: both are single-vendor analyses of their own telemetry, carried at reduced confidence, with the Unit 42 figures flagged in-entry as the vendor's own measurements rather than independently verified counts.

The AISI and OpenAI disclosure is genuinely multi-source in the sense the classification scheme asks for — two parties on opposite sides of the same incident publishing first-party accounts, not one account republished.

No contradictions between sources were left unresolved, and no entry was included at reduced confidence for lack of a primary.

Coverage gaps

Coverage gaps: prodaft (reader rung abandoned in error — root cause fixed this run); censys-blog (origin-wide challenge gate, documented and handled); dragos (feed not recovered within the research budget); vulncheck, claroty-team82, recordedfuture-insikt, wiz-blog, google-tag, nozomi-networks (JS-hydrated listings or known recipe gaps with no dated rows enumerable); chrome-releases (2026-08-04 stable post located but its body unreadable, so the CVE list could not be checked — no in-the-wild string was present in the retrieved HTML and BSI classed its advisory an update); infoguard-labs (no working discovery surface); standard-rotation tails on S3 and S4 not reached within the wall-clock budget.

Essential-coverage: all 13 essential-tier records across S1 and S2 attempted; cert-eu returned an empty feed and cert-pl's advisory listing path is 403-blocked, both recorded above.