Patch Analysis & Exploitation Timeline: A Day-Old Chrome Bug and an Eight-Month-Old Fortinet Flaw Share the Same KEV Batch

Dataset Summary

Field	Value	Interpretation
Reporting Period	September 9, 2026 KEV additions	Public-disclosure dates run from January 13 to September 8, 2026. Selected fix history extends to August 21, 2025; later advisory revisions are reviewed through September 23, 2026.
Data Sources	CISA, public CVE/CNA records, NVD, and official product advisories and release records	Source dates and calculated intervals are distinguished. Vendor investigation material is used only for supported exploitation behavior.
Total CVEs Analyzed	4	CVE-2026-19490, CVE-2025-25249, CVE-2026-87491, and CVE-2026-20079.
Average Disclosure-to-Patch Gap	Not calculated for the full cohort	The evidence does not establish a comparable earliest-fix date across every affected branch and all four CVEs. Selected, explicitly qualified fix milestones are shown below.
Average Patch-to-Exploitation Gap	Unavailable	No exact first-exploitation day is established for all four cases. Unknown dates are not replaced with KEV inclusion dates.
Average Patch-to-KEV Gap	Not calculated for the full cohort	A firmware release date and an advisory revision adding hotfixes are not interchangeable first-patch measurements.
Average Disclosure-to-KEV Gap	112.5 calendar days	The consistently calculable comparison: KEV date added minus the verified public date specified for each CVE.
Median Disclosure-to-KEV Gap	105 calendar days	The midpoint between 21 and 189 days. No individual CVE has a 105-day interval.
Shortest / Longest Disclosure-to-KEV Gap	1 day / 239 days	Shortest: CVE-2026-87491. Longest: CVE-2025-25249. These are listing intervals, not measured attacker waiting periods.

The four-CVE selection and common KEV date are confirmed by CISA's September 9 announcement. The date inputs and their references appear in the timeline tables; all averages and differences are calculations for this analysis.

Sourcing and Methodology Note

The cohort comprises the four vulnerabilities in the September 9 CISA announcement. Catalog fields were checked against CISA's official KEV data feed; public dates and fix information were then checked against the primary records identified beside each finding. Sources were reviewed on September 23, 2026.

This post separates four events: public disclosure, a documented fix milestone, observed exploitation, and KEV inclusion. CISA describes these additions as based on evidence of active exploitation. That establishes exploitation status, but not an exact first attack date, victim count, or the onset of mass exploitation. Accordingly, no mass-exploitation interval is asserted. (Source: CISA announcement.)

The date selection, calendar-day calculations, and operational interpretation constitute the analytical layer of this SecPod article; they are not statistics published by CISA. Missing or ambiguous dates remain unavailable. All four CVEs remain in the article and the disclosure-to-KEV calculation, but a full-cohort first-patch or first-exploitation average is withheld rather than completed with assumptions.

Introduction

The September 9 KEV batch combines a one-day disclosure-to-listing interval with another spanning 239 days. Its four public-date intervals are 1, 21, 189, and 239 calendar days, producing a mean of 112.5 days and a median of 105 days. This is a mixed-age vulnerability cohort, not a uniform wave of newly disclosed flaws.

The fix history is also uneven. An older FortiOS release, a dated NetScaler maintenance release, a Chrome stable update, and a revised Cisco hotfix advisory provide different kinds of timeline evidence. The central operational question is therefore not simply how quickly a CVE entered KEV, but which fix was available for the affected installation and what the exploitation evidence actually establishes. The primary records supporting those distinctions are identified in the CVE Timeline Data section.

Background and Context

The cohort covers authentication-bypass issues in NetScaler and Cisco firewall management, a Fortinet memory-corruption issue, and a Chromium V8 out-of-bounds write. The affected surfaces are not equivalent: appliance configuration matters for NetScaler, while the Chrome CVE record describes code execution inside the sandbox, not a standalone sandbox escape or automatic full-host compromise.
Sources: NetScaler bulletin; Cisco CNA record; Fortinet CNA record; Chrome CNA record.

A disclosure-to-KEV interval can describe the age of public information when a formal exploitation signal is added. A fix-to-KEV interval can describe how long a particular remediation milestone preceded that signal. Neither, on its own, measures the time an organization was compromised or how quickly attackers reverse-engineered a patch. Those questions require attributable exploitation and deployment dates that this dataset does not supply.

Gap Calculation Methodology

