Skip to content

Which publishers revise their records?

Publication yearas of the 2026-09-07 snapshot

1.6%[1.0–2.6%]

Of the 1,041 records microsoft published with CVE ID year 2024 that stated a fix, 17 later raised the stated fix version on the same release branch. The first revision appeared after a median of 35 days.

Ranked by the lower bound of the Wilson 95% interval on the share of records stating a fix whose fix later moved, among publishers with at least 100 such records and at least 5 raised; the bracket is that interval. One publisher clears both floors this year, so there is no order to compare it against.

How often, and time to the first recorded revision7 publishers · disc area is records published
same day7 d30 d90 d1 year0%2%4%6%Share of records stating a fix whose fix later moved, with 95% intervalDays to first revision (median, log scale)Patchstack: 0.13% [0.044–0.38%] of 2,332 records stating a fix; median time to revision 3 days; 4,028 records published; too few raised to rankLinux: 0.032% [0.006–0.18%] of 3,164 records stating a fix; median time to revision 282 days; 3,173 records published; too few raised to rankWPScan: 0.33% [0.092–1.2%] of 599 records stating a fix; median time to revision 10 days; 975 records published; too few raised to ranksiemens: 0.37% [0.066–2.1%] of 269 records stating a fix; median time to revision 252 days; 304 records published; too few raised to rankGitLab: 0.55% [0.097–3.0%] of 183 records stating a fix; median time to revision 22 days; 296 records published; too few raised to rankdell: 1.6% [0.45–5.7%] of 123 records stating a fix; median time to revision 171 days; 256 records published; too few raised to rankmicrosoft: 1.6% [1.0–2.6%] of 1,041 records stating a fix; median time to revision 35 days; 1,095 records published; rank 1microsoft7 publishers of records published with CVE ID year 2024, by share of records stating a fix whose fix later moved (with 95% interval) against the median days the old answer stood. One publisher clears both floors this year, so there is no order to compare it against.

Filled and named: ranked. Hollow: too few raised to rank, drawn for the interval alone. Whisker: the 95% interval.

Publishers of 2024 records, ranked

1 ranked · 6 too few to rank · by lower bound
Publishers with at least 100 records stating a fix version published with CVE ID year 2024, ranked by the lower bound of the 95% interval on the share whose fix later moved. Publishers with fewer than 5 raised records follow, unranked.
Publisher, The CVE Numbering Authority that published the record, as the catalog names it. Links to every counted change in its records.Stating a fix, Records this publisher put out with CVE ID year 2024 which stated a fix version that could be put in order. The denominator of the rate.Raised, Of those, records whose stated fix later moved to a different version.Rate [95%], Raised as a share of records stating a fix, with the Wilson 95% interval in brackets.Median days to revision, For fix moves: median days from publication to the initial value’s first observed replacement, over this publisher's raised records. Same day is under one day.Events, Distinct correcting commits behind this publisher's counted rows. One commit that re-issued fifty records is one event.Shape: fix · range · bulk, What changed, in records: a stated fix moved, a last-affected version was raised, and how many of the fix moves sat in a bulk commit of fifty rows or more. The three are not added.Edits: same day → over a year, Days until the initial value’s first observed replacement, binned same day, within a week, within a month, within a quarter, within a year, over a year. Bar height is the share of the publisher's edits in that bin.Feed, An RSS feed of every counted change in records this publisher assigned.
microsoft#11,041171.6% [1.0–2.6%]35 days1317 fix moved·0 range extended·0 in bulkmicrosoft: 27 counted rows by the interval to the first recorded revision: 2 1 to 7 days, 8 8 to 30 days, 15 31 to 90 days, 2 91 to 365 daysRSS
Too few to rank: fewer than 5 records raised. Listed for interval overlap alone. This is not a test of whether their rates differ.
dell12321.6% [0.45–5.7%]171 days22 fix moved·0 range extended·0 in bulkdell: 2 counted rows by the interval to the first recorded revision: 2 91 to 365 daysRSS
GitLab18310.55% [0.097–3.0%]22 days11 fix moved·0 range extended·0 in bulkGitLab: 2 counted rows by the interval to the first recorded revision: 2 8 to 30 daysRSS
WPScan59920.33% [0.092–1.2%]10 days22 fix moved·0 range extended·0 in bulkWPScan: 2 counted rows by the interval to the first recorded revision: 1 same day, 1 8 to 30 daysRSS
siemens26910.37% [0.066–2.1%]252 days11 fix moved·0 range extended·0 in bulksiemens: 2 counted rows by the interval to the first recorded revision: 2 91 to 365 daysRSS
Patchstack2,33230.13% [0.044–0.38%]3 days253 fix moved·91 range extended·1 in bulkPatchstack: 94 counted rows by the interval to the first recorded revision: 2 same day, 6 1 to 7 days, 7 8 to 30 days, 5 31 to 90 days, 6 91 to 365 days, 68 over a yearRSS
Linux3,16410.032% [0.006–0.18%]282 days11 fix moved·0 range extended·0 in bulkLinux: 1 counted rows by the interval to the first recorded revision: 1 91 to 365 daysRSS

