The exploited catalogue gained an entry after we read it, and the version number did not move
At 14:39 UTC the catalogue was version 2026.09.25 with 1,725 entries and two additions that day. At 18:58 it was version 2026.09.25 with 1,726 and three. The version string is a date, so it cannot record a second release.
By Parminder Kumar Sharma · · 7 min read
Two reads of the same file, nine hours apart
On 25 September this site published a briefing on the two vulnerabilities CISA had added to the Known Exploited Vulnerabilities catalogue that day. Its fact check records the reading the piece was built on, because that is what a fact check is for:
catalogVersion 2026.09.25,dateReleased 2026-09-25T14:39:25.3654Z,count 1725.
The catalogue was fetched again on the morning of 26 September. It now reads:
catalogVersion 2026.09.25,dateReleased 2026-09-25T18:58:16.5029Z,count 1726.
Same version string. Four hours and nineteen minutes later. One more entry.
The entry is CVE-2026-87902, WordPress Core, a remote file inclusion that the record describes as letting an unauthenticated attacker make page template resolution include a chosen readable local PHP file from outside the active theme directories, leading to remote code execution. CWE-98. Due 28 September, three days after it appeared. It carries forensicTriage: Yes.
What that does not establish. It does not establish that CISA did anything improper or unusual. Nothing in the catalogue's documentation promises that the version string increments per release, and a second release on the same day is a perfectly ordinary thing for a working catalogue to do. It does not establish that anybody missed the WordPress entry in a way that mattered, because no exploitation window turns on nine hours. And it does not establish that the entry was added late rather than simply added.
What it establishes is a property of the format. catalogVersion is a date. It is 2026.09.25 because that is the day, which means that by construction it cannot distinguish two releases on the same day. The only fields that moved are dateReleased and count.
What that means for anything that consumes the file
The catalogue is not read by people. It is read by vulnerability management platforms, enrichment pipelines, ticketing integrations and a large number of small internal scripts, and the cheapest way for any of them to avoid reprocessing a two megabyte file is to compare a version field and stop if it has not changed.
For anything built that way, the 18:58 release did not happen. The version it saw at 14:39 is the version it saw at 19:00 and the version it will see until the next calendar day, so the WordPress entry does not exist until the following release changes the string.
The effect is small and the mechanism is not. A defender whose tooling keys on a field that cannot represent the change is not behind by nine hours. They are behind until something unrelated happens to move the field.
There is a second way to be caught by this, and it is the one that applies to anybody who writes rather than automates. A briefing, a weekly bulletin, an internal summary or a board slide that says "two additions on Friday" was accurate when it was written and is wrong now. Nothing will ever tell its author. The correction, if it comes, comes from somebody happening to re-read the file for an unrelated reason, which is exactly how this one surfaced.
The two readings of the CISA KEV catalogue JSON, the first recorded in the fact check of the briefing published on 25 September and the second fetched on 26 September.
| Field | At 14:39 UTC | At 18:58 UTC |
|---|---|---|
| catalogVersion | 2026.09.25 | 2026.09.25 |
| dateReleased | 2026-09-25T14:39:25Z | 2026-09-25T18:58:16Z |
| count | 1,725 | 1,726 |
| Additions dated 25 September | Two | Three |
| Third entry | Not present | CVE-2026-87902, WordPress Core |
How far the miss travelled
The Hacker News published a piece on 26 September, the following day, reporting on the additions. Its opening sentence: CISA "on Friday added two security flaws impacting Microsoft SharePoint and Mikrotik RouterOS to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation". The WordPress entry does not appear in the article.
That is not a criticism of the outlet, and it should not be read as one. Two is what the catalogue said when the story was researched, and the third entry arrived without any signal that would prompt anyone to look again. This site made the identical count in the identical window, which is why the earlier reading was available to compare against at all.
It is worth stating what the pattern is, because it is not a story about one file. Briefing 119 covered a KEV record in which a single field, knownRansomwareCampaignUse, changed from Unknown to Known with no field recording when. This is the same shape one level up: the container changed with nothing in it recording that the container changed. In both cases the information is present and correct at the moment you read it, and absent any way to notice that it differs from the last time you read it.
The entry itself, which deserves its own paragraph
None of the above is a reason to skip past what was added. WordPress Core is not a niche product, and the record is not a minor one.
The catalogue describes an unauthenticated remote file inclusion reaching remote code execution through page template resolution, cites a GitHub security advisory on the WordPress development repository, and sets a three day deadline. It carries forensicTriage: Yes, which under the current directive asks agencies to gather evidence rather than only to patch, and which is the field that distinguishes a flaw somebody thinks has already been used from one somebody expects to be used.
Of the three entries dated 25 September, two carry that flag: the SharePoint code injection and this one. The MikroTik record does not.
What to do about it
Take this with you
In the order worth doing
- Check whether you are on a patched WordPress Core and whether your hosting provider has applied it for you, because this entry is three days old and the deadline has already passed for federal agencies.
- Find every place in your estate that reads the catalogue and check what it compares. If the answer is catalogVersion, change it to the release timestamp, the count, or a hash of the file.
- Re-read the catalogue once more for any day on which you acted on it this month, because a same-day second release is invisible after the fact and this is the only way to find one.
- Treat forensicTriage as a distinct signal from the deadline. It asks a different question, it appears on a minority of records, and most tooling does not surface it at all.
- If you publish or brief from the catalogue, record the release timestamp and the count alongside the version in whatever you write. That is what made this comparison possible and it costs nothing.
- Ask your vendors the same question. A platform that tells you what is in KEV should be able to tell you when it last actually re-read it, rather than when it last saw the version change.
The question this leaves
There is no villain here. A catalogue that publishes twice in one day is a catalogue that is being maintained rather than batched, which is what everybody asks of it. The version field is a date because a date is a sensible name for a daily publication, and it was almost certainly never intended to carry the meaning that downstream tooling has quietly given it.
That is the recurring shape. A field acquires a job it was not designed for, because it is the most convenient thing present, and the failure only becomes visible when somebody happens to hold two copies of the same file taken at different times.
So the question for your own pipelines: for each external feed you depend on, what exactly do you compare to decide that nothing has changed, and would that comparison notice if the publisher released twice in one afternoon?
Sources
- PrimaryThe catalogue JSON, fetched at 14:39 UTC on 25 September and again on the morning of 26 September, used for both readings and for the WordPress record in fullCISAaccessed 2026-09-26
- PrimaryThe advisory the catalogue record cites for CVE-2026-87902, used for what the flaw isWordPressaccessed 2026-09-26
- Reported byThe briefing published on 25 September whose fact check records the earlier reading of the catalogue, which is the before half of this comparisonP.K. Sharmaaccessed 2026-09-26
- Reported byPublished 26 September and still reporting two additions, used as evidence that the third entry went unnoticed rather than as a criticism of the outletThe Hacker Newsaccessed 2026-09-26