Public date (D): the dated initial vendor bulletin or release announcement, or the CNA publication date where that is the verified public record used. The selected dates are August 19 for NetScaler, January 13 for Fortinet, September 8 for Chrome, and March 4 for Cisco, all in 2026. These are the named source events, not dates inferred from a CVE identifier.
Sources: NetScaler public record; Fortinet publication metadata; Chrome announcement; Cisco revision history.

Fix milestone (M): a specified release or advisory event, with its limitations retained. NetScaler uses the dated 14.1-73.33 download; Fortinet uses the FortiOS 7.6.4 release-note chronology; Chrome uses the desktop stable release; Cisco uses the July 31 revision documenting hotfixes. These selected milestones are not claimed to be the earliest fix for every product variant.

KEV date (K): the catalog's dateAdded field. First exploitation (E): an exact, attributable observation date, only when established. An advisory update date, private report date, or assessment timestamp is not substituted for E. Earliest patch (P) would require a confirmed availability date for the defined product and branch.

Calculations use calendar dates, without inclusive counting or assumptions about intraday order. A negative D-to-M result indicates that the selected release predates the public CVE date. Month-only statements are not converted into an invented day. Google's September 8 announcement takes precedence over the Chrome CVE record's September 9 UTC publication timestamp for D; its August 6 private report date is not treated as public disclosure.
Sources: Chrome dated announcement and report field; CVE publication metadata.

Patch Timeline & Exploitation Gap Analysis

The consistently measurable full-cohort distribution is 1, 21, 189, and 239 days from public disclosure to KEV inclusion. The mean is 112.5 days and the median is 105 days. The 238-day range is more informative than either central value alone: two observations are at or below three weeks, while two are more than six months.

Disclosure-to-KEV Interval	CVE	Share of Cohort
1 day	CVE-2026-87491	25%
21 days	CVE-2026-19490	25%
189 days	CVE-2026-20079	25%
239 days	CVE-2025-25249	25%

For the selected fix milestones, the corresponding intervals to KEV are 1, 21, 40, and 384 days. They are shown individually, not pooled into a first-patch average: the 40-day Cisco value measures an advisory revision, whereas the other values refer to specified releases. An arithmetic average would be easy to produce but would conceal that difference in measurement.

No full-cohort patch-to-first-exploitation mean or median is supported. Likewise, the data does not establish a widening or narrowing industry trend, or a reliable severity-dependent exploitation window. All inputs behind the calculations follow below.

CVE Timeline Data

The public-date column supplies D. The fix column supplies a selected, qualified milestone, not an assumed universal first patch. All KEV dates and the separate deadline table are sourced from the official catalog feed. Dates use year-month-day format.

CVE / Product	Public Date (D)	Verified Fix Milestone (M)	KEV Added (K)	Days: D → M	Days: M → K	First-Exploitation Evidence
CVE-2026-19490 Citrix NetScaler ADC / Gateway	2026-08-19 Public record	2026-08-19: 14.1-73.33 download. This is above the bulletin's 14.1-73.32 fixed threshold; an earliest cross-branch date is not asserted. Dated download · Fixed threshold	2026-09-09	0 Selected release only	21 Selected release to KEV	Exact first day unavailable in the primary dataset. KEV confirms known exploitation, not its start date.
CVE-2025-25249 Fortinet products; milestone is FortiOS 7.6.4 only	2026-01-13 CNA publication	2025-08-21: initial release in the 7.6.4 release-note chronology. The same document identifies 7.6.4 as no longer vulnerable to this CVE. Release notes, pages 6 and 65	2026-09-09	−145 Release precedes public CVE date	384 7.6.4 release milestone to KEV	Exact first day not established by the core primary records used for calculation. The CVE record's exploitation-assessment timestamp is not used as an attack start date.
CVE-2026-87491 Google Chrome / Chromium V8	2026-09-08 Vendor announcement	2026-09-08: Chrome 153.0.8010.36 for Linux; 153.0.8010.36/.37 for Windows and macOS. Rollout was staged. Stable release	2026-09-09	0 Stable-release milestone	1	Google acknowledged an exploit in the wild in the release announcement. An exact first-observed day is not given.
CVE-2026-20079 Cisco Secure FMC / SCC Firewall Management	2026-03-04 CNA publication	2026-07-31: advisory revision 2.0 added hotfixes. This establishes a documented fix milestone, not the earliest availability of every fix. Revision 2.6 replaced hotfix guidance with hardening releases on September 16. Revision history	2026-09-09	149 Public date to revision, not time to first patch	40 Hotfix revision to KEV, not first-patch interval	Cisco states it became aware of active exploitation in August 2026. That month is neither an exact first attack day nor proof exploitation began then. Exploitation statement

