They are not old bugs: they are old classes of bug. We ran the numbers on CISA's catalogue

A comfortable headline did the rounds this week: that what gets exploited most are flaws which should have been eradicated decades ago. We half believed it, so we did the only sensible thing with a subject you can actually measure: download the whole catalogue and count it. There are 1,685 entries. Of the 201 CISA has added so far in 2026, 123 have a 2026 identifier, and the median gap against the year they were added is zero. That answers a question the headline was not asking — and along the way something else turned up that really does change tomorrow's work.

The catalogue is called Known Exploited Vulnerabilities, KEV to its friends, and it is the list CISA keeps of vulnerabilities with evidence of real exploitation. Out of the forty thousand-plus CVEs published every year, only what somebody has watched being used gets in here. And it ships as an open JSON file, no sign-up and no paid API, so anybody can run the numbers instead of trusting somebody else's summary.

The count, so you can redo it

We worked on catalogue version 2026.08.27, released on 27 August at 17:00 UTC. It is two commands:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json

jq -r '[.vulnerabilities[] | select(.dateAdded >= "2026-01-01") | (.cveID|split("-")[1])]
       | group_by(.) | map("\(.[0]): \(length)") | join(", ")' kev.json

One warning before somebody writes in: the curl always downloads the current file, not the snapshot we used. Run it in a month and you will get more entries and different percentages, and that will be correct. This is the snapshot of the 27 August version, with the 201 entries CISA added between 1 January and that date, broken down by the year of their CVE identifier (the command returns them oldest first; here we have flipped the order):

123 out of 201 are from this same year, and another 34 from the previous one: 78% of what CISA has confirmed as exploited in 2026 carries a 2025 or 2026 identifier. The mean gap works out at 1.76 years, and that mean is stretched by a handful of very old entries; the median, which describes the typical case, is zero. The bulk of what is being exploited today is fresh material.

So where does the "decades" bit come from?

From two things that look alike and are not the same. A CVE is an instance: this particular flaw, in one vendor's particular product, across a range of versions. A CWE is the class, the way of getting it wrong that produced it. The headlines were talking about classes. The article behind them explains this carefully; it is the headline that invites the confusion, and we fell for it like everyone else.

The good news is that this part can be measured with the same file too, because every catalogue entry carries a cwes field. 1,510 of the 1,685 have one. Counting it, the classes that show up most among vulnerabilities with confirmed exploitation are these:

There is not a single surprise in that table, and that is exactly the story. The first one is failing to check what arrives. The third and fifth are writing outside the space reserved in memory, the mistake they teach you in your second year. All of them were described and named long before half the software that contains them today even existed.

That fits what the Vulnerability Review CISA published on 28 August says — an analysis of CVE and KEV records from its 2024 and 2025 fiscal years: seven of the ten most frequent CWEs of 2025 were still defects MITRE had already called unforgivable back in 2007. The report attributes 7,701 CVEs in 2024 and 21,019 in 2025 to the injection family. That second figure deserves caution: almost tripling in a year is better explained by improved class assignment than by a real explosion of injection bugs, and these are fiscal years rather than calendar ones.

The long tail is real, and it measures something else

Of those 201 entries from 2026, 35 carry an identifier from 2023 or earlier, 16 are from 2019 or earlier and 10 from 2012 or earlier. There are museum pieces in there. On 20 May, CVE-2008-4250 joined the list — the flaw in the Windows Server service that Microsoft patched out of band in October 2008 with bulletin MS08-067, the one the Conficker worm spread through. On 26 August, CVE-2015-3246 and CVE-2015-5287 went in, two Red Hat flaws from eleven years ago, in the same batch as CVE-2026-8452 from NetScaler, which we wrote about on Friday. The oldest identifier in the whole catalogue is CVE-2002-0367.

The easy reading would be that there are people who have not patched since 2008. There may well be, but that is not what the data says. The date added measures when CISA confirms exploitation exists, not when that exploitation began. A 2008 flaw entering in 2026 has not risen from the dead: far more likely it has been in use for years against systems nobody was watching, and this year somebody finally documented it in terms that allow it to be recorded. The long tail measures how late the evidence arrives. That is our reading, not a figure from the catalogue.

What we were not looking for: in June the rules changed

Every catalogue entry comes with a remediation deadline. When we counted the difference between the date added and that deadline across the 201 entries from 2026, the average came out odd, so we split the list by month. And the line draws itself in June:

Up to 9 June the deadlines were spread across 21 days (44 entries), 14 days (55) and 3 days (31). From 10 June only two values remain: 55 entries at three days and 13 at fourteen. Nothing else. The explanation is not in the file, it is in their federal register: on 10 June 2026 CISA issued directive BOD 26-04, "Prioritizing Security Updates Based on Risk", which expressly revokes BOD 22-01 from 2021 and BOD 19-02 from 2019. Instead of one deadline for the whole catalogue, the new one builds a matrix scoring asset exposure, evidence of exploitation, adversary automation capability and technical impact; the worst of the matrix must be fixed within three days, with mandatory forensic triage on top.

It is worth saying who that binds before anyone panics: US federal civilian agencies. Nobody imposes it on your company. But it is the best public signal there is about the speed at which the body maintaining the list believes you should move, and that signal has multiplied by three and a half this summer. We first saw it on Friday, in the catalogue's own text for the NetScaler flaw, which already demanded BOD 26-04 plus the forensic triage requirements.