The rate divides by the records that stated a fix version at all, never by everything a publisher put out: a publisher whose versions are rarely comparable would otherwise read low for that reason rather than for accuracy. Records, not rows, in every column: a record that raised the fix for four products is one record here and four rows in the change list.

Shape, in records: fix is records whose stated fix moved, range is records whose last-affected version was raised, and bulk is how many of the fix moves sat in one commit of fifty rows or more. The three are never added. Events are distinct correcting commits.

A high rate is not bad practice. A publisher that finds its first patch incomplete should raise the version; what this measures is that nobody downstream is told.

Where two scorers disagree →The same records by vendor →Every raised fix version, one row each →

Data sources and quality

The organisation that publishes a CVE record is its CNA, a CVE Numbering Authority: a vendor, a research team or a national CERT that writes the record and can edit it afterwards. A rate here is the share of its records that stated a fix version whose fix later moved. It ranks one of the 15 kinds of change this site watches, and it is not a quality score.

We compare each record as it read on the day it was published against the same record today. The older copies come from the catalog's public git history, where a commit is one dated save; the first commit is the earliest copy anyone can read, and “backfilled” means a file was added to that history in a batch, later than the day the record itself went out. “Days”, for fix moves, measures from publication to the initial value’s first observed replacement. It does not date when a value became wrong.

These figures are concentrated. One publisher, microsoft, accounts for 17 of the 32 records raised with CVE ID year 2024. The 1 ranked publisher published 1,095 of the 39,236 records compared and hold 17 of the raised ones, so the year's pooled rate is an average over all of them, not a typical publisher.

Records this site refused as false positives, product lines renumbered rather than a fix raised, are counted in no figure on this page. They are listed, marked, under every change so the filter can be checked; that list counts rows, this page counts records, so the same filter reads as two different numbers on the two pages. 187 refused with CVE ID year 2024.

Not listed: a publisher with fewer than 100 records stating a fix version with CVE ID year 2024, or none whose fix moved, is absent from this page (6 such publishers had a raised record with CVE ID year 2024). Below that floor a single record swings the rate by a whole point. Absence here is not a clean record.

Not checked: a record published before 2023 cannot have its state at publication recovered and was never compared, so no publisher is credited or blamed for one.

A change shown here is a change to a public record, evidenced by a commit anyone can read in the publisher's own history. It is not an assertion of wrongdoing, negligence or bad faith by any publisher or vendor, not evidence that any fix was incomplete, and not a statement about anyone's systems.

Shipped snapshot computed 2026-09-07 from catalog commit f5f9fc6fd7dc. Real findings, not live ones: records amended since are not reflected. A later fix version is evidence that the record changed, not evidence that the first fix was incomplete.

How every one of these figures is measured, in full →