{{first_name | Reader}},

In partnership with:

Smallstep — SCEP is a password. Passwords get stolen. Real Zero Trust starts with the device — begin with Wi-Fi, extend across apps and infrastructure.

Cite the record - The record behind this brief is public, inspectable, and citable.

The weekly brief is where things get worked out. The daily CISO briefing on Spotify is the fast version: two minutes each weekday on what actually moved. Follow it here.

CybersecurityHQ

CybersecurityHQ deep dive, 8 November 2026. Catalog version 2026.11.06, 1,769 entries. Every timestamp is UTC and traces to a retained primary record.

On 30 October, CISA added an Ivanti Connect Secure vulnerability to its Known Exploited Vulnerabilities catalog with a fourteen-day remediation deadline. Nearly four days after the listing, documented checks still found the CVE record and CISA's enrichment unavailable through the endpoints queried.

A second Ivanti vulnerability showed a different failure. Its enrichment already existed, but the repository's earlier recorded version classified exploitation as none, and the change to active appears in a commit timestamped an hour and a quarter after CISA listed the vulnerability as exploited.

SonicWall and WordPress entries from the same period showed two more sequences. Across the three principal cases, the first recorded enrichment commits followed the listing by two hours to nearly four days. The exploitation findings were authoritative. The records meant to explain them kept a different schedule.

These are recorded commit times, not observed first public availability. The entries are three selected cases, not a population estimate.

CVE-2026-118527 (companion CVE-2026-111357) · Ivanti Connect Secure · listed 30 Oct · 14 days, no forensic flag

The catalog release of 30 October at 17:02:45 added two Ivanti entries that describe one chain from unauthenticated command execution to root. The companion received three days and a forensic flag. This entry received fourteen, due 13 November.

On 3 November at 13:56:06, CISA's metadata URL for the identifier returned 404. At 14:40:06 the CVE program's API answered The cve record for the cve id does not exist. The record was published at 14:53:28. CISA's container in it carries a stamp of 15:32:56, and the metadata file, whose internal assessment stamp is 15:32:15, has its first recorded commit at 16:17:59, 3 days 23 hours 15 minutes after the listing. We hold both failed checks with content hashes. Two earlier checks on 31 October agreed but were not retained as bytes, so they are context only.

The catalog's published deadline was in effect while those checks found no public structured record and no public enrichment. Their subsequent recorded timestamps establish the sequence, although the first public retrieval times are unknown. Whether a given agency asset carried a corresponding obligation depends on its circumstances under the directive. A team using the catalog as its trigger and CISA's data as its enrichment would have seen a fourteen-day clock with no assessment behind it. Ivanti's advisory had added the identifier on 29 October, describing an authenticated file upload and scoring it 4.3, so a vendor description existed a day before the listing while the CVE record was empty. The cause of the delay is not established by any public record.

The companion shows the second failure. Its recorded metadata read exploitation: none at a commit on 30 October at 06:17 and active at a commit at 18:17:50, an hour and a quarter after the listing, with an internal assessment stamp 24 minutes after the release. Continuous public availability of the older version is not established.

This case says nothing about when exploitation began. Ivanti's advisory confirms use in the wild against a limited number of customers when the flaws are chained, and gives no date.

CVE-2026-19868 · SonicWall SonicOS SSL VPN · listed 6 Nov · 14 days, no forensic flag

SonicWall's advisory describes an authentication weakness: a user holding valid credentials for an alternate method can bypass SAML authentication and SAML-enforced multi-factor authentication. The CVE record declares the vendor's public time as 18:55 and its own publication as 19:03:00. The catalog release is timestamped 19:44:45, which is 49 minutes 45 seconds after the declared public time and 41 minutes 45 seconds after the CVE. That interval gives this report its title. It measures the gap between two publications, not the time anything took to be discovered.

The disclosure had a preface. A SonicWall support notice on 3 November announced the advisory for 6 November, without CVEs or exploitation text, and listed a fixed Gen 7 release available since 20 October. So a fix existed seventeen days before the flaw was described.

The advisory itself, read on the vendor's page on 8 November, covers seven identifiers. For this one alone it states that SonicWall PSIRT "has investigated a report indicating potential exploitation of this vulnerability," and that the flaw affects SSL VPN only when SAML is enabled. It gives no date of first observation, no scale and no distinction between probing and success. It shows a publication date without a time of day.

CISA's enrichment landed overnight. The CVE record's CISA container carries a stamp of 04:55:51 on 7 November, 9 hours 11 minutes after the listing. The metadata file's first recorded commit is at 07:17:22, 11 hours 33 minutes after it. Inside that file, three internal timestamps describe one state: 19:20:53, 20:37:20 and 20:58:23 on 6 November. The middle one falls 53 minutes after the listing. None of them is the time CISA reached its finding, and a reader should not take 20:37 to mean CISA knew then.

What the sequence establishes is that CISA had made an authoritative finding of active exploitation by the time of the listing, which is the listing itself. When the evidence behind it was acquired, and when the activity began, the records do not say. This case stays in a state we call timing indeterminate.

CVE-2026-119977 · WordPress Core · listed 3 Nov · 3 days and forensic triage