Here is the knot, and we will put it plainly because it is what we see in real companies: a small or mid-sized business does not have a patching process that wins that race on a sustained basis. Three working days include the person who has to do it being on holiday, the downtime window you have to negotiate with whoever does the invoicing, and the vertical-software vendor who has not certified the new version yet. Anybody who tells you the answer is "patch faster" has not looked at the calendar of a forty-person company.

What the count does NOT say (and where we would go wrong)

Group the 201 entries from 2026 by vendor and the split is tempting. Here are the twelve with four or more, out of 88 distinct vendors: Microsoft 36, Cisco 14, Apple 8, Fortinet 6, then Google, Ivanti, Linux and Synacor with 5 each, and Adobe, Langflow, Oracle and SolarWinds with 4 each. The temptation is to publish that as a league table of bad vendors. It would be a mistake, and we say so knowing a headline like that would perform better. That count measures installed surface, researcher attention and a vendor's willingness to admit its own flaws. Microsoft tops the list because its software is everywhere and because, when something gets exploited, it becomes known. If you stop buying from them off the back of this table, you have misread the table.

There is a second thing the count does not say, and it matters more: the catalogue is a floor, not a ceiling. It only records what somebody has seen, confirmed and reported. What is missing from the list is what nobody has caught yet. In the same vein, 352 of the 1,685 entries — 21% — are flagged as having known use in ransomware campaigns, and in 2026 that is 24 out of 201. The rest are listed as Unknown, which means "not recorded".

What you can actually decide

You cannot patch a class of bug, and you cannot make your software vendor validate its inputs. What you do control is four decisions, all of them architectural. None is new or clever; they keep working when the patch arrives late, which is their entire merit.

• What is published on the internet. Look at the class table again: input validation, command injection and path traversal all require somebody to reach the input. A management panel reachable only from the internal network or over VPN trims the catalogue down to the part that actually affects you. It is the most boring measure of the lot and the one that has saved us the most grief.
• What privileges each service runs with. The same flaw is worth a scare or worth the whole domain depending on the account the process runs under. We wrote about it yesterday over PaperCut: a server's criticality is set by the privileges it runs with and what it is connected to, not by what it does for the user.
• What that service can see if it is taken. In the networks we come across, segmenting is usually an afternoon of firewall work, and it decides whether a compromised server is an incident or a rebuild.
• What happens when it fails anyway. Because it will. Behavioural rather than signature-based detection, which is what gives away a legitimate binary doing something it never does. And a backup you have genuinely restored at least once: our last full recovery drill took fourteen minutes, and we report that as evidence, not as a promise. An untested backup is not a backup: it is a lucky charm.

And there is a fifth decision almost nobody makes, and it is the only one that attacks the class rather than the case: what you demand of software before you buy it. We have already seen that a vendor's raw CVE count is no use. Its behaviour is: whether it publishes identifiers for its own flaws instead of fixing them quietly, whether it has a disclosure channel, whether it ships a component inventory, whether it documents the privileges its services run with. That is four questions and they fit in a tender document. In our consulting work we always ask them, and we resell nobody's platform: that is what lets us answer "not this one" when that is the right answer.

When this is not about you

If you have nothing published on the internet except a corporate website hosted by somebody else, and all remote access goes through a VPN with a second factor, much of this catalogue does not apply to you and is not worth losing a morning over. If on top of that your IT provider sends you a monthly report of what version each thing is running, checked against this list, this is an article rather than an outstanding task. And if you have your own security team, you had already run this count; we would like to see your numbers, because ours come from a while this morning and a single file.

New bug, old method

What gets exploited is from this year. The method for pulling it off has been documented since 2007, and the six classes in the table confirm it using CISA's own file. On top of that, since 10 June 81% of what enters the list arrives with a three-day deadline, so the speed route is closed for an ordinary company. That leaves the other one: what you expose, what privileges you run it with, what it can see if it is taken, and what you have proven you can restore. Downloading the list costs a second and counting it takes twenty minutes; start there, especially if you finish and discover that your defence can be switched off with a reboot.

Sources (consulted on 30 August 2026): every count in this article is ours, computed with jq against version 2026.08.27 of CISA's Known Exploited Vulnerabilities catalogue, released on 27 August at 17:00 UTC. From it come: the 1,685 entries, the 201 from 2026, the breakdown by identifier year, the 35 with a 2023-or-earlier identifier, the CWE class table (1,510 entries with a populated cwes field), the 10 June break in deadlines, the vendor breakdown, the 352 entries with known ransomware use and the dates CVE-2008-4250, CVE-2015-3246 and CVE-2015-5287 were added. The file lives at cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json and the commands are above so anyone can contradict us. The revocation of BOD 22-01 and BOD 19-02, the 10 June 2026 date, the prioritisation matrix and the mandatory forensic triage are in BOD 26-04, "Prioritizing Security Updates Based on Risk". That seven of the ten most frequent CWEs of 2025 were already on MITRE's 2007 unforgivable list, and the injection figures (7,701 CVEs in 2024 and 21,019 in 2025), come from the CISA Vulnerability Review of 28 August 2026, via The Register's coverage and other write-ups of the report: we flag this because CISA's server returned a 403 when we tried to read that page automatically, so unlike everything else here we could not check those two absolute figures against the original document. The attribution of CVE-2008-4250 to bulletin MS08-067 and the Conficker worm is in the public CVE record. These are ours, and we flag them as judgement rather than published fact: reading the long tail as delayed evidence, the warning against using the vendor count as a quality ranking, the suspicion that the jump from 7,701 to 21,019 is about classification rather than reality, and the five decisions at the end. The fourteen-minute figure is internal, from our last full recovery drill, and we give it as evidence rather than as a contractual commitment.