Why a vendor patch date and a CISA catalog date can differ

Apple announced one of these fixes 12 days before CISA added the CVE to its Known Exploited Vulnerabilities catalog. For two Windows bugs in the same comparison, the recorded dates match. We looked at four public records to understand what those gaps tell a patching team, and what they cannot tell us.

How we chose and compared the records

The sample contains one macOS Screen Sharing issue, one Chrome V8 issue and two Windows privilege-escalation issues covered by the advisories reviewed for this publication. We selected those four cases deliberately. They are not a representative sample of security updates.

For each row, we recorded the date of the vendor fix announcement identified in the source and the dateAdded field in CISA’s public JSON catalog. We used catalog version 2026.09.08, whose release timestamp is September 8 at 18:00:21 UTC. For Microsoft, the dates were checked against its September release data because the advisory pages require a browser application to render.

The last column subtracts the vendor announcement date from CISA’s catalog date in calendar days. A zero means the dates match. With no time of day in the per-entry values, it does not tell us which event happened first.

CISA’s public catalog data

Microsoft’s September 2026 release data

The four cases

The gaps are 12, one, zero and zero calendar days. None is an exploitation start date. The Apple row uses the cited Tahoe fix announcement, rather than attempting to combine every platform and release channel.

Apple’s cited fix announcement

Google’s cited fix announcement

Microsoft’s Windows Update Stack advisory

Microsoft’s Windows ALPC advisory

Download the four-row dataset and source URLs as CSV

How to check the calculation

Match records by CVE identifier. For each one, retain CISA’s dateAdded value and the specific vendor announcement used in the table, along with both source URLs and retrieval dates. A product nickname is too ambiguous: several bugs may affect the same component in one release.

Our calculation treats each YYYY-MM-DD value as a calendar date and subtracts the announcement date from the catalog date. No time-of-day conversion is applied because the per-entry values do not contain that precision. The catalog release timestamp identifies the snapshot reviewed; it is not the insertion timestamp of every record in that snapshot.

A check of the dataset should find four unique identifiers, one selected announcement per row, no missing dates and the four differences shown above. If a source is later corrected, keep the original and revised values with their retrieval dates. The CSV records this comparison as it was made; it is not a live exploitation feed.

Why the average is not the useful result

Sorting the four intervals gives 0, 0, 1 and 12 days. Their sum is 13 days, so the arithmetic mean is 3.25 days. The median is 0.5 days, the midpoint of the two middle values. That half-day is a property of the median calculation, not a claim that either underlying publication was timed to the nearest hour.

One 12-day gap has a large effect on that mean. Treating 3.25 days as an industry delay, a service target or a measure of CISA’s processing speed would go well beyond this small selected sample. The individual rows tell the reader more than the average.

What the selection leaves out

Every case had both a catalog entry and a vendor announcement when we reviewed it. Bugs that never enter the catalog, or enter later, are absent. This sample therefore cannot estimate the chance that a newly disclosed bug will be exploited or the share of all fixes eventually linked to known exploitation.

The comparison also selects one documented fix announcement for each CVE. A vendor can ship different products or branches on different dates. Changing the selected platform changes the question and potentially the interval. The Apple row is explicitly tied to the cited Tahoe announcement so that a reader can repeat the same comparison.

Keep your team’s dates separate

A useful internal record has four dates: vendor publication, the exploitation-source observation, your team’s triage and verified remediation. Public sources may supply the first two. Only your own records can show when you assessed the issue or finished updating the last affected device.

Those internal timestamps would let you study the time from triage to verified completion, including assets still unresolved. That is a different question from this four-row comparison. Mixing the dates would wrongly assign your organization’s response time to a vendor or catalog operator.

What this means for a patch queue

In two cases, a team waiting for a KEV entry could have started reviewing later than a team also monitoring vendor announcements. That is the limited inference the dates support. They tell us nothing about whether a particular organization delayed patching.

Use the vendor advisory to identify the correction and match affected products. Add known-exploitation information when it becomes available. Then track installation and verification in your own environment. Neither public source can confirm that a business device has received the update.

One way to do this is to keep a single work item for each applicable CVE. Record the first vendor review, add later exploitation information and retain the reason for any priority change. That avoids scattering the history across disconnected tickets.

What this comparison cannot establish

• The intervals are not the time attackers had access to an exploit, the time a vendor knew about a bug, or a measurement of how quickly anyone responded.

• A missing catalog entry does not prove that a vulnerability is safe. A catalog entry does not prove that a particular device was compromised.

• Four selected cases cannot support a ranking of vendor security quality or a prediction of how long future entries will take.

• Public records may be revised. The CSV preserves the values used for this comparison, while the linked vendor and catalog sources should be checked for subsequent changes.

Give the patch decision a record of its own

Keep the advisory, affected assets, exploitation status, assigned update and verified completion together, with dates for each check. Include outstanding exceptions so a ticket disappearing from a queue cannot be mistaken for a completed fix.

The public dates help a team decide when to look and what to prioritize. The local record answers the next question: what did we actually change on the systems we operate?

This is an original comparison of public records by Short Circuit LLC, reviewed September 8, 2026. It is not a new vulnerability disclosure. The vendors and credited researchers are responsible for the underlying findings.