2026-08-24T0906Z-intel

Verification & coverage notes

This fire published nothing, and the reason is an environment defect the operator needs to see.

The container this routine started in had a system clock roughly ten days behind real time. date -u returned 2026-08-14T04:17:18Z at start and stayed on 14 August through every phase; the clock resynchronised to the true date, 24 August, only during the publishing chain. Everything the fire computed from the clock was therefore wrong in the same direction:

• the run id was 2026-08-14T0417Z-intel;
• the previous-run anchor resolved to 2026-08-13T0412Z-intel, giving a 24 h gap and a 26 h window, when the real previous run was 2026-08-24T0110Z-weekly about eight hours earlier;
• the prior-coverage index was built for 31 July – 13 August and so was blind to the nine days of entries published between 15 and 23 August;
• entries were composed into entries/2026-08-14/, a date the store deliberately has no entries for.

Compounding it, the content the research sweeps actually reached appears to have been stale by about the same margin: every domain independently reported its newest available material as dated 12 or 13 August, and no source surfaced anything from the following ten days. Whether that is the outbound path serving cached responses or something else, the effect is that the fire researched a window that had already been covered and closed.

What the fire produced, and why none of it shipped. Thirteen entries were composed, passed the mechanical gate, and went through six verification iterations on alternating models before the clock skew came to light during the sync with main. Checking them against the store settled it immediately: all six CVEs the run recorded as new were already in the index, first seen on 15 or 16 August, and main already carries entries covering the same stories — among them 2026-08-15/fortiweb-radius-wildcard-bypass-fortimanager-fgfm, 2026-08-15/cve-2026-19188-haiwell-hmi-gateway-unauth-root-rce, 2026-08-15/geoserver-jsonarraycontains-unauth-sqli-zeroday-exploited, 2026-08-15/france-dgfip-tax-authority-credential-intrusion, 2026-08-15/jwr-phishing-framework-realtime-operator-websocket-mfa and 2026-08-15/clop-windchill-philips-shell-first-victim-confirmations. Publishing would have meant thirteen duplicate entries on a misdated day page, duplicate CVE records, and a corrupted rolling window — the precise outcome the no-repetition discipline exists to prevent. The entries were therefore discarded rather than committed.

Nothing was lost that the store did not already have. The 15 and 16 August fires covered this ground properly and, on the evidence, more completely: the GeoServer zero-day that this fire's fifth verification pass surfaced as a coverage miss was already published on 15 August with exploitation confirmed.

Nothing was published for the real window either. The genuine window for 24 August, an eight-hour gap widened to the 24 h floor, was never researched, because the fire spent its whole budget on 13 August. This run therefore leaves today's window uncovered and the next fire should treat it as the gap to work from.

State changes were reverted with the entries. The additions this fire made to the CVE index, the entity registry and the source list all derived from stale research, so the branch was reset to origin/main and none of them were kept. Two of them are worth re-making by hand on a healthy fire, because they are environment facts rather than content: the Adobe security portal refuses the direct fetch path but answers the bridge, so its recipe should be bridge rather than webfetch; and the metered reader's key pool was exhausted throughout, which took out several sources and twice prevented independent verification of a CISA advisory.

Forensic surface. Everything the fire produced is preserved under work/2026-08-24T0906Z-intel/ for diagnosis: the four research findings files and two follow-up findings files, all six verification reports and their structured findings, the URL-liveness ledger, the triage record, the cleaned text of every primary that was deep-read, and the thirteen discarded entries under discarded-entries/. The verification reports are worth keeping even though their subject was discarded — three of the six passes each found a genuine in-window omission, which is a finding about the research sweep that holds regardless of the date confusion.

• Known gate exception, stated rather than papered over: python3 tools/check_run.py exits non-zero on this record for one check only — prompt_version reads v3.31 while the CHANGELOG on disk now heads at v3.32. That is the same stale-clone defect in another guise: this fire read and executed v3.31, which was current in the clone it was given, and v3.32 landed on main on 21 August while the fire believed it was the 14th. The field records the prompt that actually ran, because writing v3.32 would claim the fire followed a prompt it never read. The check is behaving correctly and the mismatch is real; it is disclosed here instead of being silenced. Every other check passes.
• Environment defect: container system clock approximately ten days behind real time for the duration of the run, resynchronising only at the publishing stage. Every clock-derived value — run id, gap, window, entry paths, the prior-coverage span — was wrong as a result. This will recur on every fire in a container provisioned the same way, and each one will re-publish old ground.
• Environment defect: fetched content topped out around 13 August across all four research domains and every transport, consistent with cached responses on the outbound path rather than with the live web.
• Reader-pool exhaustion: the metered reader reported no live keys for most of the run. Two verification passes could not independently re-fetch a CISA advisory as a result; a third reached it through the reader's anonymous endpoint and confirmed the entry, and also established that an aggregator's claim of a patched release for that flaw is invention.
• Coverage gaps observed while the clock was wrong, recorded because the recipe findings are still true: depthfirst (homepage is an SPA shell with no dated listing); tenable-research (feed parses empty, listing is a JS shell); recordedfuture-insikt and google-tag (landing pages with no dated article index); trendmicro-research (feed transport failure); zscaler-threatlabz (reader pool exhausted); sygnia (bridge recovers the listing but post dates are not extractable); industrialcyber-co and nl-times (article bodies and homepage blocked on every transport); prodaft (pinned URL serves a frozen cache).
• Watchlists: none configured in the organisation profile, so the product and supplier sweeps are no-ops.
• Closed-source intake: none — the drop directory holds no dated subdirectories.
• Verification: the six iterations recorded in the discarded run's artefacts are not carried into this record's counters, because this record publishes no entries and there is nothing for a verifier to check. The confirmation_waived field states that explicitly rather than leaving the shape of a loop that did not run on this output.