CVE	CISA Due Date	Days from KEV Addition	Catalog Forensic-Triage Field
CVE-2026-19490	2026-09-12	3	Yes
CVE-2025-25249	2026-09-12	3	Yes
CVE-2026-87491	2026-09-23	14	No
CVE-2026-20079	2026-09-12	3	Yes

The forensic-triage field is a catalog instruction flag, not a finding that a particular customer is compromised. The separate ransomware-use field is Unknown for all four records; it must not be read as confirmed ransomware use or confirmed absence of it. (Source: Catalog source.)

Statistical Distribution and Outliers

The median of 105 days falls between two widely separated pairs rather than describing a tightly clustered typical observation. The mean is only 7.5 days higher than the median, yet the range is 238 days. Mean-versus-median proximity should therefore not be mistaken for a narrow distribution.

CVE-2026-87491 is the shortest disclosure-to-KEV case at one day; CVE-2025-25249 is the longest at 239 days. These are descriptive endpoints, not statistically established outliers. Four selected observations cannot support a general ranking of vendor responsiveness.

The negative Fortinet disclosure-to-release result belongs to a different distribution. It follows from comparing an older fixed-version release milestone with a later public CVE record. It does not mean patching took negative time, and it cannot establish when every other Fortinet branch received a fix.

Vulnerability Class Breakdown

CVE	Weakness / CWE	Published Severity Context	Primary Reference
CVE-2026-19490	Authentication bypass through an alternate path; CWE-288	Critical; CVSS v4.0 9.3	Product bulletin
CVE-2025-25249	Heap-based buffer overflow; CWE-122. KEV additionally lists CWE-787.	High: CNA severity label. No numeric score comparison is made here.	CNA record · KEV
CVE-2026-87491	Out-of-bounds write in V8; CWE-787	Medium in the Chromium release note; separately, CISA-ADP assigns CVSS v3.1 8.8 (High).	Vendor label · CISA-ADP score
CVE-2026-20079	Authentication bypass through an alternate path; CWE-288	Critical; CVSS v3.1 10.0	CNA record

The two authentication-bypass entries have disclosure-to-KEV intervals of 21 and 189 days. The two memory-corruption entries have intervals of 1 and 239 days. With only two examples per broad grouping, neither pairing establishes a consistent class-level pattern. Chromium's issue-priority label and a CISA CVSS assessment also should not be presented as the same scoring system.

Notable Case Highlights

CVE-2025-25249: an older fixed-release milestone behind a new KEV addition

The FortiOS release notes provide two distinct facts: the 7.6.4 chronology begins on August 21, 2025, and 7.6.4 is identified as not vulnerable to this CVE. Joining those facts to the January 13, 2026 CNA publication date yields the release-specific 145-day pre-disclosure interval. It does not date fixes for FortiSwitchManager or FortiSASE. The CNA solutions field separately names FortiOS 7.6.4, 7.4.9, 7.2.12 and 7.0.18, and FortiSwitchManager 7.2.7 and 7.0.6, as upgrade targets within the corresponding branches.
Sources: FortiOS 7.6.4 release notes; CNA solutions and publication metadata.

CVE-2026-20079: exploitation evidence and evolving fix guidance

The long disclosure-to-KEV interval does not make the September hardening release the first patch. Cisco's advisory history documents earlier hotfix guidance and a later replacement with hardening releases. Separately, A September 9 exploitation investigation explicitly ties one intrusion cluster to this CVE and reports a JSP web shell followed by a malicious JAR used to obtain authentication data. That supports compromise review beyond checking a software version; it does not attribute every other attack described in the investigation to this CVE.
Sources: Advisory revisions; Vendor exploitation investigation, cluster 1.

CVE-2026-87491 and CVE-2026-19490: shorter listing intervals, different exposure tests

Chrome's one-day interval still includes an acknowledgment of an exploit in the wild, without a first-observed date. NetScaler's 21-day selected-release interval requires a different applicability check: the bulletin specifies Gateway or AAA configurations and version-dependent SAML conditions. Neither case supports a universal assumption that installing the product alone proves vulnerability, or that the KEV date marks the beginning of attacks.
Sources: Chrome announcement; NetScaler prerequisites.

Historical Trend Comparison

A comparable prior-period dataset using the same date-selection rules was not established for this analysis. Consequently, this post does not label the observed gap as widening, narrowing, or stable.

A defensible future comparison would need the same public-date rule, the same treatment of selected releases versus earliest fixes, and the same separation between first exploitation and KEV inclusion. Comparing this disclosure-to-KEV mean with a prior patch-to-KEV mean would measure different events.

MITRE ATT&CK Mapping