WordPress released 7.1.4 on 28 October at 17:13:02 and named a race condition in the core upgrade process: during a full-package upgrade, affected versions unpack files into a predictable, web-accessible staging directory that includes the installer, and a well-timed unauthenticated request can reach code execution. The window lasts seconds, and the flaw is exploitable during the upgrade to the fixed release itself.

The CVE record was not published until 31 October at 05:33:07, 2 days 12 hours after the vendor. The catalog release followed on 3 November at 20:00:24, 3 days 14 hours after the CVE and 6 days 3 hours after the vendor. The metadata file carries an internal assessment stamp of 20:50, 50 minutes after the listing, and its first recorded commit is at 22:18:56, 2 hours 19 minutes after the listing, and the CVE container's stamp is 04:56:31 on 4 November, 8 hours 56 minutes after it. The CVE stamp follows the commit by 6 hours 38 minutes here, where it preceded the commit in the other two cases.

Wordfence deployed a firewall rule at 20:30 on 28 October and logged its first matching request at 20:39, 3 hours 26 minutes after disclosure, and more than 18,500 requests in the first 21 hours. Those are attempts in one vendor's sensor population. The rule did not exist earlier, so the telemetry cannot see earlier attempts, and Wordfence reports no count of compromised sites.

Every commit and every CVE record stamp we measured falls after the listing, and the two channels disagree about order. The CVE stamp is a last-update time, so for SonicWall and WordPress an earlier submission cannot be excluded. For Ivanti it is firm, because the record did not exist earlier.

Multi-day lags and sub-hour listings both occur, and these cases do not establish how often. The three were chosen because their timestamps are recoverable to the minute, from five entries added between 30 October and 6 November.

The assessment stamp follows the listing, not the other way round. In the three files whose CVE record existed before the listing, the internal assessment timestamp falls 24, 50 and 53 minutes after the catalog release. In the Ivanti fourteen-day file it falls 39 minutes after the record's publication. That fits an exploitation value written by a step that runs after the listing, and it does not fit reading the stamp as the moment the finding was made.

The deadline is not a timing signal. The entry listed fastest after disclosure received fourteen days. The entry listed six days after disclosure received three days and a forensic obligation.

A listing is an authoritative finding that a vulnerability has been exploited, plus a deadline computed from three inputs: technical impact, whether exploitation can be automated, and whether CISA's data showed a publicly exposed asset. First-observed exploitation is not an input. CERT/CC's published model of the directive gives this table:

The catalog feed publishes the due date and a forensic-triage flag for each entry. Vulnrichment adds CISA's exploitation, automatability and technical-impact assessments, and no exposure value, because exposure is the agency's own determination, asset by asset. Missing enrichment therefore stops a consumer from reproducing the rationale. It does not remove the published instructions. CISA's guidance says it will always provide Vulnrichment data for a catalogued identifier but sets no deadline for doing so, so what we describe is an observed gap, not a breach. Where the table cell implies an "exposed" input, that is the value CISA used, not a finding that your asset is reachable. "No forensic obligation" here means none under this table, and does not mean no investigation is warranted.

For federal agencies the applicable remediation timeline is determined asset by asset under the directive, and the catalog date is CISA's published deadline, not a substitute for that determination. Read the deadline from the table. Three days with forensic investigation means total control that is automatable or exposed. Fourteen days means total control that is neither, or partial control that is not both automatable and exposed. Three days alone means partial control that is both. None of these says whether the exploitation was a zero day.

Seven clocks run in this domain: fix availability, vendor disclosure, CVE publication, CISA enrichment, catalog listing, first observed exploitation-related activity, and actual first successful exploitation. The first five are recorded timestamps. The sixth exists only in one source's telemetry. The seventh is almost never recoverable, and every claim about it is an inference.

Ingest the catalog entry immediately, and do not wait for enrichment. The sequence is:

How a team fails here. An automated triage system ingests a new entry and joins it to an older record showing exploitation: none. The join succeeds, so no error is raised. Unless the system compares catalog membership with the enrichment value, it keeps acting on the outdated assessment.

When a listing arrives within the hour of disclosure, treat it as a reason to look backwards. For an edge appliance with an authentication bypass, review authentication logs before and after disclosure. Choose the period from your retention, exposure, intelligence and vendor guidance, not from the fix's release date. Treat any alternate-method login on an account that should have been SAML-enforced as a lead.

For the WordPress class of flaw, protect the upgrade before running it. The race is exploitable while a site upgrades. Where you administer the web server, deny web access to the staging directory before updating. Where you do not, update at once.

Treat attempt telemetry as attempts. Eighteen thousand matching requests measure attacker attention. They do not count compromised sites.

A commit time is the time the commit was recorded, not proof of when it became retrievable. The CVE program stamp records submission and is replaced on each submission. Only a successful retrieval establishes availability, and a failed one establishes unavailability.

Our structural conditions count the catalog listing as the event. We recommend to our criteria audit that a short publication interval be treated as an investigative trigger, not a classification criterion. The registry should hold two states: confirmed pre-disclosure exploitation, and timing indeterminate.