One case-specific behavior mapping is supported by the vendor investigation. It is an analytical mapping of observed activity, not an automatic mapping from a CWE and not a finding applied to the other three CVEs.

Tactic	Technique	Supported Case and Rationale
Persistence	T1505.003 - Web Shell	For CVE-2026-20079, the vendor investigation describes a JSP web shell placed in the CSM Tomcat webroot after successful exploitation. This observed server-side access mechanism supports the mapping. (Source: Cluster 1 evidence.)

No cohort-wide technique sequence is established. Additional tactic mappings would require case-specific behavioral evidence beyond the timeline and weakness classifications summarized here.

Risk Context for Organizations

The operational interpretation is two-sided: a newly added KEV can concern a long-public vulnerability, while a short disclosure-to-listing interval can coincide with already acknowledged exploitation. Organizations should not interpret the 112.5-day mean as a patching service level or a safe waiting period. It is a descriptive average over this selected cohort.

The catalog records three-day due-date intervals for the appliance and management-plane cases, compared with 14 days for the Chromium entry. Those recorded dates are not attacker-free windows. CISA's announcement places the applicable federal requirements under BOD 26-04, which applies to Federal Civilian Executive Branch agencies; other organizations should use the exploitation signal in their own risk-based prioritization rather than assume an identical universal legal deadline.
Sources: Recorded due dates; Directive context and scope.

For exposed management systems, patch verification and compromise assessment answer different questions. The observed Cisco web-shell activity illustrates why confirming an updated version does not, by itself, establish that prior access or persistence has been removed. (Source: Documented post-exploitation behavior.)

Detection and Patch Prioritization Considerations

Match exposure to the specific advisory. For NetScaler, combine installed build, release branch, and the applicable Gateway/AAA/SAML prerequisites. A version-only inventory is not a substitute for the configuration conditions in the bulletin.

Preserve release and revision provenance. Fortinet remediation should be matched to the relevant product and branch rather than extrapolated from the FortiOS milestone used here. For Cisco, validate against the current hardening guidance, not an old captured hotfix table. The original disclosure date and subsequent fix revisions should remain separate fields in the remediation record.
Sources: Product-specific solutions; Current fixed-software guidance.

Validate actual deployment, not only announcement. Chrome's stable update was announced with a phased rollout, so the announcement date cannot prove fleet-wide installation. Related Chromium-based products require their own vendor version and fix confirmation; this post does not assign Chrome's fixed build to another browser. (Source: Rollout announcement.)

Use exploitation evidence to set review scope. Where exposure and observed activity justify it, preserve relevant telemetry and investigate persistence in parallel with patch validation. The Cisco case provides behavior-level evidence for that distinction. A KEV entry alone is not a host-level detection, and absence of a published first attack day does not demonstrate absence of earlier compromise. (Source: Vendor investigation.)

Key Takeaways

• The four September 9, 2026 KEV additions have verified disclosure-to-listing intervals of 1, 21, 189, and 239 calendar days; their mean is 112.5 days and median is 105 days.
• A selected fixed release, a revised hotfix advisory, and an earliest patch are different measurements. This cohort does not support a uniform four-CVE first-patch average.
• FortiOS 7.6.4 supplies a release-specific milestone that predates the public CVE record; that date is not generalized to other affected Fortinet products or branches.
• KEV inclusion establishes known exploitation, not the first attack day or the scale of exploitation. A reliable cohort-wide patch-to-first-exploitation gap is unavailable.
• Patch validation should follow current, configuration-aware product guidance; where exploitation evidence supports it, compromise review must remain a separate task.

Conclusion

This batch demonstrates why patch analysis needs more than a single date difference. Its public-disclosure-to-KEV spread is measurable, but its fix milestones differ in scope and its precise first-exploitation dates are not consistently established.

For ongoing vulnerability and compliance monitoring, the useful record is a linked set of evidence: the relevant public notice, the exact fixed product and branch, subsequent advisory revisions, deployment verification, and any attributable exploitation observations. Keeping those records separate makes the timeline actionable without inventing certainty that the sources do not provide.

Constantly Fix Risks with Saner Patch Management

Saner Patch Management is a continuous, automated, and integrated patch management solution that helps organizations identify, prioritize, and remediate vulnerabilities actively exploited in the wild. It supports Windows, Linux, macOS, and more than 550 third-party applications, enabling timely deployment of security updates across enterprise environments.

The platform also provides safe patch testing environments, automated deployment workflows, compliance reporting, and patch rollback capabilities to minimize operational risk while ensuring critical vulnerabilities are addressed without delay.

Experience the fastest and most accurate patching software here.